Quantos princípios os padrões de projeto realmente têm?
Categories:
Os princípios de design de software originalmente resumidos eram apenas 5, ou seja, SOLID:
Princípio da Responsabilidade Única (Single Responsibility Principle, SRP): Uma classe deve ter apenas um motivo para mudar, ou seja, uma classe deve ter apenas uma responsabilidade.Princípio Aberto/Fechado (Open/Closed Principle, OCP): Entidades de software (classes, módulos, funções, etc.) devem estar abertas para extensão, mas fechadas para modificação. Ou seja, as mudanças devem ser implementadas através de extensão, não através da modificação do código existente.Princípio da Substituição de Liskov (Liskov Substitution Principle, LSP): Tipos derivados devem ser capazes de substituir seus tipos base. Ou seja, uma classe derivada deve ser capaz de substituir sua classe base sem afetar a correção do programa.Princípio da Segregação de Interface (Interface Segregation Principle, ISP): Não se deve forçar um cliente a depender de interfaces que não utiliza. Interfaces grandes devem ser divididas em interfaces menores e mais específicas, para que os clientes conheçam apenas os métodos que precisam usar.Princípio da Inversão de Dependência (Dependency Inversion Principle, DIP): Módulos de alto nível não devem depender de módulos de baixo nível, ambos devem depender de abstrações. Abstrações não devem depender de implementações concretas, e implementações concretas devem depender de abstrações.
Posteriormente, foram adicionados dois princípios, que são mais específicos e orientados à prática. Observando as explicações dos princípios, podemos ver que SOLID descreve “como deve ser feito”, enquanto os princípios adicionados descrevem “como é preferível fazer”.
Princípio da Reutilização por Composição/Aggregação (Composition/Aggregation Reuse Principle, CARP): Deve-se preferir a composição (agregação) de objetos ao invés da herança para alcançar reutilização de código.Lei de Demeter (Law of Demeter, LoD): Um objeto deve saber o mínimo possível sobre outros objetos, ou seja, um objeto deve saber o mínimo possível sobre a estrutura interna e detalhes de implementação de outros objetos.
Além dos princípios de design mencionados acima, existem outros princípios de design que, embora não sejam tão conhecidos, também têm um papel importante na orientação do design e arquitetura de software. Esses princípios adicionados posteriormente são um pouco desnecessários, pelo menos eu acho que eles não são contraintuitivos e não requerem reflexão profunda.
Princípio do Mínimo Conhecimento (Principle of Least Knowledge, PoLK): Também conhecido como extensão da Lei de Demeter, afirma que um objeto deve saber o mínimo possível sobre informações de outros objetos. A origem desse princípio pode ser rastreada até 1987, quando Patricia Lago e Koos Visser propuseram a “Lei da Mínima Comunicação”.Princípio da Dependência Estável (Stable Dependencies Principle, SDP): Esse princípio afirma que o design de software deve garantir que componentes estáveis não dependam de componentes instáveis, ou seja, componentes com maior estabilidade devem depender menos de componentes com menor estabilidade. Esse princípio deriva de pesquisas profundas sobre as relações entre componentes em sistemas de software.Princípio da Abstração Estável (Stable Abstraction Principle, SAP): Em consonância com o Princípio da Dependência Estável, esse princípio orienta a correspondência entre abstração e estabilidade, ou seja, componentes estáveis devem ser abstratos, enquanto componentes instáveis devem ser concretos. Esse princípio ajuda a garantir a estabilidade e flexibilidade do sistema de software.