Introduo a Orientao a Objetos

O termo orientao a objetos pressupe uma organizao de software em termos de coleo de objetos discretos incorporando estrutura e comportamento prprios. Esta abordagem de organizao essencialmente diferente do desenvolvimento tradicional de software, onde estruturas de dados e rotinas so desenvolvidas de forma apenas fracamente acopladas. Neste captulo, as primeiras noes de orientao a objetos sero introduzidas. Esta breve viso geral do paradigma permitir entender melhor os conceitos associados programao orientada a objetos e, em particular, s construes da linguagem C ++.

Definies

Um objeto uma entidade do mundo real que tem uma identidade. Objetos podem representar entidades concretas (um arquivo no meu computador, uma bicicleta) ou entidades conceituais (uma estratgia de jogo, uma poltica de escalonamento em um sistema operacional). Cada objeto ter sua identidade significa que dois objetos so distintos mesmo que eles apresentem exatamente as mesmas caratersticas. Embora objetos tenham existncia prpria no mundo real, em termos de linguagem de programao um objeto necessita um mecanismo de identificao. Esta identificao de objeto deve ser nica, uniforme e independente do contedo do objeto. Este um dos mecanismos que permite a criao de colees de objetos, as quais so tambm objetos em si. A estrutura de um objeto representada em termos de atributos. O comportamento de um objeto representado pelo conjunto de operaes que podem ser executadas sobre o objeto. Objetos com a mesma estrutura e o mesmo comportamento so agrupados em classes. Uma classe uma abstrao que descreve propriedades importantes para uma aplicao e simplesmente ignora o resto.

Cada classe descreve um conjunto (possivelmente infinito) de objetos individuais. Cada objeto dito ser uma instncia de uma classe. Assim, cada instncia de uma classe tem seus prprios valores para cada atributo, mas dividem os nomes dos atributos e mtodos com as outras instncias da classe. Implicitamente, cada objeto contm uma referncia para sua prpria classe -- em outras palavras, ele sabe o que ele . Polimorfismo significa que a mesma operao pode se comportar de forma diferente em classes diferentes. Por exemplo, a operao move quando aplicada a uma janela de um sistema de interfaces tem um comportamento distinto do que quando aplicada a uma pea de um jogo de xadrez. Um mtodo uma implementao especfica de uma operao para uma certa classe. Polimorfismo tambm implica que uma operao de uma mesma classe pode ser implementada por mais de um mtodo. O usurio no precisa saber quantas implementaes existem para uma operao, ou explicitar qual mtodo deve ser utilizado: a linguagem de programao deve ser capaz de selecionar o mtodo correto a partir do nome da operao, classe do objeto e argumentos para a operao. Desta forma, novas classes podem ser adicionadas sem necessidade de modificao de cdigo j existente, pois cada classe apenas define os seus mtodos e atributos. No mundo real, alguns objetos e classes podem ser descritos como casos especiais, ou especializaes, de outros objetos e classes. Por exemplo, a classe de computadores pessoais com processador da linha 80x86 uma especializao de computadores pessoais, que por sua vez uma especializao de computadores. No desejvel que tudo que j foi descrito para computadores tenha de ser repetido para computadores pessoais ou para computadores pessoais com processador da linha 80x86. Herana o mecanismo do paradigma de orientao a objetos que permite compartilhar atributos e operaes entre classes baseada em um relacionamento hierrquico. Uma classe pode ser definida de forma genrica e depois refinada sucessivamente em termos de subclasses ou classes

derivadas. Cada subclasse incorpora, or herda, todas as propriedades de sua superclasse (ou classe base) e adiciona suas propriedades nicas e particulares. As propriedades da classe base no precisam ser repetidas em cada classe derivada. Esta capacidade de fatorar as propriedades comuns de diversas classes em uma superclasse pode reduzir dramaticamente a repetio de cdigo em um projeto ou programa, sendo uma das principais vantagens da abordagem de orientao a objetos.

Conceitos Bsicos

A abordagem de orientao a objetos favorece a aplicao de diversos conceitos considerados fundamentais para o desenvolvimento de bons programas, tais como abstrao e encapsulao. Tais conceitos no so exclusivos desta abordagem, mas so suportados de forma melhor no desenvolvimento orientado a objetos do que em outras metodologias.

Abstrao

Abstrao consiste de focalizar nos aspectos essenciais inerentes a uma entidade e ignorar propriedades ``acidentais.'' Em termos de desenvolvimento de sistemas, isto significa concentrar-se no que um objeto e faz antes de se decidir como ele ser implementado. O uso de abstrao preserva a liberdade para tomar decises de desenvolvimento ou de implementao apenas quando h um melhor entendimento do problema a ser resolvido. Muitas linguagens de programao modernas suportam o conceito de abstrao de dados; porm, o uso de abstrao juntamente com polimorfismo e herana, como suportado em orientao a objetos, um mecanismo muito mais poderoso. O uso apropriado de abstrao permite que um mesmo modelo conceitual

