Padrões de Projeto (os Design Patterns), são combinações de classes e algoritmos associados que cumprem com propósitos comuns de projeto. São normalmente soluções consagradas que se baseiam nas estruturas da orientação a objetos em sua melhor forma.

 

Cada padrão descreve um problema no nosso ambiente e o cerne da sua solução, de tal forma que você possa usar essa solução mais de um milhão de vezes, sem nunca fazê-lo da mesma maneira.

 

 

 

Os padrões de projeto, basicamente, se dividem em grandes 3 categorias: Criacional, Estrutural e Comportamental.

 

São 4 os elementos importantes que definem um Padrão (Pattern), são eles:

 

 

Para se descrever e catalogar um Padrão de Projeto com total completude de informações, são necessários os seguintes dados:

 

 

Atualmente existem diversos catálogos de padrões já criados,  dentre os grandes, posso citar alguns aqui:

 

Os Patterns são oriundos de alguns princípios de programação, como por exemplo, o Design de Objetos, o que se torna algo complexo em projetos de software, já que muitos parâmetros estão implícitos neste conceito, como encapsulamento, granularidade, dependência, flexibilidade, desempenho, evolução e reutilização.

 

Muitos objetos oriundam da análise, e muitos destes não são abstrações do mundo real, como vetores por exemplo. Por outro lado, existem objetos que raramente aparecem durante a análise, e sim, aparecem para auxiliarem a fase de projeto. Logo, os padrões de projeto ajudam a identificar abstrações menos óbvias bem como os objetos que podem captura-las. Padrões como Composite (tratamento uniforme de objetos que não têm uma contrapartida física), Strategy (descreve como implementar famílias de algoritmos intercambiáveis) e State (representa cada estado de uma entidade como um objeto) são bastante úteis, como exemplo.

 

Objetos podem variar tremendamente em tamanho e número. Podem representar qualquer abstração. Os padrões de projeto auxiliam no tratamento da granularidade. Tem-se como exemplo:

 

Façade: Descreve como representar subsistemas completos como objetos;

 

Flyweight: Descreve como suportar enormes quantidades de objetos nos níveis de granularidade mais finos;

 

 

 

Um bom conceito O.O para se programar utilizando padrões de projeto é: “Programa para interfaces, nunca para uma implementação“.

 

Uma interface é o conjunto de assinaturas declaradas por um objeto, sendo que cada operação declarada (Assinatura) especifica o nome da operação, os objetos que ela aceita como parâmetros e o valor retornado por ela.

Um tipo é um nome usado para denotar uma interface específica. Quando um objeto tem um tipo “Janela”, significa que ele aceita todas as solicitações para as operações definidas na interface chamada “Janela”.

As interfaces são fundamentais para a programação orientada à objetos. Objetos devem ser conhecidos somente por suas interfaces e, quando uma mensagem é enviada a um objeto, a operação específica que será executada depende da “mensagem” e do objeto “receptor”. Na prática, significa que diferentes objetos que suportam solicitações idênticas, podem possuir diferentes implementações para atender estas solicitações, é o chamado Polimorfismo entrando em cena!

 

A associação em tempo de execução de uma solicitação a um objeto e a uma das suas operações é conhecida como ligação dinâmica (dynamic binding). Essa ligação auxilia o polimorfismo que por sua vez, simplifica as definições dos clientes, desacopla objetos entre si e permite a eles variarem seus inter-relacionamentos em tempo de execução. Os padrões de projeto auxiliam o uso do polimorfismo bem como o uso de interfaces, além de ajudarem a definir as interfaces pela identificação de seus elementos-chave e pelos tipos de dados que são enviados através das assinaturas das operaões contidas nas mesmas.

 

Classe do objeto (implementação) x Tipo do objeto (interface): um objeto pode ter muitos tipos, e objetos de diferentes classes podem ter o mesmo tipo;

 

Herança de classe x Herança de interface: a herança de classe define a implementação de um objeto em termos da implementação de outro objeto (é um mecanismo para compartilhamento de código e de representação), já a herança de interface descreve quando um objeto pode ser usado no lugar de outro.

 

Dado todo este contexto, uma outra dica O.O importante é: não declarar variáveis como instâncias de classes concretas específicas. Isso dá maior flexibilidade ao código e ajudará no polimorfismo.

 

