Programao Orientada a Objetos

1. Introduo Programao OO
Neste captulo so discutidas as limitaes da programao estruturada, quanto aos aspectos de visibilidade e proteo do cdigo executvel e dos dados da aplicao, e como a programao orientada a objetos capaz de super-las. So apresentados os conceitos de ocultamento de informao, encapsulamento, tipos abstratos de dados e interface. Inclui ainda um breve histrico das linguagens orientadas a objetos. Ao concluir este captulo o estudante dever ser capaz de explicar como a programao estruturada e a programao orientada a objetos esto relacionadas, analisar programas existentes sob o ponto de vista dos conceitos apresentados e situar a linguagem Java no contexto das linguagens de programao orientadas a objetos. 1.1. Evoluo das Tcnicas de Programao A evoluo da programao de computadores marcada por trs desenvolvimentos de enorme impacto nos seus parmetros de produtividade e qualidade: as linguagens de alto nvel, na dcada de 60, as tcnicas de programao estruturada [Dijkstra69], na dcada de 70 e, atualmente, as tcnicas de orientao a objetos [Liskov77]. Foram as linguagens de alto nvel, como Fortran e COBOL, que, ao permitir o desenvolvimento de programas portveis entre diferentes computadores, tornaram economicamente vivel o desenvolvimento de sistemas de grande porte, de vida til superior a de vrias geraes de computadores. O desenvolvimento de sistemas de grande porte, porm, passou a exigir programas cada vez maiores e mais complexos. O sucesso da programao estruturada se deve justamente por sistematizar o desenvolvimento desses programas, atravs de uma estratgia de diviso e conquista: cada programa dividido em vrios subprogramas, que so coordenados utilizando-se estruturas de controle de fluxo de execuo simples e bem definidas (if-then-else, do-until, while-do, etc. ). 1.2. Programao Baseada em Procedimentos Aplicando as tcnicas da programao estruturada a um programa para automao bancria, por exemplo, podemos divid-lo em quatro mdulos (ou subprogramas): (i) manuteno de cadastros (ii) movimentao de caixa (iii) caixa automtico (iv) relatrios para contabilidade O programa de manuteno de cadastros, por sua vez, divide-se em outros subprogramas, como cadastro de cliente, abertura de conta, alterao de dados da conta, e assim, sucessivamente, at obtermos subprogramas suficientemente simples e pequenos para serem codificados com facilidade. A figura 3.2 ilustra parte da estrutura desse programa. Esse mtodo de estruturao atravs de refinamentos sucessivos [Wirth71], se caracteriza por partir de uma viso global centrada em procedimentos para soluo de um problema, que detalhada gradualmente at o nvel dos comandos da linguagem de programao utilizada. Note que criada uma hierarquia de procedimentos, com uma ntida relao de subordinao entre os subprogramas, ou seja, os subprogramas dos nveis inferiores apenas respondendo a requisies oriundas de um subprograma de nvel superior. Outro ponto importante a observar que os dados da aplicao ficam separados dos subprogramas que os manipulam. Os nveis superiores da estrutura tendem a concentrar a maior parte dos dados, que so manipulados por diversos subprogramas dos nveis inferiores.

Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

Fig 1.1 - Estrutura baseada em procedimento.

1.3 Orientao a objetos

Por mais simples que seja um problema a ser implementado, ser preciso empregar alguma forma de projeto. A perspectiva orientada a objetos, uma das mais empregadas tanto pela indstria quanto pela academia para a atividade de projeto de software, comentada abaixo. Pensar em cdigo da perspectiva orientada a objetos e pensar na interao entre objetos. O que pressupe a identificao dos objetos e a distribuio de responsabilidades entre eles, o que torna a interao obrigatria. Cdigo orientado a objeto em execuo um conjunto de objetos que cooperam entre si. Empregar esta abordagem exige o domnio de vrios conceitos, apresentados logo aps uma breve discusso acerca de como registrar modelos conforme esta tecnologia.

1.3.1 Modelagem
Orientao a objetos uma forma de pensar, uma perspectiva de observao. Aplicla contemplar um determinado cenrio desta perspectiva. Esta perspectiva seria de pouca utilidade se no fosse possvel registr-la. Sem registro a histria curta, no h o que compartilhar com membros de uma equipe, e torna praticamente impossvel qualquer tipo de averiguao. Felizmente, h vrias propostas de registro da viso orientada a objetos. A Unified Modeling Language, ou UML por simplicidade, tem mostrado fora no meio industrial e se tornou um padro de fato para o registro de artefatos orientados a objetos. A UML possui construes para especificar, visualizar e documentar artefatos de software da perspectiva orientada a objetos. Esta a linguagem empregada neste texto, apresentada juntamente com termos tpicos do mundo orientado a objetos.

1.3.2 Conceitos

Objeto uma abstrao de uma entidade fsica ou de um conceito. Noutro sentido, um conceito ou uma entidade fsica pode ser representada por um objeto. A entidade objeto possui uma identidade nica, alm de um estado (dados) e de comportamento (mtodos). A reunio de dados e mtodos forma um objeto. A identidade permite distinguir um objeto dentre os demais, mesmo que estes possuem um estado semelhante. O estado de um objeto descrito pelos valores do correspondente conjunto de atributos, ou propriedades que so encapsuladas pelo objeto. O comportamento definido atravs de mtodos. Um objeto interage com outro objeto atravs do envio de uma mensagem ao destinatrio, o que realizado pela chamada de um mtodo. Um objeto pode, por exemplo,

Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

