O documento discute princípios de programação orientada a objetos como SRP, OCP, LSP, ISP e DIP. Também aborda padrões como Singleton, Builder e melhores práticas para desenvolvimento de APIs como uso de URIs significativas e documentação clara.

1. - Solid
São cinco princípios da programação orientada a objetos que facilitam no desenvolvimento de
softwares, tornando-os fáceis de manter e estender. Esses princípios podem ser aplicados a
qualquer linguagem de POO.

2. SRP Single Responsiblity
1- Uma classe deve ter uma, e somente uma responsabilidade.
2- Uma classe nunca deve ter a responsabilidade de outra classe.
3- Toda classe deve ter um inicio e fim conhecido.
4- A responsabilidade deve estar totalmente encapsulada na respectiva classe.
* Tudo que não for de uso publico deve ser obrigatoriamente mantido em segredo dentro da classe.
* Uso de GET e SET para retorno e atribuição de valores.
5- Onde se tem muita generalização não é possível ter especialização.

3. Codigo SRP
Codigo violando o principio Codigo respeitando o principio

4. OCP Open/ Closed
O codigo deve ser aberto para extensão, mas fechado para alteração.
* Atualizar ou adcionar algo a um codigo existente é uma alteração e fazer isto sem modificar um
codigo existente é extender.
* Respeitamos estes principios utilizando interfaces e classes abstratas, assim elas não são
alteradas apenas extendidas.

5. Codigo OCP

6. LSP Liskov Substitution
Este principio diz que a subclasse não pode quebrar o comportamento da classe mãe e a
classe filho deve poder ser substituida pela classe mãe sem alterar a mãe seja ela uma
interface, classe ou classe abstrata.
●Ex:
● Note que as subclasses são do tipo Cliente herdaram e sobrescreveram seu metodo
mantendo o comportamento sem necessidade de alterar a classe mãe.

7. ISP Interface Segregation
Varias interfaces especificas são melhor do que uma interface generica.
Se refere a não criar uma interface com muitas funcionalidades e sim varias com funções bem
definidas em cada uma facilitando a implementação de seus metodos em novoa clienres.

8. DIP Dependency Inversion
●Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem
depender de abstrações.
●Inverter a dependencia faz com que ao invés da classe A se referir diretamente a classe
B ambas se refiram a abstrações isto diminui a dependencia entre elas e possibilita a
reutilização dos componentes.

9. - Codigo DIP

10. - Dry
●Oque é: Um principio que faz referencia ao polimorfismo para
evitar duplicações de codigo.
●Para que serve: Reduzir duplicações, facilitar a manutenção,
trazes um codigo mais legivel.

11. - Codigo Dry

12. - Kiss
●Oque é: Um principio que busca a maior simplicidade possível para um codigo.
●Para que serve: O objetivo é tornar o codigo o mais simples possível, trazendo um
codigo limpo, facil de manter e entender .
●Dicas: Primeiro resolva o problema, então depois codifique, cada método não deve ter
mais que 30-40 linhas de código, cada método deve resolver apenas um pequeno
problema.

13. - Codigo Kiss
●Complexidade
●Implementando o principio Chamada do metodo

14. - Builder
●Oque é: É um padrão onde em vez de passar os argumentos
diretamente a Classe x nós chamamos e passamos os
argumentos para métodos do Builder e eles retornam estes
dados para a classe x.
●Praque serve: Torna o codigo legivel apesar de ficar um
pouco mais complexo.

15. - Builder Codigo

16. - Singleton
●Oque é: Um padrão para instanciar uma classe apenas uma vez
●Para que serve: Serve para garantir que apenas uma instanciação da
classe vai ser feita em toda aplicação, seria muito util na conecxão
com o banco de dados.

17. - Codigo Singleton

18. Best Practices
●Identificação dos Recursos: cada recurso deve possuir uma identificação única, que
deve ser informada nas requisições.
●Ex:
●http://minhaapi.com.br/produtos
●http://minhaapi.com.br/clientes
●http://minhaapi.com.br/vendas

19. ●Utilizar URIs ligíveis: devemos usar nomes legiveis que sejam faceis para deduzir e
que sejam relacionados com a aplicação.
●Utilizar um Padrão de URI na identificação dos recursos: Estabelecer um padrão
para nomear as URIS dos recursos e mantelo, para evitar falta de consistencia como esta:
● http://minhaapi.com.br/produto (Singular)
● http://minhaapi.com.br/clientes (Plural)

20. ● Não colocar na URI a operação que vai fazer no recurso: A manipulação dos
recursos deve ser feita utilizando os metodos http.
●http://minhaapi.com.br/produtos/cadastrar
●http://minhaapi.com.br/clientes/excluir
●http://minhaapi.com.br/vendas/atualizar

21. ●Não colocar na URI o formato desejado na apresentação do recurso
●http://minhaapi.com.br/produtos/xml;
●http://minhaapi.com.br/clientes/112?formato=json
●Evite alterações nas URI’s: Após definir uma URI e disponibilizar a manipulação de
um recurso por ela, evite ao máximo sua alteração.
●Utilização correta dos códigos HTTP
●Documentação bem definida e simples: Deve conter parametros de entrada e saida
especificados se são obrigatorios ou opcionais, descrição de funcionalidade dos metodos,
formatos de resposta, requerimento de autenticação ou não, especificações de metodos
aceitos pelo endopoint e especificar os codigos de retorno tanto de sucesso quanto de

22. API Style guide
●Consiste em duas partes a definição de funções e a definição de regras
●Difinição de funções: A função deve retornar true se a validação for aprovada ou uma
sequência que descreva o motivo da falha, se a validação falhar.
●Difinição de Regras: Precisamos garantir que toda a API use a combinação definida de
método de solicitação e código de status de resposta.