Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos

Um objeto empacota dados e operações (métodos, procedimentos ou funções) que operam sobre eles. Um objeto executa tal operação quando recebe uma requisição (request, solicitação, mensagem) de um cliente. As requisições são a única maneira de executar operações, que por sua vez são a única maneira de modificar os dados. Chama-se isso de encapsulamento, onde os dados não podem ser acessados diretamente e são invisíveis do exterior do objeto.

Decompor um sistema em objetos não é fácil por conta de fatores como 1) encapsulamento, 2) granularidade, 3) dependência, 4) flexibilidade, 5) desempenho, 6) evolução, 7) reutilização, e assim por diante. Eles influenciam a decomposição e, com frequência, de formas conflitantes entre si.

A decomposição pode seguir abordagens diferentes, sabendo que sempre haverá desacordo sobre qual é a melhor:

Muitos objetos num projeto vem da fase de análise, mas novos objetos são necessários pois só são percebidos na fase de projeto. Tratam-se de objetos de mais baixo nível sem correspondência com o mundo real, tal como vetores. Outros podem estar num nível muito alto, como no padrão Composite, que introduz uma abstração para tratamento uniforme de objetos. A modelagem estrita do mundo real gera um sistema que condiz com a realidade atual, mas não necessariamente futura. Por isso, abstrações são a chave para torná-lo flexivel.

Os padrões de projeto ajudam a identificar tais abstrações e os objetos que podem capturá-las. O padrão Strategy implementa famílias de algoritmos intercambiáveis, mas esses não ocorrem na natureza. Também, o padrão State representa cada estado de uma entidade como um objeto, que não são percebidos durante a análise ou mesmo no estado inicial do projeto. Só ficam evidentes ao tentar tornar o projeto mais flexível e reutilizável.

Podemos usar objetos para representar coisas num nível micro, como peças do hardware, ou num nível macro como uma aplicação inteira. Padrões podem implementar a granularidade necessária. O Facade pode representar subsistemas completos como objetos. O Flyweight descreve como suportar enormes quantidades de objetos com granularidade mais fina. Para decompor um objeto em objetos menores, o Abstract Factory e o Builder disponibilizam objetos com a única responsabilidade de criar outros objetos. O Visitor e o Command disponibilizam objetos com a única responsabilidade de implementar uma solicitação em outro objeto ou grupo de objetos.

Uma operação (dependendo da linguagem method, function, procedure, etc.) tem um nome, parâmetros e retorno. Isso é o que chamamos de assinatura. O conjunto de todas as assinaturas define a interface.

Um tipo é um nome que identifica uma interface. Vários objetos podem compartilhar o mesmo tipo e um objeto pode acumular vários tipos. Nesse último caso significa que a interface do objeto terá um trecho com assinaturas esperadas por um tipo e outros trechos com assinaturas esperadas por outros tipos. Um tipo pode ser chamado de subtipo se tiver a mesma interface de um supertipo estabelecendo uma herança, onde o subtipo herda a interface do supertipo.

As interfaces são fundamentais em sistemas orientados a objetos porque é a única coisa que você saberá de um objeto. Não se sabe como é a implementação de cada objeto, de modo que dois objetos com mesma interface poderão ter implementações completamente diferentes.

Quando uma solicitação (mensagem) é enviada a um objeto ela tem como destino uma das operações presentes na interface dele. Dois objetos podem aceitar solicitações idênticas. É chamado de ligação dinâmica (dynamic binding) quando a definição de qual dos objetos será o receptor da solicitação ocorre durante o tempo de execução (runtime).

A ligação dinâmica permite que uma implementação em particular não fique presa a certo tipo de solicitação, porque ela poderá ser substituída por outra implementação. A isso chamamos de polimorfismo. Assim, você escreve programas que esperam por interfaces de objetos ao invés de objetos especificamente. Isso desacopla e simplifica a relação entre objetos e permite que eles variem seus inter-relacionamentos durante a execução do programa.

Os padrões de projetos ajudam a saber o que colocar e não colocar em uma interface. Também especificam o relacionamento entre interfaces.

Uma implementação de um objeto é definida por sua classe. Usando a modelagem OMT (Object Modeling Technique), uma classe é dada por um retângulo tendo o nome em negrito, as operações e os dados, cada um separado por linhas. Os tipos de retorno e das variáveis serão opcionais porque não é definida neste livro nenhuma linguagem de implementação.