(orientao a objetos) seja utilizado para todas as fases de desenvolvimento de um sistema, desde sua anlise at sua documentao.

Encapsulao

Encapsulao, tambm referido como esconder informao, consiste em separar os aspectos externos de um objeto, os quais so acessveis a outros objetos, dos detalhes internos de implementao do objeto, os quais permanecem escondidos dos outros objetos. O uso de encapsulao evita que um programa torne-se to interdependente que uma pequena mudana tenha grandes efeitos colaterais. O uso de encapsulao permite que a implementao de um objeto possa ser modificada sem afetar as aplicaes que usam este objeto. Motivos para modificar a implementao de um objeto podem ser por exemplo melhoria de desempenho, correo de erros e mudana de plataforma de execuo. Assim como abstrao, o conceito de encapsulao no exclusivo da abordagem de orientao a objetos. Entretanto, a habilidade de se combinar estrutura de dados e comportamento em uma nica entidade torna a encapsulao mais elegante e mais poderosa do que em linguagens convencionais que separam estruturas de dados e comportamento.

O Modelo de Objetos

Um modelo de objetos busca capturar a estrutura esttica de um sistema mostrando os objetos existentes, seus relacionamentos, e atributos e operaes que caracterizam cada classe de objetos. atravs do uso deste modelo que se enfatiza o desenvolvimento em termos de objetos ao invs de mecanismos tradicionais de desenvolvimento baseado em funcionalidades, permitindo uma representao mais prxima do mundo real.

Uma vez que as principais definies e conceitos da abordagem de orientao a objetos esto definidos, possvel introduzir o modelo de objetos que ser adotado ao longo deste texto. O modelo apresentado um subconjunto do modelo OMT (Object Modeling Technique), proposto por Rumbaugh e outros1.1. OMT tambm introduz uma representao diagramtica para este modelo, a qual ser tambm apresentada aqui.

Objetos e Classes

Objeto definido neste modelo como um conceito, abstrao ou coisa com limites e significados bem definidos para a aplicao em questo. Objetos tm dois propsitos: promover o entendimento do mundo real e suportar uma base prtica para uma implementao computacional. No existe uma maneira ``correta'' de decompor um problema em objetos; esta decomposio depende do julgamento do projetista e da natureza do problema. Todos objetos tm identidade prpria e so distinguveis. Uma classe de objetos descreve um grupo de objetos com propriedades (atributos) similares, comportamento (operaes) similares, relacionamentos comuns com outros objetos e uma semntica comum. Por exemplo, Pessoa e Companhia so classes de objetos. Cada pessoa tem um nome e uma idade; estes seriam os atributos comuns da classe. Companhias tambm podem ter os mesmos atributos nome e idade definidos. Entretanto, devido distino semntica elas provavelmente estariam agrupados em outra classe que no Pessoa. Como se pode observar, o agrupamento em classes no leva em conta apenas o compartilhamento de propriedades. Todo objeto sabe a que classe ele pertence, ou seja, a classe de um objeto um atributo implcito do objeto. Este conceito suportado na maior parte das linguagens de programao orientada a objetos, tais como C ++. OMT define dois tipos de diagramas de objetos, diagramas de classes e diagramas de instncias. Um diagrama de classe um esquema, ou seja, um

padro ou gabarito que descreve as muitas possveis instncias de dados. Um diagrama de instncias descreve como um conjunto particular de objetos est relacionado. Diagramas de instncias so teis para apresentar exemplos e documentar casos de testes; diagramas de classes tm uso mais amplo. A Figura [pic] apresenta a notao adotada para estes diagramas. | | |[pic] | | | | | |[pic] | |[pic] | |Figura: Representao diagramtica de OMT para classes e objetos. Um diagrama de classe apresentado esquerda. Um possvel |diagrama de instncias apresentado direita. | |

O agrupamento de objetos em classes um poderoso mecanismo de abstrao. Desta forma, possvel generalizar definies comuns para uma classe de objetos, ao invs de repet-las para cada objeto em particular. Esta uma das formas de reutilizao e economia que a abordagem de orientao a objetos suporta.

Atributos

