Creational - Factory Method
- Define uma interface para criação de um objeto, mas delega às suas subclasses definirem qual classe será instanciada.
- Permite a uma classe deixar para suas subclasses a definição dos tipos específicos com as quais se irá trabalhar.
- Desacopla o cliente dos tipos de produto específicos que ele usa.
- Remove da classe cliente todo o conhecimento sobre as subclasses de produto.
- Permite que o sistema use tipos diferentes de produtos em diferentes momentos.
- Permite que programa seja estendido dinamicamente em tempo de execução.
- Apenas 1 linha de código define o tipo de produtos usados, ao invés de ter o tipo em dezenas de lugares diferentes.
- Negativo - aumenta o número de classes no sistema pois precisa ter a classe abtrata Creator.
Creational - Abstract Factory
- Prover uma interface para criação de famílias de objetos relacionados sem especificar sua classe concreta.
- Um sistema deve ser independente da forma como seus produtos são criados e representados
- Um sistema deve poder lidar com uma família de vários produtos diferentes.
- Você quer prover uma biblioteca de classe de produtos mas não quer revelar as suas implementações, quer revelar apenas as suas interfaces.
- Isola as classes concretas dos clientes
- Facilita a troca de famílias de produto (apenas 1 linha)
- Promove a consistência de produtos (não há o perigo de misturar objetos de famílias diferentes).
- Fábricas geralmente são implementadas como singleton.
- Na fábrica abstrata, cria-se um método fábrica para cada tipo de produto. Cada fábrica concreta implementa o código que cria os objetos de fato.
- Se tivermos muitas famílias de produtos, teríamos excesso de classes “fábricas concretas”
SOLID
-O Single Responsibility Principle (Princípio da responsabilidade única)
-O Open-Closed Principle (Princípio aberto/fechado)
-O Liskov Substitution Principle (Princípio da substituição de Liskov)
-O Interface Segregation Principle (Princípio da segregação da interface)
-O Dependency Inversion Principle (Princípio da inversão da dependência)
- Segurança
As classes e aplicação se tornam mais seguras graças a divisão de responsabilidades. Com o SOLID, não corremos o risco de ter classes “quebradas” por que alguém alterou algum método de outra classe. - Manutenção
Com responsabilidades divididas, fica muito mais fácil dar manutenção na aplicação, principalmente se a pessoa desenvolvedora que for dar manutenção não for a mesmo que desenvolveu a aplicação. Como cada parte do código fonte está exatamente aonde deveria estar, fica mais fácil entender. - Reutilizável
Com POO não é necessária ficar reescrevendo o mesmo código para executar uma determinada tarefa, basta estender de outra classe que já tenha a função que você precisa.
Como vimos, é muito importante entender o SOLID e a programação orientada a objetos, pois, atualmente, a maioria das linguagens utilizam esse paradigma por conta de todos os benefícios que ele traz.
Single Responsibility Principle
- Uma classe deve ter apenas um objetivo, ou seja, ela deve possuir apenas uma função ou funções similares.
- Você já foi a um show? Ou já viu alguma gravação de um show? Então, provavelmente você nunca viu uma única pessoa fazendo tudo. Em um show, as responsabilidades são compartilhadas em prol de um objetivo, que nesse caso é produzir uma música de qualidade. O princípio da responsabilidade única é justamente esse, fazer com que uma única classe execute funções que tem haver com aquela classe.
Open-Closed Principle (Princípio Aberto-Fechado)
- A ideia aqui não é não mexer na classe em hipótese alguma, e sim, caso necessário, adicionar uma nova função àquela classe e não alterar o que já existe nela.
Liskov Substitution Principle (Princípio da substituição de Liskov)
- “As classes derivadas devem ser substituíveis pelas suas classes bases”.
-Suponhamos que você tenha uma classe Pessoa. Essa classe contém atributos como nome, CPF, RG… Mas, e se você criar uma outra classe chamada Aluno, quais os atributos que a classe Aluno pode conter? Se você pensou em nome, CPF, RG, você está certíssimo, porém, não é interessante criar esses mesmos atributos para a classe aluno, o ideal seria que Aluno herdasse de Pessoa.
Esse é o princípio que traz a ideia de herança. Temos uma classe pai, que geralmente possui atributos genéricos e temos uma classe filha, que herda os atributos da classe pai e pode ter outros atributos específicos para si mesma. No nosso exemplo, a classe Aluno poderia herdar todos os atributos da classe Pessoa e ter também ter outros atributos como nota, presença…
Interface Segregation Principle (Princípio da Segregação da Interface)
- “Classes não devem ser forçadas a depender de métodos que não usam.”
- Quando você aplica o princípio de herança, fazendo uma classe herdar da outra, sua classe filha é obrigada a implementar os métodos da classe pai e como você já deve estar imaginando, isso vai contra os princípios do SOLID, pois não é nada interessante que uma classe implementa métodos que não é útil para ela.
Com o princípio de segregação de interface, é possível implementar somente o que importa para as nossas classes. Vamos imaginar que tenhamos uma classe AtendenteFarmacia, mas esse cargo é dividido em dois, temos o atendente de caixa e o balconista e eles executam funções diferentes, logo, teríamos as classes AtendenteCaixa e Balconista.
- Quando você implementasse essa interface na classe AtendenteCaixa, você teria que implementar todos os métodos, inclusive os métodos que o atendente de caixa não executa.
Para evitar isso, basta criar uma interface que atenda separadamente as funções de cada atendente.
Dependency Inversion Principle (Princípio da inversão da dependência)
- “Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração.”
- “Abstrações não devem depender de detalhes. Os detalhes devem depender das abstrações.”
- Em outras palavras, os módulos que são classes de alto nível devem depender de conceitos, também chamadas de abstrações independente de como funcionam, ou seja, a função da inversão de dependência faz com que os softwares se desassociem dos módulos.
