Eu li que o princípio de substituição de Liskov é violado se:
As pré-condições são reforçadas, ou
Pós-condições são enfraquecidas
Mas ainda não entendi completamente como esses dois pontos violariam o princípio da substituição de Liskov. Alguém pode explicar com um exemplo. Especificamente, como qualquer uma das condições acima causaria uma situação em que um objeto de subclasse não pode ser substituído por um objeto de superclasse?
Respostas:
Suponha que sua classe básica funcione com um membro int. Agora, seu subtipo exige que o int seja positivo. Isso é pré-condições reforçadas, e agora qualquer código que funcionou perfeitamente bem antes com ints negativos é quebrado.
Da mesma forma, assuma o mesmo cenário, mas a classe base usada para garantir que o membro seria positivo após ser chamado. Em seguida, o subtipo altera o comportamento para permitir ints negativos. O código que funciona no objeto (e assume que a pós-condição é um int positivo) agora está quebrado, pois a pós-condição não é mantida.
Estes são obviamente exemplos triviais, mas o conceito é válido. Coisas como deixar uma conexão de arquivo / banco de dados aberta é um exemplo de uma pós-condição facilitada que leva a problemas.
Invariável - modelo de SelfDrivingVehicle que permanece inalterado em todos os subtipos, ou seja, na ordem em que ele executa os comportamentos substituídos para chegar ao destino.
Vamos supor mais um método aqui
-List<SelfDrivingVehicle> vehicles
+Add(SelfDrivingVehicle vehicle)
vehicles.add(vehicle)
Pré-condição - SelfDriveVehicle o tipo base não possui veículos (aqui o contexto é Add) e está na Weakened Precondition, que não pode ser alterada por nenhum de seus subtipos, alterando os veículos de propriedade e Fortalecendo-o explicitamente. Qualquer um dos subtipos pode chamar apenas Add.
Pós-condição - Depois que o Add é chamado, o Tipo Base está na Pós-Condição Reforçada, que não pode ser enfraquecida pelos subtipos, alterando o valor dos veículos.
O estado do tipo base volta ao seu estado original quando o comportamento de adição é chamado.
Este exemplo é praticamente derrotado até a morte, mas considere a possibilidade de Quadrado / Retângulo ou Círculo / Elipse. Suponha que você tenha um retângulo de classe base que define um objeto com comprimento e largura. Se você tiver uma classe Square que herda a classe Rectangle, ela teria uma regra em seu setter / getter que exigiria que qualquer alteração no comprimento ou largura alterasse sua contraparte. Esses requisitos dimensionais reforçam as pré-condições, porque um retângulo substituído por um quadrado estaria ausente desses requisitos dimensionais. Suponha que você reverta a herança para que um retângulo herda um quadrado; você estaria enfraquecendo as condições das postagens relaxando os requisitos dimensionais para permitir que o retângulo se comporte de maneira independente.
No entanto, se você remover o recurso de alteração dimensional, o princípio de substituição é válido porque, se nem um Retângulo nem um Quadrado podem alterar as dimensões, eles têm condições pré e pós iguais, independentemente da herança. Ambos têm um comprimento, ambos têm uma largura e nenhum deles pode alterar esses valores.
ref: Wikipedia - http://en.wikipedia.org/wiki/Liskov_substitution_principle