As vantagens de se utilizar herança nos seus projetos O.O. basicamente são: simplicidade e rapidez na execução (definida em tempo de compilação) e que a mesma permite alterar com facilidade a implementação herdada (reuso).

 

Já entre as desvantagens, podemos citar: a herança não permite alterar a implementação herdada em tempo de execução e expõe para as classes descendentes, os detalhes da implementação, ferindo assim, o princípio do encapsulamento. A dependência da implementação herdada também prejudica no reuso das classes.

 

As vantagens da Composição basicamente são: os objetos são acessados somente através de suas interfaces, sem violar o encapsulamento e proporcionando independência de implementação, além do fato de que, com classes em que um número pequeno de heranças é usado e temos papéis bem definidos e focados, aumenta-se então, a capacidade de reutilização.

As desvantagens da Composição podem ser: como neste caso a herança diminuirá, e o número de objetos no sistema aumentará, e consequentemente, a performance do sistema que utiliza a composição dependerá de como será feito o inter-relacionamento entre esses  objetos.

 

 

 

É um princípio muito importante e que também é largamente utilizado nos Padrões de Projetos, se baseia no envolvimento de dois objetos ou mais objetos que visam atender a uma determinada solicitação (utiliza poderosamente a composição de objetos).

Exemplificando-se tem-se uma classe “Window” em “Rectangle”. Em vez de se fazer “Window” sub-classe de “Rectangle” (uma Janela é retangular!), ela reutilizaria o comportamento de “Rectangle”. Em vez de dizer que uma “Window” é um “Rectangle”, diremos então que uma “Window” possui um comportamento de um “Rectangle”.

A principal vantagem disso é que se “Window” em tempo de execução, quiser ter um comportamento de um “Circle” (círculo), basta utilizar uma instância de “Circle” assumindo que ambas tenham o mesmo tipo (interface).

Existem duas desvantagens: Um código dinâmico e altamente parametrizável é mais difícil de compreender e a performance é comprometida porque definir trocas em tempo de execução possuem um “overhead” da troca de contexto antes da execução propriamente dita.

Conclui-se que o uso da delegação é recomendável quando a mesma simplificar e não complicar o projeto.

 

 

 

 

 

Este padrão estrutural do GOF basicamente define um modelo no qual separa o conceito (definido pelas classes à esquerda) das suas implementações.

 

A herança é utilizada nas relações entre as classes Abstraction e RefinedAbstraction, na qual uma implementação do conceito é definida pelo seu tipo.

 

Temos herança também na relação entre a interface Implementor e suas implementações ConcreteImplementorA e ConcreteImplementorB. O propósito disto é dar flexibilidade na relação entre o conceitos e suas duas formas de implementações, configurando assim a relação de delegação polimórfica entre as duas estruturas definidas distintamente.

 

A composição se dá justamente nesta relação de delegação entre as duas interfaces Abstraction e Implementor, o que nos permite compor N combinações de novas abstrações (conceitos) com N tipos diferentes de comportamentos (implementações). Tal definição nos fornece então, a granularidade de objetos almejada para este propósito.

 

Podemos concluir então que, RefinedAbstraction pode invocar métodos, assumindo comportamentos, (representados por sua interface) tanto de ConcreteImplementorA ou ConcreteImplementorB.

 

Bom, neste ponto você já deve estar pensando que poderia muito bem fazer esta relação entre conceito <-> implementação simplesmente colocando as classes ConcreteImplementorA e ConcreteImplementorB como “herdeiras” de RefinedAbstraction, mas esta falta de separação te dará algumas dores de cabeça quando você necessitar incluir mais uma forma de implementação (ConcreteImplementorC, por exemplo), já que, para se adequar a isto, teria-se que modificar também a RefinedAbstraction, ou seja, o custo de manutenção, em um projeto real, vai aumentando exponencialmente e, certamente você não vai querer isso!

 

É isso aí pessoal, concluo o meu post aqui e, espero ter esclarecido em poucas palavras, o que são os padrões de projeto e os conceitos e definições que o envolvem.

 

Fiquem à vontade para comentar, tirar dúvidas ou sugerir melhorias.

 

Um grande abraço a todos e até o próximo post!

 

 

.