Um objeto é uma instância de uma classe. Esse processo de instanciação aloca memória para os dados internos do objeto, variáveis da instância. Também associa as operações a estes dados.

Uma flecha tracejada indica que uma classe instancia objetos de outra classe. Ela aponta para a classe dos objetos instanciados.

Em uma herança de classe, temos na parte de cima a classe-mãe e embaixo a subclasse que conterá todas as operações e dados das classes ancestrais (mãe, avó, etc.) além dos que ela mesma definir. A representação se dá por uma linha vertical com um triângulo.

Uma classe abstrata é uma classe cuja finalidade principal é definir uma interface comum para suas subclasses. Ela pode delegar parte de, ou toda, sua implementação para as subclasses, de modo que ela mesma não poderá ser instanciada. As operações que uma classe abstrata declara mas não implementa são chamadas de operações abstratas. Classes que não são abstratas são chamadas de classes concretas.

Um comportamento implementado em uma classe abstrata pode ser redefinido, isto é, reimplementado, na subclasse.

Classes e operações abstratas tem seus nomes em itálico. Um pseudocódigo pode ser associado a uma operação através de uma caixa com canto dobrado conectada por uma linha pontilhada.

Uma classe mixin tem a intenção de oferecer uma interface ou funcionalidade opcional a outras classes. São semelhantes a classes abstratas por não poderem ser instanciadas. É exigido que a linguagem de programação suporte herança múltipla.

Compreender conceitos como objetos, interfaces, classes e herança é fácil quando comparado a aplicá-los na prática, construindo softwares flexíveis e reutilizáveis. Os padrões de projeto ajudam nisso.

Considere a diferença entre agregação e associação (em inglês, acquaintance, significando "conhecimento ou relacionamento social", mas sendo aqui a ideia de conhecimento de um objeto por outro).

A agregação consiste na relação um objeto tem, ou um objeto é parte de outro objeto. Exige que ambos nessa relação tenha o mesmo tempo de vida.

A associação implica na relação um objeto usa, ou seja, tem conhecimento de outro objeto. Embora um objeto que use outro possa solicitar operações, ele não é responsável pelo outro. Trata-se de um relacionamento mais fraco do que a agregação, com menor acomplamento entre os objetos.

Nos diagramas desse livro, associação é representada por uma flecha de linha cheia como na última figura, sobre composição de objetos. Logo abaixo você vê a representação de uma agregação, com uma flecha tendo um losango em sua base.

Associação e agregação são determinadas mais pela intenção do projetista do que por mecanismos da linguagem, visto que muitas delas não fazem distinção entre esses tipos de definição. Relacionamentos de agregação são em menor número e mais permanentes que associações. Associações são feitas e refeitas com muito mais frequência, algumas vezes existindo somente para a duração de uma operação.

O código não revelará tudo acerca de como o sistema funciona. Embora agregações sejam mais fáceis de serem percebidas por estarem no tempo de compilação, as associações, impostas pelo projetista ao invés de evidenciadas pela linguagem, vão requerer uma visão mais profunda.

Um bom ou mau projeto no quesito de relacionamento entre objetos é o que faz de uma estrutura algo bom ou ruim no tempo de execução. Muitos padrões (em especial os que tem escopos de objeto), capturam explicitamente a distinção entre estruturas de tempo de compilação e execução, por exemplo, Composite, Decorator, Observer, Chain of Responsability. As estruturas de tempo de execução estabelecidas por eles não serão claras a menos que você conheça tais padrões.

A chave para reutilização está na capacidade de antecipar as futuras mudanças que surgirão, para que o então sistema possa ir evoluindo atendendo os novos requisitos. Projetos que não levam isso em conta acabam tendo que passar por grandes reformulações, que acarretam em alto custo e exige uma retestagem de todo o sistema.

Padrões de projeto ajudam nesse ponto porque permitem variar algum aspecto da estrutura sem variar as demais. Seguem algumas causas comuns que levam a uma reformulação e quais padrões tratam essas causas

Ao usar padrões de projeto para contornar os casos acima você deve avaliar quão crucial a flexibilidade é para seu sistema. A seguir veremos o papel dos padrões em três grandes classes de software: 1) programas de aplicação, 2) toolkits e 3) frameworks.