Sete princípios de design da arquitetura de software

Notas do estudo "Princípios Básicos da Primavera"

dicas: princípios fundamentais do padrão de design da mola

1. Sete princípios de design de arquitetura de software

1. Princípio Fechado Aberto OCP

• Conteúdo: aberto à expansão , fechado à modificação
• Por exemplo: o diagrama de classes é mostrado abaixo, crie uma interface ICourse do curso, cursos diferentes criam classes diferentes do JavaCourse para implementar a interface, se houver uma redução de preço do curso, não modifique o método getPrice na classe original, mas estenda novamente a nova classe JavaDiscountCouse herde essa classe e reescreva Método de preço getPrice. Esse método viola o Princípio de Substituição de Liskov, portanto, a melhor maneira é reescrever um método getDiscountPrice.
  

2. Princípio da inversão de dependência (DIP)

• Conteúdo:
  • O programa depende da interface abstrata , não da implementação concreta . Simplificando, requer programação abstrata , não programação , o que reduz o acoplamento entre o cliente e o módulo de implementação. (Métodos públicos e abstrações que não dependem de implementações específicas são classes estáticas e métodos públicos e abstrações que dependem de implementações específicas são classes de interface)
  • Injeção de dependência com Spring é um significado
• Exemplo: O diagrama de classes é mostrado abaixo: Crie uma interface ICourse do curso. Diferentes cursos implementam a interface ICourse. A classe Tom pode chamar classes de implementação de curso diferentes através da injeção de dependência (os três métodos de injeção de dependência: passagem de parâmetro, construtor e método de configuração)
  

3. O princípio da responsabilidade única (SRP)

• Conteúdo: não há mais de uma causa de mudança de classe. Ou seja, se uma classe é responsável por diferentes responsabilidades, as diferentes responsabilidades são divididas em diferentes classes.
• Nota: Durante o uso do princípio único, não é fácil de implementar e não pode garantir que todas as classes ou métodos sejam uma única função, mas devemos fazer o possível para garantir que possa reduzir o custo de operações e manutenção posteriores. Ao mesmo tempo, no modelo DAO, por que existem quatro métodos diferentes para uma classe (adição, exclusão e modificação), porque as operações básicas do DAO são essas quatro, portanto, não há necessidade de dividir os diferentes métodos (ou seja, o código que não deve ser alterado no período posterior não é necessário Split).

4. Princípio de Segregação de Interface (ISP)

• Conteúdo: use várias interfaces dedicadas em vez de uma única interface de resumo, ou seja, a classe não precisa implementar as interfaces de que não precisa.
• Por exemplo: a comparação do diagrama de classes é mostrada abaixo. A interface animal IAnimal possui três interfaces: comer, correr, voar e nadar. Todos eles têm um método comum: comer, mas os três animais diferentes de terra, mar e ar têm métodos de movimento diferentes, portanto, não podem ser definidos. A interface unificada deve ser dividida.
  

5. Lei de Demeter (Lod)

Conteúdo: um objeto deve manter um entendimento mínimo de outros objetos, também conhecido como Princípio do Menor Conhecimento (LKP), enfatizando que ele se comunica apenas com amigos , não com estranhos . Amigos são classes de variáveis ​​membros, parâmetros de entrada e saída de métodos .
Por exemplo: A comparação do diagrama de classes é a seguinte: O chefe Boss precisa verificar o número de cursos lançados, por isso quero que o TeamLeader conte, o TeamLeader informa o resultado ao Boss, o Boss não precisa conhecer as informações do curso, seus parâmetros de método precisam passar apenas pelo TeamLeader, portanto O TeamLeader é um amigo e não um amigo do Course, portanto, evite introduzir a classe Course dentro do método. Os parâmetros do método TeamLeader incluem Course, então eles são amigos do Course, portanto as informações do Course devem ser criadas e colocadas no TeamLeader. O primeiro método é criar informações do curso no Boss e repassá-las ao TeamLeader, que não está de acordo com o princípio Dimit.

6. Princípio da Substituição de Liskow (LSP)

• Conteúdo:

  • Vantagens da herança:
    • Para melhorar a reutilização de código, as subclasses têm métodos e propriedades da classe pai;
    • Melhorar a escalabilidade do código, a subclasse pode ser semelhante à classe pai, mas diferente da classe pai, mantendo as características do self;
  • Desvantagens da herança:
    • Intrusão: a herança é invasiva, desde que a herança deva ter todos os métodos e propriedades da classe pai;
    • Não é flexível o suficiente: as subclasses são restritas até certo ponto, reduzindo a flexibilidade do código;
    • Alto acoplamento: aumento do acoplamento, quando as constantes, variáveis ​​ou métodos da classe pai são modificados, a modificação da subclasse precisa ser considerada; portanto, uma vez que a classe pai foi alterada, pode causar resultados muito ruins e muito código deve ser refatorado .

• Princípio: A pedra angular da herança e reutilização, somente quando a classe derivada pode substituir a classe base, a função não é afetada, ou seja, a classe base não é afetada por nenhuma alteração na subclasse, então a classe base pode ser realmente reutilizada.

• Métodos específicos (para garantir que a subclasse substitua os resultados do código da classe pai são consistentes):

  • As subclasses devem implementar os métodos abstratos da classe pai , mas não devem substituir os métodos não abstratos (implementados) da classe pai .
  • Você pode adicionar seus próprios métodos exclusivos nas subclasses .

• Quando a subclasse substitui o método da superclasse, as pré-condições do método (ou seja, os parâmetros formais do método) ficam mais relaxadas do que os parâmetros de entrada do método da superclasse .

• Quando uma classe filha substitui um método pai ou implementa um método abstrato da classe pai **, as pós-condições do método (ou seja, o valor de retorno do método) são mais rígidas que a classe pai **.

7. Princípio de reutilização de compostos / agregados (CARP)

Conteúdo: tente usar a composição do objeto (has-a) / agregação (contains-a) em vez da herança para reduzir o acoplamento entre as classes.