O Princípio de Substituição de Liskov (LSP) é importante e comum no design orientado a objetos (OOD) Vamos resumir os pontos de conhecimento do Princípio de Substituição de Liskov, incluindo:
- Definição da Wikipedia
Na programação orientada a objetos, o princípio de Substituição de Liskov é uma definição especial de subtipos. Foi proposto pela primeira vez por Barbara Liskov em um discurso intitulado "Abstração e hierarquia de dados" em uma conferência em 1987.
O conteúdo do Princípio de Substituição de Liskov pode ser descrito como: "Objetos de classe derivada (subclasse) podem substituir seus objetos de classe base (superclasse) no programa." O conteúdo acima não é o texto original de Liskov, mas foi traduzido por Robert Martin (Robert Martin) Interpretação do texto original. O texto original é:
Barbara Liskov e Jeannette Wing publicaram um artigo em 1994 e propuseram o princípio de substituição de Liskov acima.
SÓLIDO - O L em "SÓLIDO" refere-se ao Princípio de Substituição de Liskov.
Definição 1: se para cada objeto o1 do tipo T1, houver um objeto o2 do tipo T2, de modo que quando todos os objetos P definidos por T1 forem substituídos por o2 por todos os objetos o1, o comportamento do programa P não seja alterado. , O tipo T2 é um subtipo do tipo T1.
Definição 2: Todas as referências à classe base devem poder usar de forma transparente os objetos de suas subclasses.
Princípio de substituição de Liskov (LSP): todas as referências à classe base (classe pai) devem poder usar de forma transparente os objetos de suas subclasses.
Ainda é um pouco diferente do polimorfismo.O Princípio de Substituição de Liskov afirma que a transformação para cima é segura (ou seja, objetos de subclasse são convertidos em objetos de superclasse) .O polimorfismo só pode ser alcançado sob a premissa de garantir a segurança do tipo.
"O Princípio da Substituição de Liskov afirma que a transformação para cima é segura (ou seja, objetos de subclasse são convertidos em objetos de superclasse), e o polimorfismo só pode ser alcançado sob a premissa de garantir a segurança do tipo", disse o professor Liu com muita precisão. O princípio de substituição inclui polimorfismo, e um polimorfismo melhor pode ser projetado com base no princípio de substituição Richter.
Deixe-me expressar minha opinião. O autor disse que muita imagem invertida depende do princípio de inversão, que é orientado para a programação de interfaces. Acho que o princípio de substituição de Richter faz uma declaração clara da definição de herança, porque os seis princípios de design estão inter-relacionados. Absolutamente não deve ser uma programação orientada a interface, devemos explicar a diferença entre o princípio Richter e vários outros princípios, e não a semelhança.
Especificamente, o polimorfismo é um mecanismo orientado a objetos (um dos três principais recursos do orientado a objetos), que inclui polimorfismo estático (sobrecarga de funções) e polimorfismo dinâmico (cobertura de função ou ligação dinâmica), geralmente Refere-se ao polimorfismo dinâmico, ou seja, quando o programa está sendo executado, o comportamento (método) do objeto da subclasse pode substituir o comportamento (método) do objeto da classe pai. O Princípio de Substituição de Liskov (LSP) é um princípio de design orientado a objetos. Objetos de subclasse podem ser usados onde quer que a classe pai seja usada. Isso estabelece as bases para a implementação do princípio de abertura e fechamento, permitindo programar para a classe pai e Em tempo de execução, determine qual objeto da subclasse usar, melhorando a escalabilidade e a capacidade de manutenção do sistema. No princípio da substituição de Liskov, o mecanismo polimórfico é realmente usado.Quando o objeto da subclasse substitui o objeto da classe pai, o comportamento da classe pai pode ser substituído pelo polimorfismo.
O Princípio de Substituição de Liskov nos diz que, em um software, um objeto de classe base é substituído por seu objeto de subclasse, o programa não gera erros e exceções, e o inverso não é verdadeiro.Se uma entidade de software usar um objeto de subclasse Palavras, pode não ser necessariamente capaz de usar objetos da classe base. Por exemplo: eu gosto de animais, então devo gostar de cães, porque os cães são uma subclasse de animais; mas eu gosto de cães, e não posso concluir que gosto de animais porque não gosto de ratos, embora também sejam animais.
Por exemplo, existem duas classes, uma classe é BaseClass, a outra é classe SubClass e a classe SubClass é uma subclasse da classe BaseClass, se um método puder aceitar um objeto de classe base Base do tipo BaseClass, como: method1 (base), Em seguida, ele deve aceitar um objeto de subclasse sub do tipo BaseClass, o método1 (sub) pode ser executado normalmente. Por exemplo, um método method2 aceita o objeto subclasse sub do tipo BaseClass como parâmetro: method2 (sub); geralmente, não pode haver method2 (base), a menos que seja um método sobrecarregado.
O princípio de substituição de Leeb é uma das maneiras importantes de realizar o princípio de abertura e fechamento.Como os objetos de subclasse podem ser usados onde quer que o objeto de classe base seja usado, tente usar o tipo de classe base para definir o objeto no programa e execute novamente em tempo de execução. Determine seu tipo de subclasse e substitua o objeto de classe pai pelo objeto de subclasse.
Tente usar o tipo de classe base para definir o objeto no programa e, em seguida, determine seu tipo de subclasse no tempo de execução e substitua o objeto de classe pai pelo objeto de subclasse
Parece que foi implementada a conveniência da classe pai.A subclasse não deve ser reescrita o máximo possível.A subclasse pode implementar os métodos que não são implementados na classe pai?
Somente a reescrita de métodos virtuais é polimórfica, e a reescrita de métodos não virtuais tem pouco significado para a programação orientada a interface; portanto, entender o princípio de Richter nos permite pensar em programação orientada a interface ...
Em JAVA, o polimorfismo viola o Princípio de Substituição de Liskov? ?
O Princípio de Substituição de Liskov requer subclasses para evitar a substituição de métodos da classe pai, mas uma das condições do polimorfismo é exigir que as subclasses substituam os métodos da classe pai. Portanto, não entendo a relação entre o Princípio da Substituição de Liskov, herança e polimorfismo. Peça ao grande deus que responda e comece a se curvar.
A definição original de LSP é mais complicada: nossa interpretação geral do Princípio de Substituição de Liskov é que objetos de subclasse podem substituir objetos de classe pai e a lógica do programa permanece inalterada. O princípio da substituição de Leeb tem pelo menos os dois seguintes significados:
O princípio de substituição de Leeb é para herança.Se herança é para reutilização de código, ou seja, para métodos compartilhados, o método da classe pai compartilhada deve permanecer inalterado e não pode ser redefinido pela subclasse. A subclasse só pode estender a função adicionando novos métodos.A classe pai e a subclasse podem ser instanciadas e o método de herança da subclasse é o mesmo que a classe pai.Para onde a classe pai chama o método, a subclasse também pode chamar a mesma herança O método lógico é o mesmo da classe pai.Quando o objeto da classe pai é substituído pelo objeto da subclasse, é claro, a lógica é consistente e não há problema.
Se o objetivo da herança é o polimorfismo, e a premissa do polimorfismo é que a subclasse substitui e redefine o método da classe pai, para cumprir com o LSP, devemos definir a classe pai como uma classe abstrata e definir métodos abstratos para permitir que a subclasse redefina Esses métodos, quando a classe pai é uma classe abstrata, a classe pai não pode ser instanciada; portanto, não há objeto de classe pai instável no programa. Não há possibilidade de que a subclasse substitua a instância da classe pai (não há nenhuma instância da classe pai) quando a lógica é inconsistente.
A situação mais comum que não atende ao LSP é que a classe pai e a classe filho são instáveis e não abstratas, e os métodos da classe pai são redefinidos pela classe filho.A herança de implementação dessa classe causará uma diferença entre a classe pai e a classe filho. Um forte acoplamento, ou seja, o fato de propriedades e métodos que não estão realmente relacionados serem forçados juntos, não é propício para a expansão e manutenção do programa.
Como cumprir o LSP? Para resumir uma sentença, tente não herdar da classe pai instável, mas usar herança com base em classes e interfaces abstratas.
É muito completo. Para ser franco, todo mundo está programando com base em abstração, não concreta. Isso também pode ser alcançado: aberto à extensão (com base na abstração) e proibido de alterações (com base no concreto).
O princípio de transformação de Liskov exige que as subclasses herdam da herança abstrata em vez da concreta.Se elas herdarem da abstração, as subclasses devem substituir os métodos da superclasse. Portanto, o princípio da escala Richter e o polimorfismo são complementares! Quanto ao primeiro artigo que você disse, eu não ouvi falar dele.
Depois de ler vários artigos, o autor disse que o princípio de transformação de Liskov deve evitar a reescrita dos métodos não abstratos da classe pai, e a implementação polimórfica é alcançada reescrevendo os métodos abstratos, para que não haja conflito.
Não viole o polimorfismo da substituição de Liskov: reescrevendo o método abstrato da classe pai
A idéia principal é: a subclasse deve ser capaz de substituir sua classe base. Essa idéia é refletida nas restrições do mecanismo de herança. Somente quando a subclasse pode substituir a classe base, o sistema pode garantir que o sistema reconheça a subclasse durante o tempo de execução, que é a base para garantir a reutilização da herança. No comportamento específico da classe pai e da classe filho, devemos entender estritamente o relacionamento e as características na hierarquia de herança e substituir a classe base pela classe filho, e o comportamento do programa não será alterado. Ao mesmo tempo, essa restrição não é verdadeira ao contrário, as subclasses podem substituir a classe base, mas a classe base não substitui necessariamente a subclasse.
O princípio da substituição de Liskov concentra-se principalmente na fundação da abstração e do polimorfismo na herança.Portanto, somente seguindo o princípio de substituição de Liskov é que a reutilização da herança pode ser assegurada com segurança. O método de implementação é uma programação orientada a interface: a parte pública é abstraída como uma interface de classe base ou classe abstrata e, através da Extract Abstract Class, um novo método é implementado na subclasse, substituindo a classe pai para suportar a mesma responsabilidade.
O princípio de substituição de Liskov é o princípio de design do mecanismo de herança.A violação do princípio de substituição de Liskov inevitavelmente levará à violação do princípio de aberto e fechado.
O princípio de substituição de Liskov pode garantir que o sistema tenha boa escalabilidade e, ao mesmo tempo, implementa um mecanismo de abstração baseado em polimorfismo, que pode reduzir a redundância de código e evitar a discriminação de tipos em tempo de execução.
