brunoobj

Herança vs composição

Herança e composição são conceitos para melhorar a organização e reutilização de códigos.

A herança é usada quando queremos ter um comportamento, "é um". Isso no diz que uma subclasse herda atributos e métodos de uma superclasse. Com a herança conseguimos reaproveitar comportamentos porém nos traz uma maior rigidez.

A composição por sua vez é usada quando queremos "ter um" comportamento. A classe utiliza de seus atributos ter um comportamento. Com a composição cada classe tem responsabilidade única e facilita na utilização de patterns como Strategy e Decorator.

brunoobj

The new version of PHP is available for devs. Most of the improvement has implement and what is better could be amazing. I will describe
a funcionallity that we can use: The Property Hooks.

Overbody needed to implement a class with some attributes and write getters and setters methods, one-by-one. Now, in the version 8.4
the things was simplified as the demonstration bellow: 

class BookViewModel {
    public function __construct(
        private array $authors,
    ) {}

brunoobj

Single Responsibility Principle 
S = Cada classe deve ter apenas uma responsabilidade

Open Closed Principle
- Objetos ou entidades devem estar abertos para extensão, mas fechados para modificação
O = Código existente não deve ser modificado para adicionar novas funcionalidades, mas sim extendido
Usar herança para criar novos comportamentos ao invés de modificar a função base

Liskov Substitution Principle
- Uma classe derivada deve ser substituível por sua classe base

brunoobj

O padrão de projeto Observer nos dá orientação de como podemos trabalhar com notificações. Vamos pensar na classe Publishier, ela é responsável por receber todas as alterações dos estados e notificar a classe Cliente. Para saber qual é a classe Cliente, esta precisa estar inscrita em uma interface Subscriber. O Publishier consegue direcionar notificações por Subscriber, por exemplo: um Subcriber para notificar a alteração do preço de um produto, outro para notificar que um produto chegou na loja, e assim por diente. Com isso, os clientes pertencem a um Subscriber recebe notificações do que lhe interessa.  

brunoobj

Esse padrão de projeto é útli quando temos uma classe serviço que possui uma tarefa custosa e necessitamos de mais performance. A ideia da classe se constitui em criar uma outra classe Proxy que se utiliza da mesma interface da classe de serviço. Quando o código cliente necessita instanciar a classe de serviço, utiliza-se no lugar a classe Proxy. Nessa classe Proxy pode ter implementações que ajude a performance como cache e etc. 

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

brunoobj

Thought: é o passado e particípio do verbo to think
- I thought about the future

Though: Signigica mas, embora ou entretanto
- I will travel to the Bahamas, though I would like to go to Dubai

Tough: Significa determinado, resistente, duro ou forte
- He was the winner because of his tough training

Through: Significa através

brunoobj

Esse padrão de projeto é muito útil quando um código cliente necessita de funcionalidades que um serviço dispoem porém eles possuem interface incompatível. Nesses casos, podemos utilizar o padrão de projeto Adapter. Basicamente teremos esse nova classe Adapter que implementa a interface necessária para o cliente. Dentro do Adapter, temos a propriedade do serviço. Com isso a cada método necessário na interface fazemos a "tradução" para o serviço, delegando a maior parte da responsabilidade para a classe serviço ficando o Adaptador responsável somente para a conversão do que veio do cliente para o que vai para o serviço. 

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

brunoobj

Qual é a diferença entre This, that, these e those. Essas palavras em inglês traduzidas ao pé da letra são:
This: Este
These: Estes
That: Aquele
Those: Aqueles

A variança entre eles se dá pela distância do substantivo (ou pronome pessoal) de referência e se é plural ou não. 
Alguns exemplos entre eles: 
- I'm really busy THIS morning.
- Can you eat THESE fishes?

brunoobj

Podemos utilizar o padrão Strategy quando temos uma classe inflada com varios comportamentos. Com a Strategy podemos separar cada comportamento para outras classes interligando-as por uma interface. A classe chamada de Contexto pode receber a interface  e executar o código sempre precisar saber qual foi o comportamento executado. Fica por conta do código cliente definir quem vai ser o comportamento esperado e passar a estratégia desejada.

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

brunoobj

Pensando no contexto de CRUD, o método POST deve ser utilizado para criação de registros, retornando o código http 201. O método PUT, deve servir para atualização total de um registro, caso ele exista, e a criação caso não exista, retornando o código 200 (update) ou 201 (created) respectivamente. Já o método PATCH serve para atualizar parcialmente um registro, retornando código 200 em caso de sucesso, ou 204 (No content) em caso de não encontrar o registro. 

Link: https://dev.to/mehmehmehlol/put-vs-patch-put-vs-post-56i9