requisitar o valor de um atributo de um determinado objeto atravs do envio de uma mensagem para este determinado objeto. Os atributos de um objeto e os mtodos atravs dos quais este objeto pode receber mensagens so descritos por uma classe. Classe uma espcie de forma (o) atravs da qual os objetos so criados. Em tempo, objeto uma instncia de uma classe. Quando se define uma classe, tambm definida a interface atravs da qual todos os objetos oriundos desta classe podero receber mensagens.

Figura 1.2: Um objeto caracteriza-se por encapsular dados e mtodos. Os acessos aos servios oferecidos por um objeto esto restritos a interface do objeto.

De uma classe podem ser criadas zero ou mais instncias. Classes no reagem a mensagens, pois no se pode enviar mensagens a uma classe. Quem recebe mensagens so objetos. Uma classe define um conjunto de mtodos, mas so os objetos, entidades com vida, que podem receber mensagens atravs da interface definida na classe. Classe no possui estado, mas define o conjunto de atributos cujos valores formam o estado de um objeto.

1.3.3 Interao entre objetos

No suficiente representar um conjunto de objetos para se derivar um software correspondente. preciso capturar a troca de mensagens entre objetos ao longo do tempo. Objetos no o se encontram isolados, mas interagem entre si. Ter uma tarefa realizada em um modelo orientado a objetos fazer com que os objetos cooperem uns com os outros, conforme a responsabilidade necessitada por um objeto e oferecida por outro.

Figura 1.3: Objeto cliente requisita servio de responsabilidade de um objeto servidor atravs do envio de uma mensagem. A requisio pode partir de qualquer ponto do objeto que requisita, enquanto o destino necessariamente parte da interface do objeto servidor.

A cooperao se d atravs de mensagens. Para que um objeto usufrua da responsabilidade oferecida por outro objeto e necessrio que este receba uma mensagem do primeiro. Uma mensagem s possvel caso exista um ponto de interao que faa parte da interface do objeto. A interao com um objeto est restrita interface deste objeto. Se estas condies so satisfeitas, ento o objeto que recebe a mensagem executa o mtodo. Ao final da execuo do mtodo, o controle transferido de volta para o objeto que enviou a mensagem.
Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

1.3.4 Classe
Uma classe descreve um conjunto de objetos da perspectiva dos dados e processos correspondentes. a partir de uma classe que objetos so criados. Criar um objeto, ou instncia de uma classe algo similar criao de uma varivel, para a qual existe um tipo. Uma varivel de um tipo primitivo, contudo, possui um domnio de valores e um conjunto de operaes predefinidas pela linguagem. Por exemplo, em algumas linguagens possvel realizar x + y onde os operandos so seqncias de caracteres, enquanto x * y envolve um operador no permitido para o tipo seqncia de caracteres. Uma classe, ao contrrio de tipos predefinidos, inclui dados e mtodos que forem considerados apropriados para a abstrao em questo. Por exemplo, talvez no exista nenhuma linguagem de programao que possua o tipo predefinido Pessoa, mas uma linguagem de programao orientada a objetos permitir a criao desta classe. A modelagem correspondente fornecida abaixo.

Figura 1.4: Classe Pessoa em UML.

A figura 1.4 faz uso da modelagem de uma classe empregando trs compartimentos: (a) nome da classe, (b) atributos e (c) mtodos. Apenas o nome da classe, primeiro compartimento, foi fornecido nesta figura. Os outros dois compartimentos esto vazios. Conforme a figura 1.5, os compartimentos de atributos e mtodos podem ser omitidos. A opo entre um e outro depende do interesse que se pretende fazer do modelo. Em alguns cenrios pode ser suficiente representar a classe Pessoa sem o detalhamento dos atributos e dos mtodos, enquanto em outros pode ser imprescindvel a descrio destes elementos.

Figura 1.5: Verses equivalentes sem o detalhamento de atributos e mtodos.

1.3.5 Atributos de classe

O estado de um objeto determinado pelos valores dos atributos da classe correspondente. No exemplo da figura 1.8, a classe Pessoa declarada com quatro atributos. So os valores destes quatros atributos para uma dada instncia que iro determinar o estado desta instncia em determinado instante. Observe que nenhum mtodo fornecido na declarao desta classe. Trs dos atributos so privados, o que significa que so visveis exclusivamente no corpo da classe, enquanto idade declarado pblico, ou seja, e visvel em outras classes, que desconhecem a existncia de dia, mes e ano.

Figura 1.6: Declarao de atributos de uma classe em Java e a verso correspondente em UML. Observe o sinal representando o modificador de acesso privado e o sinal + representando o modificador de acesso pblico, enquanto / indica que o atributo em questo derivado.

Os atributos so do tipo Integer, predefinido na UML. Representa um elemento de um conjunto infinito representado pelos inteiros, ou seja, -2, -1, 0 e 256 so elementos deste conjunto. Quando esta classe for implementada, naturalmente este tipo ter que ser mapeado para o tipo correspondente na linguagem de programao empregada. Por exemplo, em Java
Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

os dois bytes do tipo predefinido short so suficientes. Se a linguagem VB.NET, ento pode ser empregado o tipo predefinido Short, que representa um inteiro de dois bytes. A classe na figura 1.6 possui um atributo derivado. Um atributo derivado e aquele que pode ser obtido dos demais. A verso UML faz uso de uma barra / para identificar um atributo derivado. Esta barra indica que o atributo idade e derivado. Os demais atributos, dia, mes e ano identificam a data de nascimento da pessoa em questo e, portanto, o valor do atributo idade pode ser obtido dos valores dos demais atributos.

1.3.6 Mtodos de classe

