PADRÕES DE PROJETO.

GoF(Gang of Four) GRASP (General Responsibility Assignment Software Patterns).

PRINCÍPIOS DE PADRÕES DE PROJETO.

Princípio Aberto Fechado Entidades de software como classes, módulos e funções devem ser abertas para expansão, mas fechadas para modificações

Princípio Inversão de Dependência • “Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.”; • “Abstrações não deve depender de detalhes. Detalhes devem depender abstrações”.

Princípio Segregação de Interfaces “Os clientes não devem depender de interfaces que eles não usam”. Este princípio nos ensina a cuidar da forma que escrevemos nossas interfaces. Quando escrevemos as nossas interfaces, deve-se ter o cuidado de só acrescentar métodos que deveriam estar lá. Se acrescentamos métodos que não deveriam estar lá as classes que à implementam terão que implementar esses métodos. Por exemplo, se vamos criar uma interface chamada Trabalho e adicionar um método de intervalo para o almoço, todos os trabalhadores terão de implementá-lo. E se o trabalhador é um robô? Interfaces contendo métodos que não são específicas para isso são chamadas poluídas ou de gorduras interfaces. Devemos evitá-los.

Programe para uma interface, e não para uma implementação. Desta forma, você encapsula os códigos que podem variar para que futuras alterações não sejam complicadas e também forneça um único ponto de alteração. Esse princípio é a base de todos os padrões. O padrão strategy a utiliza.

Dê preferência para o “Tem um” à “é um”. “Dar prioridade e composição”. Padrões de projeto tendem a dar prioridade a utilização de composição, ela permite o controle dos objetos em “tempo de execução”, dinamicamente, enquanto heranças são estáticas e pouco flexíveis(“em tempo de compilação”) Lembre-se que composição é um tipo de associação(“UML”) bidirecional entre objetos instanciados, daí a manipulação ser em tempo de execução.

Encapsule o que varia Programe para interface à implementação. Dessa forma seu código estará preparado para o futuro de forma mais flexível e extensível.

Padrões de criação Abstract Factory Builder Factory Method Prototype Singleton

Abstract Factory Fornece uma interface para a criação de uma família de objetos relacionados ou dependentes, sem especificar suas classes concretas. Também é conhecida como “KIT”. Como possui escopo de objeto, manipula objetos em “tempo de execução(composição)” fornece interfaces para serem implementadas por classes que desejam criar seus objetos.

Builder Permite a separação da construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações. Um exemplo é a conversão em “tempo de execução” do um formato RTF. Se diferencia do Abstract Factory pela criação de objetos passo a passo, ao invés de criar todos os objetos de uma só vez.

Factory Método(Fabrica Virtual) Define uma interface para a criação de um objeto, mas deixa as subclasses decidirem qual classe a ser instanciada. permite postergar(deferir) a instanciação em subclasses. Em resumo, deixa as subclasses escolherem quais objetos criarem(através de herança). Esse padrão é o único voltado para o escopo classe, os demais são voltados para objeto. Lembrando que os escopo de classe são manipulados em “tempo de compilação(herança)” e os de objetos, em “tempo de execução(composição e delegação)”.

Prototype Especifica objetos a serem criados usando uma instância-protótipo e cria(clona) uma cópia a partir desse protótipo. Possui escopo de objeto, então, adiciona ou remove objetos em “tempo de execução”

Singleton Garante que uma classe tenha somente uma instância e fornece um ponto global de acesso a mesma.

Termos estudados Escopo Princípios Aberto/fechado, preferir composição, Dependência, programe para interfaces e encapsule o que varia. Orientação Padrões de criação Abstract Factory, builder, factory method, prototype e singleton.

Padrões estruturais Adapter Bridge Composite Decorator Façade Flyweight Proxy

Adapter(Wrapper) Converte interface de uma classe em outra interface, esperada pelo cliente. O Adapter permite que interfaces incompativeis trabalhem em conjunto. OBS: O adapter é o único padrão estrutural que trabalha com o ambos os escopos(Classe e objeto)

Bridge(Handle/body) Desacopla a abstração de sua implementação, de modo que as duas possam variar independentemente. Exemplo: Criar uma aplicação que funcione no windows e no linux. É indicado quando podemos ter várias implementações possíveis para uma abstração e vc deseja evitar o vínculo entre a abstração e sua da implementação.

