brunoobj

O padrão de projeto Cadeia de responsabilidade nos ajuda quando pode existir diversos comportamentos dentro de uma classe. Invés de utilizarmos varias condicionais (IFs e elses) podemos criar handlers que trabalha com um e somente um comportamento e nele tem um apontamento para um outro handler caso o atual não se aplique. Com isso temos uma corrente (ou cadeia) de comportamentos.

Com esse padrão, podemos usar duas abordagens. Uma seria ter os handler que verifica se pode realizar o trabalho e caso negativo passa para o próximo handler e a outra abordagem seria passar por todos os handler, e fazer as devidas validações e em caso de sucesso avançar para o próximo handler. 

Cada um dessas abordagens vão variar conforme a necessidade da implementação. 

Link: https://refactoring.guru/pt-br/design-patterns/chain-of-responsibility

brunoobj

Imagine que em algum momento no código cliente se faça necessário clonar um objeto, a primeiro momento parece ser a melhor solução acessar parametro por parametro da classe de desejo e passar para a nova instancia do clone, porém essa abordagem acaba gerando alguns problemas, por exemplo, se a classe que se deseja clonar tem métodos privados. Nessa situação já não é possível ter um clone fiel. 

O padrão de projeto Prototype resolve essa situação. A ideia do Prototype é gerar uma interface que tenho somente um método chamado clonar. As classes que irão sofrer um clone implementa essa interface e cada uma gera o seu próprio clone. Como a classe tem acesso a todos os seus métodos e atributos, é possível criar um clone exato. 

No código cliente, bastaria chamar o método clonar para ter acesso a uma réplica exata da classe de desejo, ficando sobre a responsabilidade dessa clase a clonagem. 

Link: https://refactoring.guru/pt-br/design-patterns/prototype

brunoobj

O padrão de Projeto Singleton é muito bem aceito quando necessitamos acessar os recursos de um objeto em qualquer lugar do código, sem precisar usar variáveis globais. A sua estratégia é definir uma classe com um construtor privado e um método estático para lidar com a instaciação. Basicamente esse método estático fica responsável por instanciar o objeto ou então, caso já tenha sido uma vez instanciado, retornar a referencia já criada. 

Utilizando da estratégia de singleton, conseguimos utilizar o mesmo objeto em todo o projeto, sem o risco de sobrescrita como pode acontecer com variáveis globais. 

brunoobj

O padrão de projeto Builder resolve o problema de instanciação de objetos muito complexos e dependente de muitos parâmetros opcionais. Pensando no objeto Casa, este pode ter piscina, jardim, garagem entre outros atributos opcionais. Passar todos eles no construtor da casa acaba gerando smells. Para resolver isso utilizamos o builder, que basicamente vai montando o objeto conforme a necessidade. O builder tem uma caracteristica que enquanto não finaliza a construção, não é possível acessa-lo, nos trazendo a garantia que o objeto a construir estará com todas as dependencias que desejamos. 

brunoobj

O padrão Ponte é o que conhecemos por abstração. A melhor forma de implicar é em cima de exemplos: Imagine que você tem uma classe carro, e essa classe pode ser Carro Elétrico e Carro a combustão. A forma de de ligar o motor nas duas classes são diferentes. A tendência é termos que implementar duas classes onde escreveríamos o método ligar de formas diferentes. 

O padrão Ponto no diz que nesse caso teríamos uma classe chamada Carro e uma interface chamada Motor que define o método ligar, A classe Carro teria um atributo chamada motor que seria do tipo Motor. Teríamos mais duas classes, MotorEletrico e MotorCombustao, que implementariam a interface Motor e cada um faria da forma que fosse necessária o método ligar.

Ao definir um carro, instanciaríamos a classe Carro e passaríamos o tipo de motor (elétrico ou a combustão). Como estamos definindo em Carro a interface Motor, para esta fica transparente se é Elétrico ou a Combustão. A interface fica como uma ponte entre as duas classes, Carro e CarroElétrico (ou

brunoobj

Imagine que existem varias classes que são dependentes para realizar uma ação, porém para cada classe é utilizado poucos métodos de tudo o que ela oferece. Para não expor todas essas classes com todos esses métodos para um código cliente (tenha como código cliente, o código que vai chamar a funcionalidade executada pelas classes complexas) passamos a Fachada que tem um método que realiza a ação desejada. 

A Fachada é responsável por reunir as classes complexas, podendo instanciar ou receber por parametros, ficando responsável por lidar com cada método das classes complexas e chegar no resultado desejado. 

Utilizando o padrão de projeto Fachada (Facade) fica transparente para o código cliente a implementação do método, ficando fácil a alteração de uma classe complexa por outra.

Link: https://refactoring.guru/pt-br/design-patterns/facade

brunoobj

Antes de explicar o conceito, é bom sabermos qual é a diferença entre compilador e interpretador na linguagem de programação. 

Tanto o compilador quanto o interpretador serve para transforma o nosso código (linguagem humana) para algo que o
computador consiga entender (linguagem de máquina). Porém o "como" isso é realizado difere nas duas maneiras. 

O compilador obtem o nosso código e transforma diretamente para a linguagem de máquina (executável). Para executar o código é só abrir o executável no computador.

Já o interpretador, ele lê o nosso código, linha a linha, em tempo de execução e vai transformando em linguagem de máquina, após a linguagem de máquina pronta, está é executada. 

Existe vantagens e desvantagens nas duas abordagens. A vantagem de linguagem compiladas é a velocidade de execução, porém existe a desvantagem de ter que gerar uma nova versão compilada caso o nosso código exija alteração.

brunoobj

https://refactoring.guru/pt-br
https://medium.com/
https://stitcher.io/
https://dev.to/