Al leer artículos sobre ISP, parece haber dos definiciones contradictorias de ISP:
Según la primera definición (consulte 1 , 2 , 3 ), el ISP establece que las clases que implementan la interfaz no deben ser forzadas a implementar funcionalidades que no necesitan. Por lo tanto, la interfaz de grasa IFat
interface IFat
{
void A();
void B();
void C();
void D();
}
class MyClass: IFat
{ ... }
se debe dividir en interfaces más pequeñas ISmall_1 y ISmall_2
interface ISmall_1
{
void A();
void B();
}
interface ISmall_2
{
void C();
void D();
}
class MyClass:ISmall_2
{ ... }
ya que de esta manera mi MyClass es capaz de implementar solo los métodos que necesita ( D() y C() ), sin ser forzado a proporcionar implementaciones ficticias para A() , B() y C() :
Pero de acuerdo con la segunda definición (consulte 1 , 2 , respuesta de Nazar Merza ), ISP declara que los métodos de llamada MyClient en MyService no deberían ' t Esté al tanto de los métodos en MyService que no necesita. En otras palabras, si MyClient solo necesita la funcionalidad de C() y D() , entonces en lugar de
class MyService
{
public void A();
public void B();
public void C();
public void D();
}
/*client code*/
MyService service = ...;
service.C();
service.D();
deberíamos segregar los métodos MyService's en interfaces específicas del cliente :
public interface ISmall_1
{
void A();
void B();
}
public interface ISmall_2
{
void C();
void D();
}
class MyService:ISmall_1, ISmall_2
{ ... }
/*client code*/
ISmall_2 service = ...;
service.C();
service.D();
Por lo tanto, con la definición anterior, el objetivo del ISP es " facilitar la vida de las clases implementando la interfaz IFat ", mientras que con el último el objetivo del ISP es " hacer el La vida de los clientes llama a los métodos de MyService más fáciles ".
¿Cuál de las dos definiciones diferentes de ISP es realmente correcta?
@MARJAN VENEMA
1.
Entonces, cuando vas a dividir IFat en una interfaz más pequeña, que Los métodos terminan en los que ISmallinterface debe decidirse en función de cómo cohesionados son los miembros.
Aunque tiene sentido colocar métodos cohesivos dentro de la misma interfaz, pensé que con el patrón ISP las necesidades del cliente tienen prioridad sobre la "cohesión" de una interfaz. En otras palabras, pensé con el ISP que deberíamos agrupar dentro de la misma interfaz aquellos métodos que necesitan los clientes en particular, incluso si eso significa dejar fuera de esa interfaz aquellos métodos que deberían, por el bien de la cohesión, también ser incluidos dentro de esa misma interfaz.
Por lo tanto, si hubiera muchos clientes que solo necesitarían llamar a CutGreens , pero no también a GrillMeat , entonces para cumplir con el patrón de ISP solo deberíamos poner CutGreens dentro de ICook , pero no también GrillMeat , a pesar de que los dos métodos son altamente cohesivos?
2.
Creo que su confusión proviene de un supuesto oculto en el Primera definición: que las clases implementadoras ya están siguiendo. El principio de responsabilidad única.
Al "implementar clases que no siguen a SRP", ¿se refiere a las clases que implementan IFat o a las clases que implementan ISmall_1 / ISmall_2 ? Supongo que te refieres a las clases que implementan IFat ? Si es así, ¿por qué asumes que no siguen SRP?
gracias