Um atributo um valor de dado assumido pelos objetos de uma classe. Nome, idade e peso so exemplos de atributos de objetos Pessoa. Cor, peso e modelo so possveis atributos de objetos Carro. Cada atributo tem um valor para cada instncia de objeto. Por exemplo, o atributo idade tem valor ``29'' no objeto Pedro Y. Em outras palavras, Pedro Y tem 29 anos de idade. Diferentes instncias de objetos podem ter o mesmo valor para um dado atributo. Cada nome de atributo nico para uma dada classe, mas no necessariamente nico entre todas as classes. Por exemplo, ambos Pessoa e Companhia podem ter um atributo chamado endereo. No diagrama de classes, atributos so listados no segundo segmento da caixa que representa a classe. O nome do atributo pode ser seguido por detalhes opcionais, tais como o tipo de dado assumido e valor default. A Figura [pic] mostra esta representao. | | |[pic] | | | | | |[pic] | |[pic] | |Figura: Representao diagramtica de OMT para classes e objetos com atributos. Um diagrama de classe com atributos apresentado | |esquerda. Um possvel diagrama de instncias com os respectivos valores apresentado direita. |

No se deve confundir identificadores internos de objetos

com atributos do mundo real. Identificadores de objetos so uma convenincia de implementao, e no tm nenhum significado para o domnio da aplicao. Por exemplo, CIC e RG no so identificadores de objetos, mas sim verdadeiros atributos do mundo real.

Operaes e Mtodos

Uma operao uma funo ou transformao que pode ser aplicada a ou por objetos em uma classe. Por exemplo, abrir, salvar e imprimir so operaes que podem ser aplicadas a objetos da classe Arquivo. Todos objetos em uma classe compartilham as mesmas operaes. Toda operao tem um objeto-alvo como um argumento implcito. O comportamento de uma operao depende da classe de seu alvo. Como um objeto ``sabe'' qual sua classe, possvel escolher a implementao correta da operao. Alm disto, outros argumentos (parmetros) podem ser necessrios para uma operao. Uma mesma operao pode se aplicar a diversas classes diferentes. Uma operao como esta dita ser polimrfica, ou seja, ela pode assumir distintas formas em classes diferentes. Um mtodo a implementao de uma operao para uma classe. Por exemplo, a operao imprimir pode ser implementada de forma distinta, dependendo se o arquivo a ser impresso contm apenas texto ASCII, um arquivo de um processador de texto ou binrio. Todos estes mtodos executam a mesma operao -- imprimir o arquivo; porm, cada mtodo ser implementado por um diferente cdigo. A assinatura de um mtodo dada pelo nmero e tipos de argumentos do mtodo, assim como por seu valor de retorno. Uma estratgia de desenvolvimento recomendvel manter assinaturas coerentes para mtodos implementando uma dada operao, assim como um comportamento consistente entre as implementaes. Em termos de diagramas OMT, operaes so listadas na terceira parte da

caixa de uma classe. Cada nome de operao pode ser seguida por detalhes opcionais, tais como lista de argumentos e tipo de retorno. A lista de argumentos apresentada entre parnteses aps o nome da operao. Uma lista de argumentos vazia indica que a operao no tem argumentos; da ausncia da lista de argumentos no se pode concluir nada. O tipo de resultado vem aps a lista de argumentos, sendo precedido por dois pontos (:). Caso a operao retorne resultado, este no deve ser omitido -- esta a forma de distingu-la de operaes que no retornam resultado. Exemplos de representao de operaes em OMT so apresentados na Figura [pic]. |[pic] | | |[pic] |Figura: Representao diagramtica de OMT para classes com atributos e operaes. | | | | |

Ligaes e Associaes

Ligaes e associaes so os mecanismos para estabelecer relacionamentos entre objetos e classes. Uma ligao uma conexo fsica ou conceitual entre duas instncias de objetos. Por exemplo, Pedro Y trabalha-para Companhia W. Uma ligao uma instncia de uma associao. Uma associao descreve um grupo de ligaes com estrutura e semntica comuns, tal como ``uma pessoa trabalha-para uma companhia.'' Uma associao descreve um conjunto de ligaes potenciais da mesma forma que uma classe descreve um conjunto de objetos potenciais. A notao de diagramas OMT para associao uma linha conectando duas classes. Uma ligao representada como uma linha conectando objetos. Nomes de associaes so usualmente apresentada em itlico. Se entre um

par de classes s existe uma nica associao cujo sentido deva ser bvio, ento o nome da associao pode ser omitido. A Figura [pic] apresenta um exemplo de diagrama OMT com associaes. | | |[pic] | | | | | |[pic] | |[pic] | |Figura: Representao diagramtica de OMT para associaes entre classes (topo) e ligaes entre objetos (abaixo). |

Alguns atributos podem dizer respeito a associaes, e no a classes. Para tais casos, OMT introduz o conceito de atributo de ligao. Quando a associao tem ainda operaes associadas, ento ela pode ser modelada como uma classe que est ``conectada'' associao. Um exemplo deste caso apresentado na Figura [pic]. | | |[pic] | | | |