Uma classe a unio de atributos, que descrevem o domnio dos estados dos objetos criados a partir desta classe, e mtodos, que descrevem o comportamento. Os mtodos so descritos no terceiro compartimento de uma classe em UML, conforme a ilustrao na figura 1.7.

Figura 1.7: A classe Prova contm trs membros: um atributo e dois mtodos para manipulao deste atributo. Para cada atributo pode ser definido um mtodo get um mtodo set. (Alguns sofisticados preferem empregar as denominaes de accessors e mutators, respectivamente.)

Para que este atributo privado possa ser manipulado, dois mtodos foram fornecidos com o modificador de acesso pblico. O mtodo getNumQuestoes dito um mtodo get. Retorna o valor do atributo em questo. A construo do nome deste tipo de mtodo formado pela concatenao de get com o identificador do atributo. Todas as iniciais de nomes que formam o identificador do atributo so fornecidas em maisculas. Esta conveno a mesma empregada pela especificao da UML. A formao do nome do mtodo set similar formao para o nome do mtodo get. Enquanto o primeiro no recebe um valor do tipo Byte, o segundo retorna um valor deste tipo.

1.3.4 Visibilidade e Proteo de Cdigo e Dados

Um dos problemas da programao estruturada a forma como so implementados, naquelas linguagens, os conceitos de visibilidade e proteo do cdigo executvel e dos dados da aplicao, conforme definidos a seguir: Visibilidade (visibility) a propriedade de um item de dado ou subprograma que determina quais as partes do cdigo do programa em que pode ser referenciado. Proteo (protection) a capacidade de um programa impedir que os dados1 de um subprograma sejam modificados de forma no prevista no prprio subprograma. Nas linguagens de programao convencionais, como Pascal ou COBOL, essas propriedades so decorrentes da estrutura hierrquica do programa, no havendo mecanismos que permitam atribu-las de maneira seletiva. Por exemplo: uma varivel global visvel em todos os subprogramas enquanto que uma varivel local visvel apenas no subprograma onde definida. No dado nenhum tipo de proteo a uma varivel global. medida que o porte e a complexidade dos sistemas aumentam, a aplicao das tcnicas de programao estruturada pode conduzir a estruturas com centenas de subprogramas. Nessas dimenses, problemas no s de desenvolvimento mas, principalmente, de manuteno assumem propores dramticas. Para ilustrar esse tipo de problema, vamos examinar o que ocorre com uma conta naquele programa para automao bancria estruturado da forma descrita na seo 1.2. No nvel mais baixo da estrutura, diferentes subprogramas manipulam os dados da conta, que criada no subprograma de manuteno de cadastros, recebe lanamentos nos subprograma de movimentao de caixa e caixa automtico e pode ser consultada por qualquer subprograma. Isso significa que, para verificarmos como o programa implementa a manuteno de uma conta, ao longo de toda sua existncia no sistema, precisamos examinar
Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

e entender todo o cdigo em que os dados da conta so visveis, o que pode significar o entendimento de uma grande parte do programa, seno todo ele. Uma modificao aparentemente simples, como a incluso de um novo atributo, por exemplo, pode produzir efeitos colaterais indesejveis, provocados pela falta de proteo adequada, inclusive em subprogramas que nem tenham sido alterados. Modificaes mais complexas, como a criao de contas especiais com limites de saques negativos, por exemplo, exigem alteraes em vrios subprogramas, com grande risco de afetar o comportamento do programa em situaes desvinculadas do motivo da alterao. Resumindo, os principais problemas so: (i) a separao entre dados e funes; (ii) a disperso de funes interrelacionados por diversos subprogramas; e (iii) a falta de isolamento entre diferentes funes do programa. As tcnicas de orientao a objetos visam, em ltima instncia, resolver esses problemas atravs de uma nova forma de modularizao, com visibilidade e proteo apropriadas, que resulte em programas mais fceis de desenvolver e manter. Observe que, na anlise feita anteriormente, a unidade principal uma conta e no um subprograma. Afinal, uma conta possui existncia concreta no mundo real, e sobre ela que recaem as atenes do usurio e, eventualmente, a necessidade de alguma modificao no programa. Num programa orientado a objetos uma conta seria um de seus objetos. 1.4. Ocultamento de Informao e Encapsulamento2 Ocultamento de informao [Parnas72] e encapsulamento [Snyder86] so dois conceitos fundamentais em orientao a objetos, relacionados s noes de visibilidade e proteo vistos na seo 1.3 Ocultamento de informao (information hiding) o critrio para modularizao de programas onde cada mdulo (subprograma) caracterizado pelo conhecimento de uma deciso de projeto, que escondida de todas as outras partes do programa, e sua interface revele o mnimo possvel sobre seu funcionamento interno. Encapsulamento (encapsulation) a tcnica para agregao das partes de um subprograma (dados e cdigo) numa forma que seja tratada como uma unidade indivisvel pelas demais partes do programa. De acordo com o princpio do ocultamento de informao, a utilizao de um subprograma (ou mdulo) deve exigir que se conhea apenas sua interface externa, num nvel de abstrao mais elevado. O encapsulamento, por sua vez, impede que as partes internas de um subprograma sejam manipuladas diretamente por outras partes do programa. Para isso necessrio o controle tanto da visibilidade como do nvel de proteo, de cada elemento do programa. Para uma melhor compreenso desses conceitos vamos aplic-los ao programa para automao bancria da seo 3.2, conforme a seguir. Podemos criar um novo subprograma reunindo todas os servios necessrios para a manuteno de uma conta pelo sistema: abertura da conta, depsitos, saques, etc. Qualquer subprograma que manipule uma conta passa a faz-lo, obrigatoriamente, atravs de chamadas a esse novo subprograma. Com isso, todo o cdigo necessrio para implementao das contas reunido num nico local. A forma como feita essa implementao fica oculta para o restante do programa e isolada das demais partes do programa. Dizemos que a implementao das contas est oculta e encapsulada no novo subprograma. As vantagens dessa alternativa para a manuteno do sistema so evidentes. A figura 1.4 apresenta a estrutura do programa nesse novo contexto. Podemos aplicar esse conceito em programas escritos mesmo numa linguagem baseada em procedimentos, tal como Pascal ou Cobol-85, utilizando sub-rotinas com listas de argumentos variveis ou subprogramas com mltiplos pontos de entrada, por exemplo. As linguagens orientadas a objetos, por sua vez, fornecem o suporte necessrio de forma transparente para o programador, alm de outros
Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