Composite Compor os objetos em uma estrutura de árvore para representar uma hierarquia parte/todo. Exemplo: Aplicações gráficas que agrupam objetos simples para a partir daí formarem estruturas complexas(Paletas do photoshop ou do MS visio.)

Decorator(Wripper) Dinamicamente, adiciona nova responsabilidade a objetos

Facede Fornece uma interface unificada para um conjunto de interfaces de um subsistema. * É aplicável quando queremos fornecer uma única interface para um subsistema complexo. * Estruturar subsistemas em camadas. * Reduzir o acoplamento entre clientes e subsistemas.

Flyweight A intenção é usar o compartilhamento para suportar uma grande quantidade de objetos de granularidade fina. Use o Flyweight quando a quantidade de objetos foi muito grande.

Proxy Fornece um substituto(surrogate) ou um marcador da localização de um objeto para controlar o acesso a esse objeto. Exemplo: quando abrimos o word uma foto que exista na página 2 não precisará ser carregada se nós só precisarmos visualizar a pagina 1. A função do proxy é controlar a criação de objetos no momento que realmente é necessário.

Padrões de comportamento Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor

Chain of Responsibility Evita o acoplamento do remetente de uma solicitação ao seu receptor, ao dar a mais de um objeto a oportunidade de tratar a solicitação.Encadear os objetos receptores, passando a solicitação ao longo da cadeia até que algum objeto a trate. A Idéia desse padrão é desacoplar o remetente e receptor, dando a oportunidade a múltiplos objetos para tratar a solicitação.

Command(Action ou transaction) Encapsular uma solicitação como um objeto, desta forma permitindo que clientes parametrizem diferentes solicitações, enfileirem ou façam o registro (log) de solicitações e suportem operações que podem ser desfeitas.

Interpreter Dada uma linguagem, defina uma representação para sua gramática.

Iterator(Cursor) Fornece uma maneira de acessar seqüencialmente os elementos de um objeto.

Mediator Define um objeto que encapsula como um conjunto de objetos interage. Ao invés de cada os objetos se comunicarem entre sí, se comunicam com o mediator (Mediador) de forma centralizada, isso diminui o acoplamento de muitos objetos entre sí. Compare-o como um switch. Melhor exemplo é o DNS.

Memento(Token) Sem violar o encapsulamento,captura e externaliza o estado interno de um objeto de modo que ele possa ser restaurado posteriormente. Pense no memento como, como o recurso de salvar o estágio de um jogo para ser restaurado depois. Ele faz um snapshot do objeto. Interessante quando queremos implementar recursos de checkpoint e rollback.

Observer (Dependents, Publish-Subscribe) Define uma dependência um-para-muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes sejam atualizados.

State Permite a alteração do comportamento de um objeto quando seu estado interno é modificado.

Strategy(Policy) Define uma família de algoritmos, encapsula cada um deles para torná-los intercambiáveis, esse padrão permite que o algoritmo varie independente dos clientes que a utilizem. Lembre-se do princípio: “encapsular o que varia”.

Template method Define um esqueleto de um algoritmo em uma operação, postergando a operação de alguns passos para subclasses. Esse padrão permite que subclasses redefinam alguns passos sem mudar sua estrutura. Exemplo: em um algoritmo para fazer chá ou café teríamos o esqueleto de todos os passos comuns para fazer café e chá, deixando para subclasses apenas os passos “Adicione pó de café”, para a subclasse que implemente fazer café, e “Adicione pó de chá”, para a subclasse que implementa fazer chá. É boa prática usar a função “final” do java para evitar que o algoritmo seja alterado por subclasses.

Visitor Representa uma operação a ser executada sobre os elementos da estrutura de um objeto. Permite definir uma nova operação sem mudar as classes dos elementos sobre os quais opera.

DIVISÃO

Novos princípios Dependa de abstrações não de classes concretas. Princípio do conhecimento mínimo: “Só fale com seus amigos mais próximos”, Lembre-se do “facade” e do “mediator” Princípio Hollywood:”Não nos ligue, nós ligamos pra vc”. Ele evita o colapso de dependências. Faz com que módulos de alto nível controlem quando módulos de baixo nível serão chamados. Ex: Template method, Factory method, Observer.