Padrões de projeto

Padrões de projeto

1. O que é

   • São soluções tipicas para problemas comuns em um projeto de software.
   • É um conceito geral onde deve ser seguido e implementar uma solução adequada para o programa

2. Do que consiste

   • Proposito
     • Descreve previmente o problema e solução
   • Motivação
     • Explica a fundo o problema e a solução que o padrão torna possivel
   • Estrutura
     • classes mostram cada parte do padrão e como se relacionam.
   • Exemplo do codigo
     • qual linguagem de programação torna mais facil de entender a ideia por tras do padrão

3. Classificação dos padrões

   • Criacionais
     • Fornece mecanimos de criação de objetos que aumentam a flexibilidade e a reutilização de código.
   • Estruturais
     • explicam como montar objetos e classes em estruturas maiores, enquanto ainda mantém as estruturas flexíveis e eficientes.
   • Comportamentais
     • cuidam da comunicação eficiente e da assinalação de responsabilidades entre objetos.

4. Porque Aprender

   • saber sobre os padrões se torna muito util porque ensinam a como resolver varios problemas usando principios de orientação a objetos

5. Caracteristicas de um bom projeto

   • Reutilização de codigo
     • como o proprio nome ja diz, reutilizar um codigo que ja existe poupa tempo e linhas de codigos
   • Extensibilidade
     • Esteja adapto a mudanças

6. Encapsule oq varia

   • isole as partes de um programa que variam em módulos independentes, protegendo o resto do código de efeitos adversos.

7. Programe para uma interface, não uma implementação.

   • pode perceber se o projeto é flexível o bastante se você pode estendê-lo facilmente sem quebrar o código existente.

8. Prefira composição sobre herança

   • A herança é provavelmente a maneira mais óbvia de reutilizar código entre classes. Você tem duas classes com o mesmo có- digo. Crie uma classe base comum para ambas essas duas clas- ses e mova o código similar para dentro dela.
     • lado ruim
       • Uma subclasse não pode reduzir a interface da superclasse.
       • Quando sobrescrevendo métodos você precisa se certificar que o novo comportamento é compatível com o comportamento base.
       • A herança quebra o encapsulamento da superclasse
       • As subclasses estão firmemente acopladas as superclasses.
       • Tentar reutilizar código através da herança pode levar a cri- ação de hierarquias de heranças paralelas.

9. SOLID

   • S: Uma classe deve ter apenas uma razão para mudar.
     • O objetivo principal deste princípio é reduzir a complexidade. Você não precisa inventar um projeto sofisticado para um programa que tem apenas 200 linhas de código. Faça uma dúzia de métodos bonitos, e você ficará bem.
     • se uma classe faz muitas coisas, você terá que mudá-la cada vez que uma dessas coisas muda. Enquanto faz isso, você está arriscando quebrar outras partes da classe que você nem pretendia mexer. Se em determinado momento você sente que está se tornando difícil focar em aspectos específicos de um programa, lem- bre-se do princípio da responsabilidade única e verifique se já não é hora de dividir algumas classes em partes.
   • O: As classes devem ser abertas para extensão mas fecha- das para modificação.
     • A ideia principal deste princípio é prevenir que o código existente quebre quando você implementa novas funcionalidades.
   • L: Quando estendendo uma classe, lembre-se que você deve ser capaz de passar objetos da subclasse em lugar de objetos da classe mãe sem quebrar o código cliente.
     • Isso significa que a subclasse deve permanecer compatível com o comportamento da superclasse. Quando sobrescre- vendo um método, estenda o comportamento base ao invés de substituí-lo com algo completamente diferente.
   • I: Clientes não devem ser forçados a depender de métodos que não usam.
     • Fazer com que suas interfaces sejam reduzidas o sufici- ente para que as classes cliente não tenham que implementar comportamentos que não precisam.
   • D : Classes de alto nível não deveriam depender de classes de baixo nível. Ambas devem depender de abstrações. As abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.
     • Geralmente quando fazendo projeto the software, você pode fazer uma distinção entre dois níveis de classes.
       • Classes de baixo nível
         • implementam operações básicas tais como trabalhar com um disco, transferindo dados pela rede, conectar-se a uma base de dados, etc.
       • Classes de alto nível
         • contém lógica de negócio complexa que direcionam classes de baixo nível para fazerem algo.

10. Padrões de projeto criacionais

    • Factory Method
      • Fornece uma interface para criar objetos em uma superclasse, mas permite que as subclasses alterem o tipo de objetos que serão criados.
    • Abstract Factory
      • Permite que você produza famílias de objetos relacionados sem ter que especificar suas classes concretas.
    • Builder
      • Permite construir objetos complexos passo a passo. O padrão permite produzir diferentes tipos e representações de um objeto usando o mesmo código de construção.
    • Prototype
      • Permite que você copie objetos existentes sem fazer seu código ficar dependente de suas classes.
    • Singleton
      • Permite a você garantir que uma classe tem apenas uma instân- cia, enquanto provê um ponto de acesso global para esta instân- cia.