Apres s4
- 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.
- 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.