Padrões Orientados a Objeto para a engenharia de software se tornaram um tema importante há vários anos. Os padrões passaram a ser populares com a publicação do criativo Design Patterns: Elements of Reusable Object-Oriented Software [GOF]. Este livro classificou vários padrões para o projeto de soluções extensíveis Orientadas a Objeto.

■ Pensando em Padrões

A primeira etapa crítica para tornar-se proeficiente no aprendizado de padrões é conhecer o vocabulário do domínio. Exige estudar material que abranja plenamente o assunto. O livro Design Patterns [GOF] é a base de grande parte da literatura subseqüente sobre padrões e deve ser uma opção de leitura de qualquer aspirante a arquiteto ou projetista de software. Mesmo com exemplos definidos usando OMT (predecessor do UML) e C++, este volume foi obviamente escrito para ensinar padrões a partir do zero. Há muitos outros recursos que podem oferecer ao leitor exemplos em Java, C# e UML para serem usados como suplemento dos exemplos existentes em Design Patterns [GOF].

Design Patterns [GOF] começa com um somatório incrível de benefícios do projeto orientado a objeto e a motivação para o uso de padrões. Depois, continua com um exemplo de aplicativo nos quais os padrões são incorporados no projeto. O exemplo indica um número de padrões do livro, colocando-os no contexto de uma solução de software. Como conhecer o vocabulário é apenas metade do caminho para a proficiência em padrões (a aplicação destes é a outra metade), este capítulo é crítico na educação do leitor em como aplicá-los. Depois de ler o exemplo e os padrões mencionados, o leitor poderá passar para as outras seções, sequencialmente, como faria com qualquer outro livro. Isto o ajudará a conhecer outros padrões e reforçará o que foi lido no exemplo.

Uma opção para conhecer os padrões é incluí-los em uma solução que esteja sendo desenvolvida durante a leitura do material sobre padrões. Essa solução pode ser um projeto feito dentro ou fora do seu ambiente de trabalho.

■ Definindo soluções

O uso de padrões para definir uma solução de software é uma tarefa analítica que exige pensamento abstrato. Existem vários padrões documentados que permitem a definição da estrutura e do comportamento da solução, em diferentes níveis de abstração: para a arquitetura da solução e para as estruturas contidas na solução.

    • Limites

    • Estrutura

    • Frameworks que dão suporte ao domínio - » Ler mais sobre frameworks.

■ Limites da solução

Conhecer os limites, é a primeira etapa para definir uma solução de software. Definir os limites do sistema acrescenta enfoque à solução, permitindo que seja projetada e desenvolvida. Sem limites claros, a solução será um alvo móvel e poderá mergulhar na ambiguidade.

Em geral, existem alguns requisitos de sistema, formais ou informais, provenientes de diferentes participantes, que servirão de base para derivar os limites da solução. Além de ter um conhecimento perfeito do propósito global da solução, os seguintes requisitos do sistema são críticos na definição dos limites: eventos externos que acionam a funcionalidade da solução e os processos externos dos quais depende a solução.

Considerado de modo holístico, esses requisitos permitem ao arquiteto definir o contexto da solução. Ter consciência dos eventos que desencadeiam o comportamento da solução e conhecimento dos dados que residem nas dependências da solução permitem ao arquiteto "normalizá-la", separando os objetos internos dos externos à solução. Entender os processos dos quais depende a solução permite ao arquiteto limitar o comportamento da solução, aproveitando aquele dos processos externos.

■ Estrutura de uma solução

Depois de os limites da solução estarem definidos, os arquitetos estará pronto para decidir como estruturar a solução. A estrutura da solução proporciona um entendimento conceitual do espaço da solução e deve ser definida com bastante antecipação no processo, pois esta é uma etapa crítica para a definição do framework arquitetural da solução que ajudará a garantir a consistência de toda a solução, com o objetivo de fazê-la mais extensível e de fácil manutenção.

Similarmente à definição dos limites de uma solução, existem vários requisitos de sistema que permitem aos arquitetos definir a estrutura da solução. Às vezes, esses requisitos poderão, aparentemente, se contradizer, e várias compensações terão de ser ponderadas. Importante: os padrões estruturais escolhidos para uma solução não devem acarretar a implementação de quaisquer tecnologias específicas. As tecnologias usadas para implementar a solução devem se basear na capacidade da tecnologia de atender aos requisitos do sistema, funcionais ou não, dentro da estrutura da solução definida.

Com os requisitos do sistema usados para definir os limites da solução, existem alguns outros requisitos que podem pesar sobre a estrutura da solução: requisitos de segurança, desempenho e transacionais

Os requisitos de segurança podem precisar do acréscimo de outros componentes à solução, os quais pode influenciar a sua estrutura definida. De forma similar, os requisitos de desempenho da solução talvez permitam ou proíbam a adição de elementos estruturais que possam sobrecarregá-la, assim como os requisitos transacionais, que talvez exijam partes adicionais da solução que possam afetar sua estrutura.

Algumas poucas publicações sobre arquitetura de software classificam diferentes padrões de arquitetura estrutural. Com base nos limites definidos dos sistemas e nos requisitos de sistema acima mencionados, o arquiteto pode selecionar a estrutura adequada à solução. É preciso notar que nem todos os padrões arquiteturais podem ser formalmente documentados e que a solução pode exigir uma variação em relação à atual.

