Padrões de Projetos

Padrões de Projetos

1. Comportamento

2. Criação

   • Factory Method
     • “Definir uma interface para criar um objeto, mas deixar as subclasses decidirem que classe instanciar. O Factory Method permite adiar a instanciação para subclasses.”
     • a principal vantagem em utilizar o padrão Factory Method é a extrema facilidade que temos para incluir novos produtos. Não é necessário alterar NENHUM código, apenas precisamos criar o produto e a sua fábrica.
     • Ele tem duas opções: criar uma estrutura relativamente grande para resolver o pequeno problema; ou criar um códigos gigante para criação de objetos. durante a implementação é necessário escolher qual tipo resolver melhor o seu problema
   • Abstract Factory
     • Fornecer uma interface para criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.”[
     • Como você pode notar, este padrão sofre do mesmo problema do Factory Method, ou seja criamos uma estrutura muito grande de classes e interfaces para resolver o problema de criação de objetos.
     • segundo o princípio da Segregação de Interface [2] isto é uma coisa boa, pois o nosso código cliente fica dependendo de interfaces simples e pequenas ao invés de depender de uma interface grande e que nem todos os métodos seria utilizados.
   • Builder
     • “Separar a construção de um objeto complexo de sua representação de modo que o mesmo processo de construção possa criar diferentes representações.”
     • separar em pequenos passos a construção do objeto complexo
     • o padrão Builder com o Abstract Factory e o Factory Method. Todos eles servem para criar objetos, além disse escondem a implementação do cliente, tornando o programa mais flexível. No entanto, no padrão Builder, não existe o conceito de vários produtos ou de famílias de produtos, como nos outros dois padrões.
     • no padrão Builder nós definimos quais os passos devem ser executados (na classe Builder) e como eles devem ser executados (na classe Director).
     • Um problema com o padrão é que é preciso sempre chamar o método de construção para depois utilizar o produto em si
   • Prototype
     • “Especificar tipos de objetos a serem criados usando uma instância protótipo e criar novos objetos pela cópia desse protótipo.”
     • esconde os produtos do cliente, reduz o acoplamento e oferece maior flexibilidade para alterações nas classes produtos.
     • A diferença básica deste padrão é a flexibilidade. Por exemplo: o cliente instancia vários protótipos, quando um deles não é mais necessário, basta removê-lo. Se é preciso adicionar novos protótipos, basta incluir a instanciação no cliente. Essa flexibilidade pode ocorrer inclusive em tempo de execução.
     • Um detalhe que torna o Prototype único em relação aos outros padrões de criação é que ele utiliza objetos para criar os produtos, enquanto os outros utilizam classes.
   • Singleton
     • “Garantir que uma classe tenha somente uma instância e fornece um ponto global de acesso para a mesma.”
     • Outro fator bem positivo do padrão é que, ao mesmo tempo que nós unificamos o acesso aos recursos, nós compartilhamos todos eles! Lembre que não é necessário criar referências, ou seja, qualquer objeto/classe/método em qualquer lugar do seu programa tem acesso aos recursos.
     • Isto também pode ser visto como uma grande desvantagem, pois não é possível inibir o acesso a classe Singleton. Qualquer parte do código por chamar o método getInstance(), pois ele é estático, e ter acesso aos dados da classe.

3. Estrutura

   • Adapter
     • “Converter a interface de uma classe em outra interface, esperada pelo cliente. O Adapter permite que interfaces incompatíveis trabalhem em conjunto – o que, de outra forma, seria impossível.”
     • Cada implementação de adapter possui suas implicações. Um adaptador de classe não vai conseguir trabalhar com as subclasses da classe adaptada, já ao utiliza um adaptador de objeto é possível trabalhar com objetos de subclasses da classe adaptada
     • utilizamos o padrão Adapter para liberar o nosso código cliente de detalhes de implementação de Frameworks/API/Biblioteca específicas.
   • Bridge
     • um Adapter para adaptar as janelas para as diversas plataformas parece ser boa, criaríamos um Adapter para Windows, Linux e Mac e então utilizaríamos de acordo com a necessidade.
     • “Desacoplar uma abstração da sua implementação, de modo que as duas possam variar independentemente.”
     • Como vimos pelo exemplo de codificação o Bridge provê um excelente nível de desacoplação dos componentes. Tanto novas abstrações como novas plataformas podem ser acomodadas pelo sistema sem grandes dificuldades, graças a extensibilidade do padrão.
     • Um ponto que merece um certo cuidado é sobre a instanciação dos objetos, pois vimos que é necessário especificar a abstração e utilizar uma implementação, assim o cliente precisa conhecer bem as classes, e o que elas realizam para saber exatamente o que, quando e como fazer.
   • Decorator
     • “Dinamicamente, agregar responsabilidades adicionais a objetos. Os Decorators fornecem uma alternativa flexível ao uso de subclasses para extensão de funcionalidades.”
     • Como já dito o padrão Decorator adiciona funcionalidades ao objeto em tempo de execução. Note bem que, ao contrário da herança que aplica funcionalidades a todos os objetos dela, o padrão decorator permite aplicar funcionalidades apenas a um objeto específico.
     • Decorator aplica apenas as funcionalidades necessárias ao objeto nós evitamos o problema de classes sobrecarregadas, que possuem funcionalidade que nunca são utilizadas.
   • Facade
   • Proxy
   • Flyweight
   • Composite
     • “Compor objetos em estruturas de árvore para representar hierarquia partes-todo. Composite permite aos clientes tratarem de maneira uniforme objetos individuais e composições de objetos.”
     • A primeira vantagem, e talvez a mais forte, seja o fato de os clientes do código Composite serem bem simplificados, pois podem tratar todos os objetos da mesma maneira.
     • o mal tratamento destas exceções podem gerar problemas de segurança e ai surge uma outra forma de implementar o padrão, restringindo a interface comum dos objetos. Para isto basta remover os métodos de gerenciamento de arquivos (adicionar, remover, etc) da classe base, assim apenas os arquivos pastas teriam estes métodos.
     • Em contrapartida o usuário do código precisa ter certeza se um dado objeto é Pasta para realizar um cast e chamar os métodos da pasta.