Dê exemplos para analisar o significado do princípio de substituição de Richter na programação do Java Design Pattern

O princípio de substituição de Rich, OCP, como o princípio de alto nível da OO, defende o uso de "abstração" e "polimorfismo" para mudar a estrutura estática no design em uma estrutura dinâmica para manter o gabinete do projeto. "Resumo" é uma função fornecida pelo idioma. "Polimorfismo" é implementado pela semântica herdada.

O princípio de substituição Richter contém os 4 significados a seguir:

1. As subclasses podem implementar métodos abstratos da classe pai, mas não podem substituir os métodos não abstratos da classe pai.
2. Você pode adicionar seus próprios métodos exclusivos à subclasse.
3. Quando uma classe infantil substitui ou implementa um método de classe pai, as pré -condições de um método (ou seja, os parâmetros formais de um método) são mais soltos que os parâmetros de entrada do método da classe pai.
4. Quando um método de subclasse implementa o método abstrato da classe pai, a condição pós -condição do método (isto é, o valor de retorno do método) é mais rigorosa que a classe pai.

Agora podemos explicar os quatro significados acima.

As subclasses podem implementar métodos abstratos da classe pai, mas não podem substituir os métodos não abstratos da classe pai.

Quando estamos projetando sistemas, geralmente projetamos interfaces ou classes abstratas e, em seguida, as subclasses implementam métodos abstratos. O princípio de substituição Richter é realmente usado aqui. É fácil entender que as subclasses podem implementar o método abstrato da classe pai. De fato, as subclasses devem implementar completamente o método abstrato da classe pai, mesmo que eles escrevam um método vazio, caso contrário, eles compilarão e relatarão um erro.

O ponto-chave do princípio de substituição de Richter é que ele não pode cobrir os métodos não abstratos da classe pai. Qualquer método bem implementado na classe pai está realmente definindo uma série de especificações e contratos. Embora não force todas as subclasses a atender a essas especificações, se a subclasse modificar arbitrariamente esses métodos não abstratos, ele danificará todo o sistema de herança. O princípio da substituição de Lizur expressa esse significado.

Na idéia de design orientada a objetos, a herdadora desse recurso traz grande conveniência para o design do sistema, mas também existem alguns riscos que vêm dele. Os exemplos a seguir são usados para ilustrar o risco de herança. Precisamos concluir a função de subtrair dois números e a classe A é responsável por isso.

 classe A {public int func1 (int a, int b) {return ab; }} public class cliente {public static void main (string [] args) {a a = novo a (); System.out.println ("100-50 ="+A.FUNC1 (100, 50)); System.out.println ("100-80 ="+A.FUNC1 (100, 80)); }}

Resultados em execução:

 100-50 = 50100-80 = 20

Posteriormente, precisamos adicionar uma nova função: complete a adição de dois números e, em seguida, resumi -o com 100, e a classe B é responsável. Ou seja, a classe B precisa concluir duas funções:
Os dois números subtraem.
Adicione dois números e adicione 100.
Como a classe A implementou a primeira função, após a classe B herda a classe A, você só precisa concluir a segunda função. O código é o seguinte:

 A classe B estende A {public int func1 (int a, int b) {return a+b; } public int func2 (int a, int b) {return func1 (a, b) +100; }} public class cliente {public static void main (string [] args) {b b = new b (); System.out.println ("100-50 ="+B.FUNC1 (100, 50)); System.out.println ("100-80 ="+B.FUNC1 (100, 80)); System.out.println ("100+20+100 ="+B.FUNC2 (100, 20)); }}

Após a conclusão da classe B, o resultado da execução:

 100-50 = 150100-80 = 180100+20+100 = 220

Descobrimos que a função de subtração que estava originalmente em execução normalmente teve um erro. O motivo é que, quando a classe B nomeou o método, ele reescreve acidentalmente o método da classe pai, causando todos os códigos que executam as funções de subtração para chamar o método de reescrita da classe B, causando erros na função normal original. Neste exemplo, depois de se referir à função concluída pela classe Base A e alterando para a subclasse B, ocorreu uma exceção. Na programação real, geralmente concluímos novas funções reescrevendo o método da classe pai. Embora seja simples de escrever, a reutilização de todo o sistema de herança será relativamente ruim, especialmente quando o polimorfismo é usado com mais frequência, a probabilidade de erros de operação do programa é muito alta. Se você precisar reescrever o método da classe pai, a abordagem mais comum é: a classe pai original e a classe infantil herdam uma classe base mais popular, remova a relação de herança original e use dependência, agregação, combinação e outros relacionamentos.