recursos importantes, a serem vistos nos prximos captulos.

Fig. 1.4 - Diagrama de Estrutura usando Ocultamento de Informao. 1.5. Tipos Abstratos de Dados e Interfaces Linguagens de programao tradicionais, como Pascal e C, definem alguns tipos de dados com diferentes domnios, como nmeros inteiros e cadeias de caracteres, e algumas operaes vlidas para cada um desses tipos. Por exemplo, nmeros inteiros definidos entre 2.147.483.648 e 2.147.483.647, para os quais so vlidas as operaes de soma, subtrao, multiplicao e diviso. Esses tipos de dados so suficientemente genricos para que possamos representar os dados de nossas aplicaes em variveis desses tipos. Por exemplo, para armazenar um nmero de conta corrente utilizamos uma varivel do tipo inteiro, ainda que no possam existir nmeros de conta negativos, todo nmero de conta tenha um dgito verificador e a soma de nmeros de conta no faa sentido algum para a aplicao. Tipos abstratos de dados [Liskov74] permitem definirmos novos tipos de dados mais apropriados para uma determinada aplicao, especificando os domnios e operaes vlidas para cada tipo. Tipo abstrato de dados - TAD (abstract data type - ADT) uma classe de objetos (ou itens de dado) que completamente caracterizada pelas operaes que podem ser realizadas com esses objetos. Uma caracterstica essencial de um tipo abstrato de dados a independncia entre sua especificao e sua implementao, conforme ilustrado atravs da figura 3.5(a). A especificao se restringe ao mnimo necessrio para que seja utilizado, ou seja, a forma de chamada (sintaxe) e o significado (semntica) de cada operao prevista para o mesmo. A implementao de um TAD, por sua vez, define uma estrutura de dados que o represente e os algoritmos utilizados para realizar as operaes previstas. Uma especificao de um tipo abstrato de dados, portanto, pode possuir diversas implem entaes, todas com o mesmo comportamento observvel externamente.
Tipos Abstratos de Dados

Especificao

Implementao

Sintaxe (assinatura)

Semntica

Representao (estrutura de dados)

Algoritmos

Fig. 1.8 - Estrutura de um Tipo Abstrato de Dados

Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

Um tipo abstrato de dados proporciona, ao mesmo tempo, o ocultamento de informao e o encapsulamento de sua implementao. A visibilidade de seus objetos restrita sua interface, conforme definida a seguir, e sua implementao protegida das demais partes do programa. Interface (interface) a especificao das operaes que caracterizam o comportamento de um tipo abstrato de dados. Poderamos, por exemplo, definir a seguinte interface para um tipo abstrato de dados NumConta, especfico para nmeros de contas correntes: criaNmeroDeConta(int n) - converte o nmero inteiro n num item de dado do tipo NumConta; char calculaDgitoVerificador() - fornece um caracter contendo o dgito verificador do nmero da conta, de acordo com a regra de clculo adotada pelo Banco; String formataNmeroDaConta() - produz uma cadeia de caracteres com os dgitos significativos do nmero da c onta seguido do seu dgito verificador, separados por "". Um tipo abstrato de dados garante que somente essas operaes podem ser executadas sobre um nmero de conta. A implementao dessas operaes permanece oculta para o restante do programa e protegida contra manipulaes indevidas. Erros de programao comuns, como a atribuio de um valor inteiro qualquer, que no seja um nmero de conta vlido, a uma varivel definida para armazenar o nmero de uma conta, podem ser detectados ainda na fase de compilao do programa, como ilustrado atravs do exemplo seguinte. Sem uso de TAD:
int conta; int cont=0; ... conta++; // numero da conta corrente // contador qualquer // incrementa numero da conta !! ao invs // de incrementar o contador, porm // ... compila OK, gerando BUG no programa !

Usando TAD:
NumConta conta; // numero da conta corrente int cont=0; // contador qualquer ... conta++; // operao invlida para o tipo NumConta // e o compilador acusa o erro

Fig. 3.5(b) - Encapsulamento e Proteo do TAD

Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

1.6. Um Exemplo de Programa Orientado a Objetos As tcnicas de orientao a objetos induzem, naturalmente, ao uso generalizado de tipos abstratos de dados. Isso altera radicalmente a estrutura do programa, se comparada com aquela estrutura hierrquica clssica da programao estruturada. Voltando ao exemplo da seo 3.2, e supondo que um cliente possa manter contas em vrias agncias e que uma conta possa ser movimentada por vrios clientes, como ficaria a estrutura do nosso programa se utilizssemos tipos abstratos de dados para contas, clientes e agncias, encapsulando todas as funes relacionadas com esses objetos ? fcil perceber que no possvel estabelecer uma relao hierrquica entre contas, agncias e clientes. Temos agora relacionamentos no hierrquicos entre instncias de tipos abstratos de dados ou, mais precisamente, uma rede de associaes entre objetos da aplicao. A Figura 3.6 apresenta um pequeno diagrama, denominado "diagrama de classes", representando tais associaes.