| |[pic] | |[pic] | |Figura: Representao diagramtica de OMT para associaes entre classes com atributos. Neste caso, os atributos da associao esto| |representados atravs de uma classe explcita, Autorizao. O crculo preto no final da linha da associao indica que mais de um | |objeto de uma classe podem estar associados a cada objeto da outra classe. Um crculo vazado indicaria que possivelmente nenhum |

|objeto poderia estar associado, ou seja, o conceito de associao opcional. |

Agregao

Uma agregao um relacionamento do tipo ``uma-parte-de,'' nos quais objetos representando os componentes de alguma coisa so associados com objetos representando uma montagem. Por exemplo, o texto de um documento pode ser visto como um conjunto de pargrafos, e cada pargrafo um conjunto de sentenas (Figura [pic]). | |[pic] | | |[pic] |[pic] |Figura: Representao diagramtica de OMT para agregao. | | | | | | |

Agregao uma forma de associao com alguma semntica adicional. Por exemplo, agregao transitiva: se A parte de B e B parte de C, ento A parte de C. Agregao tambm anti-simtrica: se A parte de B, ento B no parte de A.

Generalizao e Herana

Generalizao e herana so abstraes poderosas para compartilhar similaridades entre classes e ao mesmo tempo preservar suas diferenas. Generalizao o relacionamento entre uma classe e um ou mais verses refinadas (especializadas) desta classe. A classe sendo refinada chamada de superclasse ou classe base, enquanto que a verso refinada da classe chamada uma subclasse ou classe derivada. Atributos e operaes comuns a um grupo de classes derivadas so colocadas como atributos e operaes da classe base, sendo compartilhados por cada classe derivada. Diz-se que cada classe derivada herda as caractersticas de sua classe base. Algumas vezes, generalizao chamada de relacionamento is-a (-um), porque cada instncia de uma classe derivada tambm uma instncia da classe base. Generalizao e herana so transitivas, isto , podem ser recursivamente aplicadas a um nmero arbitrrio de nveis. Cada classe derivada no apenas herda todas as caractersticas de todos seus ancestrais como tambm pode acrescentar seus atributos e operaes especficos. A Figura [pic] mostra a notao diagramtica de OMT para representar generalizao, um tringulo com o vrtice apontado para a classe base. Um discriminador pode estar associado a cada associao do tipo generalizao; este um atributo do tipo enumerao que indica qual a propriedade de um objeto est sendo abstrada pelo relacionamento de generalizao. Este discriminador simplesmente um nome para a base de generalizao.

| |[pic] | | |[pic] |[pic] |Figura: Representao diagramtica de OMT para generalizao. |

| | | | | |

Uma classe derivada pode sobrepor1.2 uma caracterstica de sua classe base definindo uma caracterstica prpria com o mesmo nome. A caracterstica local (da classe derivada) ir refinar e substituir a caracterstica da classe base. Uma caracterstica pode ser sobreposta, por exemplo, por questes de refinamento de especificao ou por questes de desempenho. Entre as caractersticas que podem ser sobrepostas esto valores default de atributos e mtodos de operao. Uma boa estratgia de desenvolvimento no deve sobrepor uma caracterstica de forma inconsistente com a semntica da classe base.

Sugestes de desenvolvimento

Na construo de um modelo para uma aplicao, as seguintes sugestes devem ser observadas a fim de se obter resultados claros e consistentes: 1. No comece a construir um modelo de objetos simplesmente definindo classes, associaes e heranas. A primeira coisa a se fazer entender o problema a ser resolvido. 2. Tente manter seu modelo simples. Evite complicaes desnecessrias. 3. Escolha nomes cuidadosamente. Nomes so importantes e carregam conotaes poderosas. Nomes devem ser descritivos, claros e no deixar

ambiguidades. A escolha de bons nomes um dos aspectos mais difceis da modelagem. 4. No ``enterre'' apontadores ou outras referncias a objetos dentro de objetos como atributos. Ao invs disto, modele estas referncias como associaes. Isto torna o modelo mais claro e independente da implementao. 5. Tente evitar associaes que envolvam trs ou mais classes de objetos. Muitas vezes, estes tipos de associaes podem ser decompostos em termos de associaes binrias, tornando o modelo mais claro. 6. No transfira os atributos de ligao para dentro de uma das classes. 7. Tente evitar hierarquias de generalizao muito profundas. 8. No se surpreenda se o seu modelo necessitar vrias revises; isto o normal. 9. Sempre documente seus modelos de objetos. O diagrama pode especificar a estrutura do modelo, mas nem sempre suficiente para descrever as razes por trs da definio do modelo. Uma explicao escrita pode clarificar pontos tais como significado de nomes e explicar a razo para cada classe e relacionamento. 10. Nem sempre todas as construes OMT so necessrias para descrever uma aplicao. Use apenas aquelas que forem adequadas para o problema analisado.