Ol�!
Eu retirei este texto da apostila de UML que o professor Ant�nio Francisco
do Prado usou para nos dar aula este ano. Se voc� quiser que eu mande a
apostila inteira, me mande um e-mail para eu mandar em private, porque eu
acho que ela � um pouquinho pesada demais para se mandar pela lista (por
volta de 1.3Mb)...
Espero que ajude!
Abra�os
Ana L�cia
[EMAIL PROTECTED]
3. Princ�pios da Orienta��o a Objetos
O conhecimento dos princ�pios da Orienta��o a Objetos � de grande
import�ncia porque facilita o entendimento das id�ias, t�cnicas e
ferramentas deste novo paradigma. Um m�todo, uma ferramenta, um ambiente ou
uma linguagem � tanto mais orientado a objeto quanto mais atende aos
princ�pios da orienta��o a objeto.
3.1 Abstra��o
Abstra��o � a habilidade de ignorar os aspectos de um assunto n�o
relevantes para o prop�sito em quest�o, tornando poss�vel uma concentra��o
maior nos assuntos principais[Oxford 86]. A abstra��o consiste portanto na
sele��o que um desenvolvedor faz de alguns aspectos, suprimindo outros.
Pessoas, lugares, coisas e conceitos do mundo real s�o normalmente
complexos. Quando queremos diminuir a complexidade selecionamos parte do que
estamos analisando, em vez de tentarmos compreender o todo.
A abstra��o pode ser de: procedimentos e objetos.
Abstra��o de procedimentos baseia-se no princ�pio de que qualquer opera��o
com um efeito bem definido pode ser tratada por seus usu�rios como uma
entidade �nica, mesmo que a opera��o seja realmente conseguida atrav�s de
alguma seq��ncia de opera��es de n�vel mais baixo[Oxford 86].
Normalmente, usamos abstra��o de procedimentos quando definimos em nossos
DFDs macrofun��es que se decomp�em em fun��es, as quais por sua vez se
decomp�em em subfun��es. Um sistema em seu n�vel mais alto pode ser
abstra�do como um caixa preta que, uma vez executado, produz os resultados
desejados. Dividir o sistema em processos e subprocessos, muito usado na
an�lise estruturada, n�o � a forma principal de particionamento ou abstra��o
da AOO. Na AOO a abstra��o de procedimentos � usada dentro do contexto
limitado da especifica��o e descri��o de servi�os.
Abstra��o de objetos consiste em definir os servi�os e atributos aplic�veis
a estes objetos. Estes objetos s� podem ser modificados e observados atrav�s
destes servi�os[Oxford 86].
A abstra��o de objetos serve de base para a organiza��o do pensamento e a
especifica��o das responsabilidades do sistema. � a habilidade de descrever
novos tipos de dados em termos de seus formatos e servi�os que agem sobre
eles.
Ao aplicar a abstra��o de objetos, o desenvolvedor define:
- atributos e
- servi�os que manipulam exclusivamente estes atributos.
Atributo � qualquer propriedade, qualidade ou caracter�stica que pode ser
atribu�da a uma pessoa ou objeto[Webster's 77]. Na AOO, o termo atributo �
definido de forma a refletir o dom�nio do problema e as responsabilidades do
sistema, ou seja, atributo � um dado (informa��o de estado) para o qual cada
objeto em uma classe tem seu pr�prio valor. Os atributos s� podem ser
acessados atrav�s de um servi�o.
Servi�o � uma atividade executada para permitir que as pessoas utilizem
alguma coisa [Webster's 77]. Na AOO, o termo servi�o � definido de forma a
refletir o dom�nio do problema e as responsabilidades do sistema, ou seja,
servi�o � um comportamento espec�fico que um objeto deve exibir.
A abstra��o tamb�m depende do ponto de vista. Por exemplo, o coelho da
Figura 3.1, sob o ponto de vista da mo�a tem atributos cor, apar�ncia, etc,
e sob o ponto de vista do veterin�rio tem atributos peso, tamanho, etc. Da
mesma forma, tem-se os servi�os correr e brincar, sob o ponto de vista da
mo�a, e criar e comer sob o ponto de vista do veterin�rio.
3.2 Encapsulamento
Princ�pio usado no desenvolvimento de uma estrutura global de programa, que
estabelece que cada componente do programa deve conter uma �nica decis�o de
projeto. A interface para cada m�dulo � definida de forma a revelar o menos
poss�vel sobre seu funcionamento interno[Oxford 86].
O objetivo do encapsulamento (ocultamento de informa��es) � restringir o
escopo ou visibilidade da informa��o para obter melhor legibilidade,
manutebilidade e principalmente reutilizabilidade no desenvolvimento de um
novo sistema. O encapsulamento permite que o desenvolvedor reuna os aspectos
mais inst�veis de forma a facilitar sua localiza��o e manuten��o em caso de
altera��es, hoje muito comum nos sistemas.
O encapsulamento pode ainda ser visto como um processo pelo qual se
combinam os atributos e os servi�os que agem sobre estes atributos, em uma
defini��o que oculta detalhes de implementa��o. Por exemplo, a calculadora
da Figura 3.2, tem internamente seus registradores, que s�o ocultos por uma
interface que disponibiliza para o usu�rio apenas os servi�os de Somar,
Subtrair e outras opera��es. Note ainda que detalhes dos processos pelos
quais se obtem um resultado n�o est�o diretamente vis�veis para quem est�
usando a calculadora, e nem mesmo isto interessa. Em resumo, juntam-se
atributos e servi�os disponibilizando apenas o que interessa mostrar,
normalmente os servi�os.
3.3 Classe e Objeto
Das id�ias de abstra��o e encapsulamento tem-se o Tipo Abstrato de
Dados(TAD), que possui uma interface para ocultar detalhes de implementa��o,
possibilitando que se tenham diferentes especifica��es, em diferentes
tempos, sem afetar as aplica��es que utilizam o TAD. Um TAD � tamb�m chamado
de Classe, a qual pode ser vista como uma f�brica de objetos id�nticos no
que diz respeito � sua interface e implementa��o. Assim por exemplo, tem-se,
na Figura 3.3, o TAD Pessoa, ou a Classe Pessoa, cujos atributos s�o Nome,
Endere�o, Identidade, Estado Civil e outros, e cujos servi�os s�o Estudar,
Trabalhar, Dirigir, Passear, e outros. Uma classe � portanto um conjunto de
objetos similares. Uma inst�ncia de uma classe � chamada Objeto da Classe.
Na Figura 3.3 tem-se que Maria e Pedro s�o duas inst�ncias da classe Pessoa.
3.4 Heran�a
A abstra��o de dados � uma t�cnica efetiva para se definir um conceito
�nico e claro, como os TADs. Contudo, muitas vezes pode-se ter um TAD que �
quase, mas n�o exatamente o que queremos e, neste caso, a heran�a � uma
t�cnica �til para ampliar a abstra��o de dados. Baseado nestes conceitos,
define-se:
Heran�a � o mecanismo para expressar a similaridade entre Classes,
simplificando a defini��o de Classes iguais a outras que j� foram definidas.
Este princ�pio permite representar membros comuns, servi�os e atributos uma
s� vez, assim como especializar estes membros em casos espec�ficos.
A heran�a permite, portanto, a reutiliza��o de especifica��es comuns, logo
no in�cio das atividades de an�lise. A heran�a define uma rela��o entre
classes do tipo �-um(a), onde uma classe compartilha a estrutura e o
comportamento definidos em uma ou mais classes. O reconhecimento da
similaridade entre classes forma uma hierarquia de classes, onde
superclasses representam abstra��es generalizadas e subclasses representam
abstra��es, onde atributos e servi�os espec�ficos s�o adicionados,
modificados ou removidos. As classes s�o conectadas por uma estrutura de
generaliza��o e especializa��o, tornando expl�citos os atributos e servi�os
comuns em uma hierarquia de Classes.
Na Figura 3.4, tem-se, por exemplo, que Estudante � uma Pessoa, Professor �
uma Pessoa. Um objeto da classe Estudante, tem n�o apenas os atributos e
servi�os de Estudante, como tamb�m os atributos herdados da classe Pessoa.
Por exemplo, o estudante Jo�o tem atributos e servi�os de Pessoa, como Nome,
Endere�o, Dirigir, Viajar, e atributos e servi�os que expressam o
comportamento espec�fico de um estudante, como Curso, Nota, Estudar e
Realizar Prova. A classe Pessoa � reconhecida como uma generaliza��o e
Estudante como uma classe especializa��o, a qual herda os servi�os e
atributos de Pessoa. Al�m disso, uma classe derivada (uma especializa��o)
pode incluir novos servi�os e atributos ou redefinir os servi�os herdados.
Dessa forma, Funcion�rio pode incluir atributos como Sal�rio e Profiss�o e
servi�os como CalcularSal�rio, que podem n�o ser relevantes ou apropriados
para Pessoa em geral.
3.5 Escala
� o princ�pio que permite ao desenvolvedor considerar algo muito grande
atrav�s do enfoque Todo-Parte. Todo-Parte � um dos servi�os b�sicos naturais
de organiza��o dos seres humanos que orienta o desenvolvedor atrav�s de um
modelo extenso.
Todo-Parte tamb�m � conhecido como Agrega��o, que � um mecanismo que
permite a constru��o de uma classe agregada a partir de outras classes
componentes. Usa-se dizer que um objeto da classe agregada(Todo) tem objetos
das classes componentes(Parte). Por exemplo, na Figura 3.5 tem-se que uma
casa tem portas, janelas, paredes, escadas e outras partes.
Mesmo em se tratando de entidades abstratas, pode-se compor um objeto a
partir de outros objetos. A Figura 3.6 mostra que um Pedido (Todo) �
composto ou tem ItensPedidos(Partes), no caso Rel�gio e Computador.
3.6 Associa��o
A associa��o vem do relacionamento entre as entidades do mundo real, e �
usada para agrupar certos objetos que ocorrem em algum ponto no tempo ou sob
circunst�ncias similares.
Associa��o � uma uni�o ou conex�o de id�ias[Webster's 77]. Na AOO, a
associa��o � modelada atrav�s de uma conex�o de ocorr�ncias. Uma conex�o de
ocorr�ncia � um relacionamento que um objeto precisa ter com outro(s)
objeto(s), para cumprir suas responsabilidades. Por exemplo, a Figura 3.7
mostra a associa��o entre Estudante, Teste e Sala. Neste relacionamento
tern�rio, tem-se que cada estudante faz determinado teste em uma sala.
Outros tipos de relacionamentos bin�rios ou de maior ordem podem existir,
como o mostrado na Figura 3.8 onde Cliente faz determinado Pedido.
3.7 Comunica��o com Mensagens
Mensagem � qualquer comunica��o, escrita ou oral feita entre
pessoas[Webster's 77]. Na AOO, a comunica��o entre objetos, � feita atrav�s
de mensagens modeladas usando conex�es de mensagens. Uma conex�o de mensagem
modela a depend�ncia de processamento de um objeto, indicando quais servi�os
ele precisa para cumprir suas responsabilidades. As conex�es de mensagens
existem somente em fun��o dos servi�os, e fazem o mapeamento:
- de um objeto para outro objeto;
- de um objeto para uma classe (cria��o de objetos) e
- de uma classe para outra classe (cria��o de objetos dentro de outros
objetos).
Numa conex�o de mensagem, tem-se uma classe ou objeto emissor que envia a
mensagem para uma classe ou objeto receptor para realiza��o de algum
processamento. O processamento necess�rio � nomeado na especifica��o de
servi�os do emissor, e � definido na especifica��o de servi�os do receptor.
Na Figura 3.9, uma estudante, objeto da classe Estudante, dispara uma
mensagem para o professor, objeto da classe Professor. A mensagem � tratada
e � retornada uma resposta.
Os servi�os modelam o comportamento dos objetos.
Tr�s tipos de classifica��o de comportamento s�o mais freq�entemente
usados:
(1) com base na causa imediata;
(2) conforme similaridade de evolu��o hist�rica(altera��o com o tempo) e
(3) conforme a similaridade de fun��o.
Considerando que, na AOO, a considera��o central na defini��o de servi�os �
definir o comportamento requerido que um objeto deve refletir, estes
princ�pios s�o incorporados nas estrat�gias que definem:
(1) Estados de objeto - elaborada com base no princ�pio de altera��o com o
tempo.
(2) Servi�os requeridos - elaborada com base nos princ�pios de similaridade
de fun��o e causa imediata.
3.8 Polimorfismo
Polimorfismo � o princ�pio relacionado com as diferentes formas de um
objeto. Operacionalmente, o polimorfismo pode ser visto conforme mostra a
Figura 3.10, onde se pode instanciar um objeto Janela de v�rias formas.
Tamb�m pode-se observar que operadores podem ser sobrecarregados para
realizar opera��es com diferentes tipos de objetos. Por exemplo, o operador
+ est� sendo utilizado para somar inteiros e matrizes.
Finalizando este cap�tulo, conclu�-se que o conhecimento dos princ�pios da
orienta��o a objetos � de fundamental import�ncia, principalmente porque nos
ajuda a pensar em objetos e n�o apenas em dados ou fun��es, como era no
paradigma tradicional de desenvolvimento de software. Em seguida, ser�o
apresentados os principais m�todos utilizados para o desenvolvimento de
software orientado a objetos.
* Para n�o receber mais e-mails desta lista envie um e-mail para
[[EMAIL PROTECTED]]
e no corpo do email escreva [unsubscribe <seu-email>]
Veja as mensagens antigas em http://www.mail-archive.com/javabr%40cits.br/