Fig. 3.6 - Exemplo de Diagrama de Classes Nos captulos seguintes sero apresentados, com detalhes, outros conceitos necessrios para a correta interpretao dos diagramas de classes. Por ora, suficiente perceber que a passagem da programao estruturada para a programao orientada a objetos vai alm do aprendizado de uma nova linguagem de programao. preciso, antes de tudo, adotar um novo ponto de vista ao analisarmos um problema de programao, passando a enxergar objetos numa rede de colaboraes ao invs de procedimentos organizados hierarquicamente. 1.7. Um Breve Histrico das Linguagens Orientadas a Objetos A primeira linguagem de programao a implementar o conceito de classes, com o encapsulamento de dados e funes, foi Simula-67 [Dahl70] que considerada a precursora das linguagem orientadas a objetos. Smalltalk-72 [Ingalls78], Ada [DoD83], C++ [Stroustrup86] e Eiffel [Meyer88] foram alguns desenvolvimentos importantes baseados nessa linguagem. Smalltalk-72 foi de grande importncia para a difuso da programao orientada a objetos por ter sido a primeira, desse tipo, de uso geral e destinada a computadores pessoais. A linguagem Ada resultou de uma iniciativa do Departamento de Defesa Norte americano (DoD) visando a adoo de uma linguagem padro para desenvolvimento de sistemas. Conserva caractersticas tambm de uma linguagem baseada em procedimentos, sendo uma linguagem de uso geral rica em recursos para desenvolvimento de sistemas em tempo real. A linguagem C++ incorpora recursos de orientao a objetos mantendo a compatibilidade com o padro ANSI C j existente. Essa dualidade foi necessria em vista da enorme quantidade de programas em C j existentes e que no so orientados a objetos, porm tornou a programao em C++ menos segura do que numa linguagem 100% orientada a objetos. A principal caracterstica da linguagem Eiffel, que a diferencia daquelas citadas anteriormente, ser aplicvel tambm s fases de anlise e projeto de sistemas, oferecendo suporte a metodologia conhecida como "projeto por contrato"3. Ao contrrio de Smalltalk, Ada, C++ e outras linguagens com padres ANSI/ISO definidos, o desenvolvimento da linguagem Eiffel ainda controlado por um pequeno consrcio, liderado pela empresa de seu criador. Talvez por isso, sua utilizao ainda seja relativamente restrita. A linguagem Java, criada em 1995 pela empresa Sun Microsystems, representa uma nova gerao de linguagens orientadas a objetos, derivada de C++. Se coloca como uma alternativa mais segura que C++, por manter uma forte semelhana com ela porm inteiramente aderente aos princpios de orientao a objetos. Outra caracterstica importante,
Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

10

responsvel por sua rpida popularizao, sua adequao ao desenvolvimento de sistemas distribudos e sua integrao com a Internet, onde largamente empregada. Assim como ocorreu com a linguagem C, outras linguagens importantes baseadas em procedimentos, como Pascal e COBOL, j possuem suas extenses orientadas a objetos. Uma das motivaes iniciais que contriburam para promover o interesse pelas linguagens orientadas a objetos foi a maior possibilidade de reutilizao de software oferecida pelas mesmas, atravs de bibliotecas de classes e "frameworks" orientados a objetos. A programao de interfaces grficas (GUI) em ambientes do tipo Windows um dos exemplos mais comuns de aplicao dessas tcnicas. As chamadas linguagens visuais, como VisualBasic e Delphi (derivada de Pascal), por exemplo, utilizam intensivamente essa tecnologia. Tal como ocorreu com a programao estruturada, cujos fundamentos originaram metodologias estruturados de anlise e projeto de sistemas, os conceitos de orientao a objetos se propagaram para todas as fases do ciclo de vida do software. As metodologias de Coad-Yourdon (OOA e OOD) [Coad91], Booch [Booch91] e OMT [Rumbaugh91] so alguns exemplos de mtodos de anlise e projeto orientados a objetos, que esto substituindo rapidamente as metodologias estruturadas . Em 1997 foi concluda uma proposta de notao para modelos de sistemas orientados a objetos denominada UML (Unified Modeling Language) [Rational97], que vem se firmando como um padro de fato. Diferentemente das tcnicas estruturadas, que tiveram sua influncia limitada aos mtodos de desenvolvimento de software, a tecnologia de objetos j alcana as reas de interfaces homem-computador, bancos de dados, sistemas distribudos e sistemas operacionais. Bancos de dados orientados a objetos, que se integram de forma mais natural s novas linguagens orientadas a objetos, j constituem uma alternativa aos bancos de dados relacionais, principalmente em aplicaes que manipulam estruturas de dados complexas como, por exemplo, na rea de projetos de engenharia (CAD). Os principais ambientes de sistemas distribudos, como CORBA [OMG96] e DCOM, j foram projetados visando o suporte a aplicaes orientadas a objetos. Todos esses fatos apontam na mesma direo: a tecnologia de objetos est cada vez mais presente no cotidiano do desenvolvimento de software. A sua compreenso , portanto, essencial para todos que pretendam participar ativamente desse jogo, sejam profissionais ou usurios da rea de Informtica.

1.8 Associaes entre classes

