arquitetura.md

@@ -13,6 +13,79 @@ Esta é a página em que irão constar todas as informações da Arquitetura do
 
 
 
+# Análise dos principios SOLID
+
+S — Single Responsiblity Principle (Princípio da responsabilidade única)
+
+O — Open-Closed Principle (Princípio Aberto-Fechado)
+
+L — Liskov Substitution Principle (Princípio da substituição de Liskov)
+
+I — Interface Segregation Principle (Princípio da Segregação da Interface)
+
+D — Dependency Inversion Principle (Princípio da inversão da dependência)
+
+### SRP — Single Responsibility Principle:
+
+Princípio da Responsabilidade Única — Uma classe deve ter um, e somente um, motivo para mudar.
+Esse princípio declara que uma classe deve ser especializada em um único assunto e possuir apenas uma responsabilidade dentro do software, ou seja, a classe deve ter uma única tarefa ou ação para executar.
+
+**A violação do Single Responsibility Principle pode gerar alguns problemas, sendo eles:**
+
+* Falta de coesão — uma classe não deve assumir responsabilidades que não são suas;
+
+* Alto acoplamento — Mais responsabilidades geram um maior nível de dependências, deixando o sistema engessado e frágil para alterações;
+
+* Dificuldades na implementação de testes automatizados — É difícil de “mockar” esse tipo de classe;
+
+* Dificuldades para reaproveitar o código;
+
+### OCP — Open-Closed Principle:
+
+Princípio Aberto-Fechado — Objetos ou entidades devem estar abertos para extensão, mas fechados para modificação, ou seja, quando novos comportamentos e recursos precisam ser adicionados no software, devemos estender e não alterar o código fonte original.
+
+### LSP— Liskov Substitution Principle:
+
+Princípio da substituição de Liskov — Uma classe derivada deve ser substituível por sua classe base.
+
+O princípio da substituição de Liskov foi introduzido por Barbara Liskov em sua conferência “Data abstraction” em 1987. A definição formal de Liskov diz que:
+
+>>>
+Se para cada objeto o1 do tipo S há um objeto o2 do tipo T de forma que, para todos os programas P definidos em termos de T, o comportamento de P é inalterado quando o1 é substituído por o2 então S é um subtipo de T
+>>>
+
+**Exemplos de violação do LSP:**
+
+* Sobrescrever/implementar um método que não faz nada;
+
+* Lançar uma exceção inesperada;
+
+* Retornar valores de tipos diferentes da classe base;
+
+### ISP — Interface Segregation Principle:
+
+Princípio da Segregação da Interface — Uma classe não deve ser forçada a implementar interfaces e métodos que não irão utilizar.
+
+Esse princípio basicamente diz que é melhor criar interfaces mais específicas ao invés de termos uma única interface genérica.
+
+### DIP — Dependency Inversion Principle:
+
+Princípio da Inversão de Dependência — Dependa de abstrações e não de implementações.
+
+De acordo com Uncle Bob, esse princípio pode ser definido da seguinte forma:
+
+>>>
+1. Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração.
+>>>
+
+>>>
+2. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.
+>>>
+
+---
+
+
+
 
 * Segurança 
 * Rotas de Backend (Arquitetura
@@ -25,7 +98,6 @@ funcional)
 * Diagrama de Deploy
 * Documentação sobre aplicação de
 Design do Projeto
-* Análise dos principios SOLID
 * Code Review
 * 
 Devem ser apresentados das seguintes formas: