Princípios de arquitetura
- usado para criar aplicações limpas e de fácil manutenção
Separação de interesses
- separa as partes de acordo com o que cada um executa(especialização)
Design de arquitetura
- sempre siga a arquitetura escolhida a risca
Encapsulamento
- elementos privados
- parte encapsulada recebe interfaces para se comunicar com o resto
- não é necessário saber como as partes agem por dentro
Inversão de dependência
- um módulo que depende de outro, não pode ter detalhes de implementação desse outro, esse deve ser mais genérico
- módulos se comunicam através de uma interface padrão, assim as classes vão ficar dependentes das interfaces, mas não dos detalhes da outra classe
sem inversão de\ndependência" loading="lazy" src="/posts/ciencias-da-computacao-dia-220-e608i9iiigi6/image_361.png">
com inversão de\nindependência" loading="lazy" src="/posts/ciencias-da-computacao-dia-220-e608i9iiigi6/image_362.png">
Dependências explicitas
- se um objeto precisa de algo de outro, o método construtor precisa explicitamente requisitar eles
Responsabilidade única
- os objetos precisam ter uma única responsabilidade
- precisam também ter apenas uma razão para existir ou deixar de existir
- devem fazer essa única coisa muito bem
DRY(don’t repeat yourself)
- não se replica conhecimento num mesmo contexto
- para contextos diferentes isso não é necessariamente obrigatório refatorar e extrair para uma coisa só, já q partes diferentes significam coisas diferentes
- partes do mesmo contexto deve ser refatoradas para deixar o conhecimento especializado em um local só
Ignorância de persistência
- persistência aqui significa o meio que você salva coisas, com o BD
- o sistema deve ser agnóstico ao sistema de persistência
- usar coisas como ORM ou outras abstrações
Contexto limitado
- dividir o sistema em módulos de mesmo contexto (RH, Contabilidade, Log, etc)
- são usadas interfaces quando há necessidade de comunição entre eles