Uma associao um relacionamento entre classes. Associao um meio de comunicao entre objetos das classes envolvidas. O objetivo de uma associao descrever a relao semntica existente entre instncias destas classes. Uma associao e representada por uma linha slida entre as classes envolvidas no relacionamento, conforme a figura 1.8.

Figura 1.8: Notao de uma associao em detalhes. O nome da associao elucida o significado da relao. A cardinalidade estabelece quantidades de instncias que podem participar da relao. Objetos ligados pela associao desempenham papis que podem ser esclarecidos, caso considerado conveniente.

No mundo real, alunos matriculam-se em cursos. Esta relao modelada conforme a associao exibida na figura 1.9. O nome Matrcula ressalta o significado da associao, no e
Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

11

obrigatrio. A cardinalidade indica que um aluno pode estar matriculado em um curso e no em mais do que um. Ou seja, pode ser que tenhamos um dado aluno, em dado instante de tempo, que no esteja matriculado em um curso. Por outro lado, dado um objeto da classe Curso, podem existir zero ou mais instncias da classe Aluno associados. As instncias de uma associao so denominadas de ligaes. Ou seja, o modelo registra um possvel cenrio no qual, em determinado instante, um objeto da classe Curso est ligado a vrios objetos da classe Aluno. Nestas ligaes, os objetos da classe Alunos desempenham o papel alunos, enquanto o objeto da classe Curso desempenha o papel curso. (No faa como neste exemplo, se o papel fornecido bvio, simplesmente no o fornea.)

Figura 1.9: Relacionamento semntico entre classes registrado atravs de uma associao.

Para que uma associao seja utilizada por um objeto necessria a existncia de atributos que implementem a associao. Por exemplo, sabemos que um curso formado por zero ou mais alunos, ou seja, dado um curso, desejamos saber quais os alunos correspondentes. Uma possibilidade de realizao da associao manter um atributo que seja uma coleo de alunos. No modelo UML, contudo, nem sempre uma associao descrita juntamente com os atributos correspondentes. Quando os atributos so fornecidos tem-se uma redundncia. Alternativamente, algum poderia descrever os atributos e no estabelecer uma associao entre as classes. Neste caso, qual seria a forma mais indicada? A resposta depende do contexto. A associao deve ser fornecida quando for relevante para a legibilidade e a compreenso do modelo. fcil perceber que a relao entre um aluno e um curso informao til para um sistema de controle acadmico. 1.8.1 Associaes reflexivas Em uma associao reflexiva os extremos da associao so uma mesma classe conforme a figura 1.10. Toda pessoa possui um pai e uma me. O modelo, contudo, contentase com pessoas para as quais os pais no esto estabelecidos. Ou para as quais apenas o pai ou a me conhecido(a).

Figura 1.10: Duas associaes reflexivas annimas. Os papis so denominados de pai e me, ambos private. Estas associaes definem o parentesco de uma pessoa. Para cada pessoa teremos uma instncia de Pessoa que representa o pai e outra para a me.

Uma instncia da classe Pessoa pode estar ligada a vrias instncias desta classe pois um dos extremos da associao no explicitamente fornece a cardinalidade e, neste caso, o padro e *, ou seja, zero ou mais. Quando uma associao possui uma seta em uma das extremidades a orientao da seta indica a navegabilidade. Noutras palavras, de uma instncia de pessoa possvel identificar o pai e a me da pessoa em questo, caso sejam estabelecidos. Por outro lado, dada uma pessoa, mesmo que esta possua vrios filhos, no possvel identificar com facilidade a prole do indivduo.
Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

12

Se a associao no possui uma orientao ento esta dita bidirecional. Se as associaes discutidas fossem bidirecionais, ento de uma pessoa que pai poderamos recuperar os filhos correspondentes de forma imediata. De acordo com o modelo, embora seja possvel identificar os filhos de determinada pessoa, esta informao trabalhosa de ser obtida, pois provavelmente teremos que percorrer todas as instncias de Pessoa. Por outro lado, dada uma pessoa, o parentesco obtido diretamente pelas associaes. 1.8.2 Agregao Uma associao estabelece um relacionamento entre classes. Quando uma instncia de uma classe contm instncias de outra classe a associao denominada de agregao. Ou seja, um objeto parte lgica de outro objeto. Em uma festa convencional varios convidados esto presentes. Imagine que h festa desde que venha pelo menos um convidado. A classe Festa est associada classe Convidado por uma agregao, denotada por um losango, conforme ilustra a figura 1.11.

Figura 1.11: Uma Festa uma agregao de Convidado, pelo menos uma instncia de Convidado. Felizmente, boa praa pode ser estar presente em vrias festas.

Outro exemplo segue na figura 1.12. Uma Unio pode dar origem a vrios filhos, cada um uma instncia de Pessoa. O relacionamento denominado de Prole captura esta semntica. O Casamento, por outro lado, pode ser visto como uma agregao de duas pessoas. Impossvel mais romantismo, devidamente registrado no modelo. Neste modelo as associaes no so bidirecionais. Ou seja, dado um objeto da classe Pessoa, no fcil identificarmos se o ser humano correspondente encontra-se casado ou o parentesco deste, embora tais informaes possam ser obtidas.

Figura 1.12: Viso romntica para a atualidade. Uma prole fruto de uma unio, um casamento uma unio entre apenas duas pessoas, supostamente de sexos opostos.

1.8.3 Composio Composio uma associao do tipo todo/parte, semelhana de uma agregao. Em uma composio, contudo, quando o todo criado as partes correspondentes so criadas, quando o todo destrudo, as partes deste todo so destrudas. Por exemplo, na figura 1.13, observa-se que Religio e uma composio de Devoto, o que denotado pelo losango hachurado.

