Princípio da Responsabilidade Única:
Um objeto deve conter apenas uma única responsabilidade, e essa responsabilidade é completamente encapsulada em uma classe.
Princípio de Responsabilidade Única (SRP): Todo objeto deve ter uma única responsabilidade, e essa responsabilidade deve ser totalmente encapsulada pela classe.No que diz
respeito a uma classe,
nunca deve haver mais de um motivo para uma classe mudar.
O princípio da responsabilidade única analisa quanto mais responsabilidades uma classe (de módulos a métodos) assume ,
menor a probabilidade de ser reutilizada Encapsule diferentes razões para mudanças em diferentes classes O princípio da responsabilidade única é a diretriz para alcançar alta coesão e baixo acoplamento
Princípio de abertura e fechamento:
As entidades de software devem estar abertas para extensão e fechadas para modificação.
Princípio Aberto-Fechado (OCP): entidades de software devem ser abertas para extensão, mas fechadas para modificação.
Análise do princípio de abertura e
fechamento O princípio de abertura e fechamento foi proposto por Bertrand Meyer em 1988.
Na definição do princípio de abertura e fechamento, uma entidade de software pode ser um módulo de software, uma estrutura parcial composta de múltiplas classes, ou uma classe independente. O princípio de abertura e fechamento
refere-se ao software Entidades devem tentar expandir sem modificar o código original.
Abstração é a chave para o princípio de abertura e fechamento.
Camada de abstração relativamente estável +
camada de concreto flexível. Princípio de encapsulamento de Variação (EVP): encontre os fatores variáveis do sistema e encapsule-os
Princípio da substituição de Liskov:
Todos os lugares que se referem à classe base devem ser capazes de usar objetos de suas subclasses de forma transparente.
Princípio de Substituição de Liskov (LSP): Funções que usam ponteiros ou referências a classes base devem ser capazes de usar objetos de classes derivadas sem saber.
Análise do Princípio de Substituição de Liskov Se
um objeto de classe base for substituído por seu objeto de subclasse no software, o programa não produzirá erros e exceções e vice-versa. Se uma entidade de software usa um objeto de subclasse, ela pode não ser capaz de usar o objeto de classe base
Tente usar o tipo de classe base para definir o objeto no programa e, em seguida, determine seu tipo de subclasse em tempo de execução
Princípio de inversão de dependência:
Módulos de alto nível não devem depender de módulos de baixo nível, todos devem depender de abstrações. Abstrações não devem depender de detalhes, detalhes devem depender de abstrações.
Princípio de Inversão de Dependência (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 detalhes, detalhes devem depender de abstrações. Programar contra interfaces, não contra implementações Programar para uma interface
,
não uma implementação.
Análise do princípio de inversão de dependência
Ao passar parâmetros no código do programa ou em relacionamentos de associação, tente se referir a classes de camadas abstratas de alto nível, ou seja, use interfaces e classes abstratas para declarar tipos de variáveis, tipos de parâmetros, tipos de retorno de método e tipos de dados. Conversão, etc.
Tente usar a camada abstrata para programação no programa e escreva a classe específica no arquivo de configuração.
Para a programação da camada abstrata, injete o objeto da classe específica em outros objetos através da Injeção de Dependência (Dependency Injection, DI )
Construir o
ajuste de injeção Injection (Setter Injection)
Interface Injection
Princípio de isolamento de interface:
Um cliente não deve depender de interfaces de que não precisa.
Princípio de segregação de interface (ISP): os clientes não devem ser forçados a depender de interfaces que não usam.
Análise do princípio de segregação de interface
Quando uma interface é muito grande, ela precisa ser dividida em interfaces menores.
Os clientes que usam essa interface precisam apenas conhecer os métodos relacionados a ela
. Faça o que não deve fazer e faça o que deve fazer.
Definição de "Interface" (1): uma coleção de todas as características de método fornecidas por um tipo. Uma interface representa um papel, e cada papel tem sua própria interface específica "Princípio de Segregação de Papéis"
Definição de "Interface" (2): interface específica de linguagem estritamente definida. A interface fornece apenas o comportamento de que o cliente precisa, e o comportamento de que o cliente não precisa fica oculto. O cliente deve receber uma única interface tão pequena quanto possível, em vez de fornecer uma grande interface total. Cada interface contém apenas uma cliente. método necessário, "serviço personalizado"
Princípios de multiplexação sintética:
Priorize o uso de composição de objetos em vez de herança para atingir o propósito de reutilização.
Princípio de Reutilização Composta (CRP): Favorecer a composição de objetos sobre a herança como um mecanismo de reutilização.
Análise do princípio de reutilização sintética O
princípio de reutilização sintética é usar alguns objetos existentes em um novo objeto por meio de relacionamento de associação (incluindo relacionamento de combinação e relacionamento de agregação), tornando-o parte do novo objeto. O novo objeto chama o objeto existente por meio de delegação. O
método para atingir o objetivo da função de reutilização
Ao reutilizar, tente usar o relacionamento de combinação/agregação (relação de associação) e use menos herança.Reutilização de herança
: simples de implementar e fácil de expandir. Destrua o encapsulamento do sistema; a implementação herdada da classe base é estática, impossível de ser alterada em tempo de execução e não há flexibilidade suficiente; ela só pode ser usada em um ambiente limitado. (reutilização de "caixa branca")
reutilização composicional/agregada: acoplamento relativamente baixo, operações em objetos membros são invocadas seletivamente; pode ser feito dinamicamente em tempo de execução, novos objetos podem referenciar dinamicamente outros objetos do mesmo tipo como objeto de objetos membros. multiplexação (caixa preta)
Lei de Dimit:
Cada unidade de software tem apenas um conhecimento mínimo de outras unidades e é limitada às unidades de software intimamente relacionadas à unidade.
Lei de Demeter (LoD): Cada unidade deve ter apenas conhecimento limitado sobre outras unidades: apenas unidades "estreitamente" relacionadas à unidade atual.
Análise da Lei de Dimiter A Lei de Dimiter
exige que uma entidade de software interaja o mínimo possível com outras entidades . estranhos.) Comunique-se apenas com seus amigos diretos (Fale apenas com seus amigos imediatos.) (1) O próprio objeto atual (este) (2) É passado como um parâmetro para o método do objeto atual Objetos em (3) Objetos membros do objeto atual (4) Se os objetos membros do objeto atual são uma coleção, então os elementos da coleção também são amigos (5) Qualquer objeto criado pelo objeto atual . O grau de acoplamento do sistema, a mudança de um objeto não afetará muitos outros objetos A lei de Dimiter exige que, ao projetar o sistema, a interação entre os objetos deve ser minimizado. Se dois objetos não precisam se comunicar diretamente entre si, então isso não deve haver nenhuma interação direta entre dois objetos. Se um dos objetos precisar chamar o método de outro objeto, a chamada pode ser encaminhada por meio de um "terceiro" para reduzir a distância entre os objetos existentes introduzindo um "terceiro" razoável. Acoplamento entre
Pontos a serem observados ao aplicar a lei de Dimit:
Em termos de divisão de classes, classes fracamente acopladas devem ser criadas o máximo possível. Quanto menor o grau de acoplamento entre as classes, mais propício ao reuso. Uma vez que uma classe em acoplamento fraco é modificada, ela não terá muito impacto na classe associada
No projeto estrutural da classe, cada classe deve minimizar os direitos de acesso de suas variáveis e funções-membro
No projeto da classe, sempre que possível, um tipo deve ser projetado como uma classe invariável
Um objeto deve minimizar suas referências a outros objetos em termos de referências a outras classes