Os exemplos a seguir descrevem os acionadores dos requisitos do sistema e como se aplicam aos diferentes padrões arquiteturais.

O padrão arquitetural "Camadas" (Layers) [POSA 1] poderá ser apropriado se os requisitos contiverem as seguintes provisões:

    ◊ Partes diferentes da solução podem ser conceitualizadas em diferentes níveis:

    • Se a solução for válida para reutilização em cada camada conceitual.

    • Se um protocolo comum puder ser usado para acessar os serviços contidos em cada camada.

    • A solução será exposta publicamente e deseja ocultar as complexidades da implementação.

    • Existem vários processos externos nos quais a solução possui dependências, exigindo adaptadores técnicos.

    ◊ Partes diferentes da solução podem ser conceitualizadas em diferentes níveis:O padrão arquitetural "Modelo-Visão-Controlador" (Model-View-Controller) [POSA 1] poderá ser apropriado, se os seguintes forem requisitos da solução:

    • A solução contém uma interface de usuário e deseja exibir objetos do mesmo tipo, em formatos diferentes.

    • A solução pode ser acessada por consumidores além de uma interface de usuário, como um processo externo.

    • Se a solução quiser expor os mesmos objetos (Modelo) para todos os consumidores.

Isto não deve implicar exclusão mútua dos padrões Modelo-Visão-Controlador e Camadas. Por exemplo, uma camada pública dentro de uma solução em camadas pode usar o padrão Modelo-Visão-Controlador para o consumidor da interface do usuário.

■ Frameworks de domínio

Depois de definida a estrutura da solução, a definição dos frameworks dentro dessa estrutura é o próximo esforço arquitetural que deve acontecer. Em soluções mais complexas, várias frameworks são necessários para preencher os requisitos funcionais.

Compreender os objetos e as relações no contexto do domínio do problema é a primeira etapa da definição dos frameworks de domínio. Para começar a definição dos objetos e das relações da solução, um bom lugar será o modelo de análise UML. Se o modelo de análise da solução ficar muito grande, ele poderá ser desdobrado em subdomínios. Cada subdomínio poderá prestar-se a um framework diferente.

Em Design Patterns [GOF] os padrões estão divididos em três categorias: estrutural, comportamental e de criação. Observar os requisitos da solução, sua estrutura arquitetural e os modelos de análise no contexto dessas categorias é uma boa forma de começar a definir os frameworks de domínio.

■ Padrões Estruturais

São utilizados para definir a composição de objetos e controlar o acesso aos subsistemas de objetos. Se utilizar o modelo de análise no contexto da estrutura da solução, o arquiteto pode começar a definir os frameworks no contexto dos padrões estruturais.

Os exemplos a seguir descrevem os prós e contras dos requisitos do sistema e como se aplicam aos diferentes padrões de projeto estrutural. Em oposição aos padrões arquiteturais que definem completamente uma solução ou subsistema, em geral existem vários padrões de projeto estrutural em um único framework.

    ◊ O padrão estrutural Composição (Composite) [GOF] poderá ser aplicável se o domínio contiver as seguintes relações:

    • Objetos do mesmo tipo (subclasse) estão contidos em objetos desse mesmo tipo em uma estrutura hierárquica.

    • Desejamos tratar partes da hierarquia ou de modo independente, em alguns cenários, ou combinadas, em outros.

    ◊ O padrão estrutural Fachada (Façade) [GOF] poderá ser aplicável:

    • Se o subsistema for significativamente complexo e os detalhes tiverem de ser abstraídos para o consumidor.

    • Se os requisitos do sistema indicarem que o subsistema pode ser implantado em um servidor remoto, fazendo com que a interface fique remotamente exposta.

■ Padrões Comportamentais

Padrões comportamentais referem-se a algoritmos e comunicações entre objetos. Os padrões comportamentais abordam questões como: quais comportamentos aplicam-se a qual estado do objeto e qual algoritmo aplicam-se a um determinado objeto em um dado contexto.

    ◊ O padrão comportamental Estado (State) [GOF] seria uma boa adição a qualquer estrutura se:

    • Houver mudança de comportamento do objeto com base no seu estado.

    • Os consumidores acessam o objeto por meio de uma fachada sem estado, e a aplicabilidade de um método exposto pela interface deve ser determinada no tempo de execução.

    ◊ O padrão comportamental Estratégia (Strategy) [GOF] seria uma boa adição a qualquer estrutura se:

    • O objeto desejar expor uma interface estática e determinar qual algoritmo executar, com base em um critério definido no tempo de execução.

■ Padrões de Criação

Referem-se à instanciação de objetos. Os padrões de criação concentram-se na composição de objetos complexos e no encapsulamento do comportamento de criação.

    ◊ O padrão estrutural Construtor (Builder) [GOF] poderá ser aplicável se:

    • Um objeto exigir representações diferentes em contextos diferentes. O padrão comportamental Singleton [GOF] seria uma boa adição a qualquer estrutura se:

    • Uma única instância de um objeto fosse necessária.

  Ir para Padrão de Criação