Figura 1.13: Uma composio uma relao do tipo todo/parte rigorosa, no sentido em que a parte no existe sem o todo, assim como os membros de um corpo esto para o corpo humano correspondente. Conforme a figura, se h fiel, ento porque existe religio, uma composio de fiis.

Neste exemplo, h um relacionamento entre instncias de Devoto e de Religio. Em particular, dado o fato de se tratar de uma composio, o modelo ressalta que no existe instncia de Devoto sem uma correspondente instncia de Religio. Uma instncia de Religio
Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

13

pode estar ligada a vrios devotos e, em particular, talvez nenhum devoto. Conforme o modelo, se a religio de alguns devotos desaparecer, ento estes devotos desaparecem juntos. Observe que a opo entre agregao e composio pode no oferecer, em alguns casos, informao semntica de valor e, portanto, simplesmente faa opo pelo relacionamento que considerar mais natural. Por outro lado, h casos onde no deve pairar dvidas. Reunio uma agregao de Pessoa e no faria sentido ser uma composio. Por outro lado, Roupa pode ser modelada como uma composio de Boto, Tecido e outras partes conforme ilustra a figura 1.14.

1.8.4 Pacote
Se um modelo composto de um conjunto relativamente pequeno de classes, ento possivelmente at sejamos capazes de citar todas elas. Contudo, nem sempre o cenrio to simples. Mesmo que seja, medida que o tempo passar, outras classes sero criadas at o momento que ser impossvel gerenciar o imenso conjunto resultante. Pacote uma proposta que permite dividir classes em subconjuntos quando o conjunto delas no mais puder ser compreendido em sua totalidade pela mente humana. desta forma que possvel usufruir da grande quantidade de recursos oferecidos por bibliotecas que acompanham linguagens de programao como VB.NET e Java, por exemplo. Um pacote se assemelha a um escaninho. Se h organizao, ento existem vrios escaninhos e cada um deles tem o seu propsito, o que resulta em um cenrio onde encontrar uma classe desejada, por exemplo, e uma tarefa onde primeiro se identifica o pacote (escaninho) e, no interior deste, a classe de interesse.

Figura 1.14: Roupa uma composio de vrios elementos. Reunio uma agregao de pelo menos duas pessoas.

Na figura 1.15 vemos o pacote ensino. natural procurar por uma classe Estudante no pacote ensino. Contudo, a classe NotaFiscal definitivamente no deveria fazer parte deste pacote. (Seria como colocar o delicioso marrom-glac no mesmo compartimento dos produtos de higiene, junto com detergentes e o sabo neutro de coco em barra.)

Figura 1.15: Pacote o recurso empregado para organizar classes. Sistemas complexos podem ser compostos de grande nmero delas, o que fora a existncia de um mecanismo de classificao.

Em uma instituio de ensino ser natural fragmentar o nosso modelo orientado a objetos, composto por dezenas de classes ou mais, em pacotes que representam componentes semnticos do problema. Por exemplo, aquilo que diretamente diz respeito ao ensino pode ser depositado em um pacote de nome ensino. Elementos gerais, por outro lado,
Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

14

podem ser depositados no pacote escola. Esta organizao pode ser modelada conforme a figura 1.16 ilustra.

Figura 1.16: Pacotes e uma dependncia entre eles.

Nesta figura vemos dois pacotes. O pacote escola depende do pacote ensino. Isto significa que uma mudana em ensino pode provocar uma alterao em escola. Dependncia tema da seo seguinte. Aqui, o relevante observar a diviso do nosso modelo em dois pacotes e que um deles depende do outro. Embora nossa discusso tenha se restringido a pacote como um depsito de classes, um pacote pode conter qualquer outro elemento de uma modelagem, por exemplo, diagramas de interao e, inclusive, outros pacotes.

1.8.5) Dependncias
Uma dependncia um relacionamento no qual uma das partes exigida para a especificao ou implementao da outra. Conseqentemente, o elemento dependente deste relacionamento ter, provavelmente, que ser alterado quando ocorrer uma mudana no outro elemento. Por exemplo, na figura 1.17 a classe Pessoa depende das classes Data e String.

Figura 1.17: Se alguma alterao ocorrer com a classe Data ou a classe String, ento a classe Pessoa ter que ser analisada procura de mudana decorrente da anterior e que se faa necessria.

Embora o diagrama da figura 1.17 esteja correto, mais comum encontrar a relao entre estas classes conforme a figura 1.18. De fato, na verso esquerda, apenas a classe Pessoa esta presente. Quando se imagina que para um determinado contexto Data e String so conceitos perifricos, sem tanta relevncia, recomendado que no sejam representados como classes, conforme exibido no lado direito da figura 1.18. Outra alternativa, tambm vlida, mas neste ponto reconhecido como uma proposta de menor qualidade, a verso do lado direito. Neste caso optou-se por uma representao explcita de todas as classes. Observe que nesta verso so fornecidos os papis. Por exemplo, a instncia de Data associada a uma instncia de Pessoa desempenha o papel de nascimento, conforme o diagrama. De forma anloga, a instncia de String desempenha o papel de nome. Que no fiquem dvidas: todas estas alternativas esto corretas. A verso da esquerda da figura 1.18 oferece vantagens. Primeiro, no ressalta dependncias entre classes de domnios diferentes. A classe Pessoa um conceito relevante do contexto. As classes Data e String so apenas acessrias. Por ltimo, os relacionamentos ressaltados nos demais casos no acrescentam nenhuma informao relevante nem tornam o modelo mais atrativo e, portanto, podem ser preteridas em nome da simplicidade.

Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

