C sharp - Liskov Substitution Principle (POO)

Hola, quisiera oir vuestra opinion:

Tengo una clase base:

public abstract class ClaseBase{
void abstract Execute();
}

A continuacion dos sub clases:

public class SubClase1{
override void Execute(){
//Haz algo
}
}

public class SubClase2{

public object NuevaPropiedad{get;set;}

override void Execute(){
if (NuevaPropiedad == null) return;
//Haz algo usando NuevaPropiedad
}
}

Romperia SubClase2 el principio de Liskov? Deberia subir "NuevaPropiedad" a la clase base, de esta forma todas las clases tendrian el mismo interfaz, incluso habiendo subclases que no la van a usar?

considero que no se rompe el principio por tener una propiedad adicional en SubClase2, mal harías si pones la propiedad a nivel de la clase base pues como dices tu no es una propiedad comun para las clases hijas como para tenerla para todas. Lo que veo es normal, estas especializando una clase base agregandole una nueva propiedad.

saludos

Hola
Estoy de acuerdo en que es una especializacion y como tal puede agregar propiedades publicas.

El problema viene a la hora de trabajar con abstracciones, supongamos que obtenemos SubClaseA o SubClaseB usando, por ejemplo, una factory:

//...
ClaseBase cb = Factory.Create();
cb.Execute();
//..

Si SubClaseB necesita de 'NuevaPropiedad' para que Execute() se ejecute adecuadamente, en la linea de codigo superior estariamos rompiendo Liskov, ya que necesitariamos saber que tipo de instancia esta siendo devuelta por la Factory, para poder asi asignarle un valor a 'NuevaPropiedad' (mediante type casting) y obtener el resultado adecuado.

En mi opinion, podemos añadir propiedades a subclases en modo de especializacion, siempre que esas propiedades sean usadas por metodos no heredados de la clase base.

Imaginate que Execute devuelve un numero entero, en lugar de ser void.. Que valor devolverias en SubClaseB.Execute() si 'NuevaPropiedad' no ha sido asignada?

buen punto, veo que en el ejemplo de factoria que propones no funcionaria (supongo que habria que atacarlo de otra manera). Pero pensemos en el ejemplo clasico de la clase Forma, de la cual heredan rectangulo y triangulo por ejemplo, y cada cual tiene su metodo para calcular el área, ambos tienen sus propiedades especializadas necesarias para calcular el área.

un codigo cliente podria ser

var formas = List<Forma>
{
new Rectangulo{ propiedadRectangulo1 = 34, propiedadRectangulo2 = 45},
new Triangulo { propiedadTriangulo1 = 2 }
};

foreach(Forma forma in formas)
{
forma.CalcularArea();
}

Considero que se estaria cumpliendo el principio. No me suena mucho que Liskov limite el uso de los miembros de las subclases solo a metodos que no son de la clase base, no se aprovecharia toda la potencia y ventajas de la herencia. claramente no soy experto en el tema :P, pero me ha parecido muy interesante este post para aprender acerca de estos principios.

Saludos

Estoy de acuerdo con tu ejemplo.
Solo estaba llevando el caso a un extremo, como norma general el diseño se debe ajustar a tus necesidades y no a la inversa.

La duda me surgio usando los Code Contracts de Microsoft, si tratas de añadir una precondicion al metodo Execute() de SubClaseB, donde compruebe que 'NuevaPropiedad' no sea nula, el compilador genera un Warning, advertiendote de que no se recomienda añadir precondiciones en sub clases... de ahi me vino a la cabeza Liskov.

A los que no les suenen este tipo de principios sugeriria la seria Head First (Design Patterns y Object oriented Analysis and Design), y a los algo mas experimentados un imprescindible: Agile Patterns and Practices in C# - Robert C Martin

Saludos