Utilizando UML e Padrões - Parte II

Definindo um Objeto

A definição de um objeto precisa levar em consideração informações e comportamento. Cada objeto define três tipos básicos de informações e dois tipos de comportamento.

Informações

Primeiro, um objeto precisa descrever as características de uma entidade que permitirão aos usuários do objeto distingui-lo dos outros objetos. Ele precisa ter uma identidade. Mesmo que dois objetos compartilhem as mesmas características, cada objeto possui uma identidade.

Segundo, um objeto precisa ser capaz de descrever a si mesmo. Um livro possui um título, autor, ISBN e preço e contém páginas e capas. Esse tipo de informação normalmente é chamado de estrutura, a informação usada para criá-lo.

Terceiro, cada objeto precisa ser capaz de descrever sua condição atual, chamado de estado. O estado do objeto às vezes é representado por valores de cada uma de suas características. Por exemplo, a capa de um livro poderia ser nova ou muito antiga. Outras vezes, o estado é representado pela presença ou ausência dos principais relacionamentos com outros objetos. Por exemplo, um livro pode ser reservado ou solicitado. Um livro reservado possui um relacionamento com a pessoa que o reservou. Às vezes, um único código de status representa o estado de um objeto. Porém, mais frequentemente, esse código de status representa uma combinação exclusiva de valores de característica e relacionamento que, juntos definem a condição atual do objeto.

Em alguns casos, um objeto pode até mesmo conter um quarto tipo de informação. Alguns objetos são criados simplesmente para manter e proteger informações geradas pelo sistema. O objeto não cria nem sequer possui realmente a informação. Ele é responsável pela informação, um repositório. Por exemplo, os arquivos de log registram eventos que ocorrem durante a execução de uma aplicação. O arquivo de log não cria a informação. A informação não descreve o arquivo de log nem seu estado. O arquivo de log simplesmente oferece um local para armazenar a informação até que alguém a solicite.

Nem toda característica de um objeto define seu estado. Por exemplo, o nome do autor de um livro não afeta sua condição. Ele é simplesmente um fato sobre o livro.

Assim, para que um objeto seja útil, ele precisa saber:

- Sua identidade única.

- Como descrever-se.

- Sua condição ou estado atual.

Comportamento

Criamos objetos para representar entidades do mundo real porque precisamos fazer algo. Por exemplo, a Editora Expertise contrata funcionários. A Expertise mantém registros sobre esses funcionários, para que possa acompanhar o progresso e compensar os funcionários liberalmente seus esforços.

A Expertise também deseja publicar, distribuir e vender livros. Para gerenciar os funcionários, a editora precisa conhecer o que os funcionários podem fazer. Eles podem trabalhar, candidatar-se aos cargos anunciados, revisar livros, adquirir novos autores, comercializar novos livros, obter revisores por contrato, assumir tarefas, usar um espaço de trabalho, tirar férias e fazer muito mais coisas que são importantes para o sucesso da empresa. Uma definição para cada comportamento trona-se parte da definição completa de um objeto funcionário, ou seja, a classe Funcionario.

Porém, os livros são um pouco diferente. Os livros não fazem nada por si próprios. A Expertise deseja fazer coisas com o livro. Ela deseja adquirir livros, revisar livros, imprimir livros, distribuir livros, revisar livros e vender livros. Na realidade, alguém está fazendo essas coisas com os livros.

Logo, por que a orientação a objetos nos diz para atribuir esses comportamentos ao livro, em vez de atribuí-los à pessoa que realmente realiza o

comportamento?

Essa técnica é a marca autenticada do enfoque orientado a objetos. Durante anos, os sistemas de software foram projetados com as informações sobre um objeto separadas do comportamento que utiliza o objeto. Para cada uso do objeto em um contexto diferente, normalmente havia um programa diferente. Infelizmente, essa técnica levou a alguns problemas sérios e dispendiosos. A saber, como muitos programas poderiam utilizar o mesmo objeto, era comum que eles exigissem alguns dos mesmos comportamentos. Assim, o mesmo comportamento era codificado em diversos programas sem garantias de que cada programa ditasse o comportamento da mesma maneira. Manter um objeto significava manter todo o código espalhado por todos os programas que utilizam esse objeto. A separação entre comportamento e a informação sobre o objeto resultou em descrições redundantes do comportamento, falta de integridade entre as muitas definições e alto custo para manter o código de programa redundante.

A orientação a objetos propôs que o comportamento deveria ser definido uma vez, não importa quem utiliza o comportamento, e que o comportamento deveria ser armazenado com o objeto. Usando essa técnica para organizar o código, qualquer um que queira saber como usar o objeto corretamente simplesmente examina os comportamentos definidos no próprio objeto. O benefício adicional dessa técnica é mais simples de codificar nos programas que utilizam o objeto. Em vez de escrever os comportamentos nos programas, os programas invocam comportamentos já definidos no objeto.

Assim, para que um objeto seja útil, ele precisa saber:

- O que ele pode fazer.

- O que pode ser feito com ele.

Encapsulamento

Encapsulamento é outro conceito que distingue a técnica de software orientada a objetos dos seus predecessores. O encapsulamento é um modo de organizar os muitos tipos de informações e comportamento descritos anteriormente de modo que os objetos possam ser usados da forma mais eficiente possível. O encapsulamento demonstra que, ao projetarmos um objeto, devemos separar o que sabemos sobre o objeto de acordo com dois conceitos:

- A informação mínima necessária para usar o objeto.

- A informação exigida para fazer com que o objeto funcione corretamente.

Esses dois conceitos nos levam a examinar o objeto de dois pontos de vista: uma visão externa, que pergunta apenas "O que eu posso fazer com esse objeto?" e uma visão interna, que pergunta "Como essa coisa funciona?"

Leia também