15

Figura 1.18: Dois modelos equivalentes. Muitos preferem a verso da esquerda por simplicidade. Observe como os papis da verso da direita coincidem com os identificadores dos atributos da outra verso.

Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

16

2) Interfaces
Neste captulo apresentado o conceito de interfaces Java, sua aplicao no projeto de hierarquias de tipos e sua relao com hierarquias de classes. Ao final deste captulo o estudante dever compreender as diferenas entre interfaces e classes e ser capaz de interpretar e empregar corretamente o mecanismo de interfaces de Java. 2.1) O Conceito de Interface O conceito de interface se origina da Fsica, onde tem o seguinte significado: Interface: Superfcie que separa duas fases de um mesmo sistema. Fase: Parte homognea de um sistema heterogneo. Uma interface tem, portanto, a funo de separar duas partes de um mesmo sistema. Para isso a interface deve proporcionar um grau de isolamento controlado entre as partes, de modo a permitir a transio entre elas como partes de um mesmo sistema.

Fig 2.1 - Exemplos de Interfaces em Sistemas de Computao

Uma interface define um contrato. O contrato permite estabelecer um relacionamento entre o cliente e uma implementao de uma interface sem que o cliente seja dependente da implementao. O contrato descreve servios, que no so implementados pela interface, mas apenas especificados. Depender apenas desta especificao oferecer a liberdade para que vrias implementaes possam ser utilizadas, por exemplo ao longo do tempo, para um intacto cliente. A figura 1.19 mostra a interface Identificao contendo um nico mtodo. Observe o esteretipo <<Interface>> indicando que a notao de classe para ser interpretada como uma interface. Alternativamente pode-se empregar a notao da direita. Esta ltima, contudo, no to adequada quanto a anterior quando se deseja especificar os servios oferecidos pela interface. Qualquer classe que se propuser a implementar esta interface ter que implementar o mtodo getNome, que no recebe qualquer argumento como entrada e retorna uma String. Convm ressaltar que uma interface no oferece servios, apenas os especifica, ou seja, este mtodo s poder ser usufrudo com uma implementao que no fornecida na interface. Em tempo, no possvel criar instncias de interfaces! Continuando nossos exemplos extrados do meio de ensino, podemos estar interessados na identificao de uma avaliao ou instnciancia da classe Prova, de tal forma que pudssemos enviar a mensagem getNome para ob jetos desta classe. Para tal, indicamos, conforme a figura 1.20, que a classe Prova implementa a interface Identificacao.

Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

17

Figura 1.19: Interfaces descrevem colees de servios a serem oferecidos por quem se propuser a implementlos. A verso da esquerda adequada para se especificar o contrato registrado pela interface, enquanto a outra para estabelecer relacionamentos com quem implementa e quem faz uso da interface.

Figura 1.20: Uma interface seria de pouca utilidade se no fosse implementada. Acima a classe Prova implementa a interface Identificao.

Embora a classe Prova no inclua explicitamente o mtodo getNome, sabemos que o relacionamento entre esta classe e a interface Identificao faz com que esta classe possua, entre seus mtodos, uma implementao para getNome conforme descrito na interface. Outro exemplo apresentado na figura 1.21. A classe Nota implementa a interface Compara, cujo nico mtodo compareCom, recebe como argumento uma instncia de Object e retorna um inteiro. A nota fornece a semntica do mtodo. Em resumo, esta implementao torna possvel ordenar instncias de Nota, que no um tipo primitivo conhecido e, em Conseqncia, s quem o cria pode dizer se possvel ordenar valores deste tipo e, caso seja, como. A implementao deste modelo torna possvel a ordenao de notas por algoritmos que sequer sabem o que uma nota significa. Suponha que voc esteja interessado em implementar um algoritmo de ordenao baseado em comparaes nem sempre preciso fazer comparaes para ordenar. Voc tambm no gostaria que o seu algoritmo ordenasse apenas nmeros inteiros, mas tambm valores em ponto flutuante, assim como as notas de alunos, referncias bibliogrficas com base no ttulo destas referncias e assim por diante. Observe que para ordenarmos um conjunto de elementos no precisamos saber o que estamos ordenando, desde que seja possvel obter dois elementos do conjunto que se deseja ordenar, quaisquer que sejam eles, e perguntar para um deles qual a relao com o outro. O que precisamos para isto? Dois itens: (a) um array para guardar os elementos do conjunto que se deseja ordenar (b) que as instncias depositadas neste array sejam de uma classe que implementa a interface Compara. Isto suficiente!

Material compilado por Prof. Dr. Roberto Mendes Finzi Neto

Programao Orientada a Objetos

18

Figura 1.21: A classe Nota implementa a interface Compara.

A independncia entre algoritmos de ordenao e elementos que se deseja ordenar um grande benefcio. No apenas para este caso. O que se tornou independente foi a implementao de um servio, neste caso, qualquer classe. Mesmo aquelas que ainda no foram construdas no momento em que voc estiver lendo este texto podero ser ordenadas por cdigo j disponvel. Afinal, este cdigo depende apenas de uma interface e no de quem a implementa. Como ressaltar esta dependncia? A figura 1.22 ilustra uma classe que depende de e uma classe que implementa uma interface.

Figura 1.22: A classe QuickSort faz uso da interface Compara para classificar elementos, quaisquer que sejam estes, que implementam esta interface. A classe Nota implementa tal interface. No h nenhum erro com a anotao acima. Quando se usa o crculo, a classe que implementa a interface e indicada por um trao contnuo.

Material compilado por Prof. Dr. Roberto Mendes Finzi Neto