3:12 0 0
Principios SOLID Interface Segregation Principle

Principios SOLID Interface Segregation Principle

  DrUalcman |  marzo 72022

Single responsabilitie Principle [SRP]

Open/Close Principle [OCP]

Liskov Substitutio Principle [LSP]

Interface Segregation Principle [ISP]

Definición: Los clientes no tienen que ser forzados a utilizar funciones que no utilicen. Mejor que un interfaz con muchos métodos es, varios interfaces con pocos métodos agrupados.

De hecho siguiendo este principio y teniendo en cuenta el principio anterior de LSP, he pecado de segregar demasiado al punto de crear practicamente un interfaz para sólo un método. Ni tanto ni tan calvo, pero lo que si se puede aplicar, y desde luego tiene muchas ventajas, es que es mejor tener una clase que implemente varios interfaces, y que cada interzas sea para un propósito concreto, que tener un interfax todo en uno el cual si alguna función o método no la deseamos nos obligue a tener que implementarla con el típoco error de método no implementado.

Algunas de las ventajas de utilizar ISP es que despedazando una código muy grande en pequeñas porciones, con funciones más específicas, hace que el programa sea más fácil de depurar y de mantener, como por ejemplo.

1. Hay menos código del que preocuparse entre cada clase. Menos código implica menos errores.
2. Un simple método es responsable de muy pocas variantes. Si hay menos vatiantes, solo necetas mirar métodos más pequeños.
3. Si un método con multipe prosibilidades se le pasa a una clase que no soporta todas las posibilidades (llamémolas propiedades) tendremos un error si la case no soporta alguna de las posibilidades.

Ejemplo que no cumple con ISP

Tenemos un interfaz para que calcule el salario de un empleado dependiendo del tipo de pago que reciba el empleado. Dispondremos de tres tipos de empleados diferentes, uno que trabaja a tiempo completo y por hotras, otro que trabaja solo a tiempo completo y otro que trabaja solo por horas. Por lo que podríamos definir una interfaz para relalizar este tipo de trabajo.
public interface IWorker  
{
float CalculateNetSalary();
float CalculateWorkedSalary();
}

public class AllInOneEmployee : IWorker
{
public float HourlyRate { get; set; }
public float HoursInMonth { get; set; }
public float MonthlySalary { get; set; }
public float OtherBenefits { get; set; }
public float CalculateNetSalary() => MonthlySalary + OtherBenefits;
public float CalculateWorkedSalary() => HourlyRate * HoursInMonth;
}

public class FullTimeEmployee : IWorker
{
public float MonthlySalary { get; set; }
public float OtherBenefits { get; set; }
public float CalculateNetSalary() => MonthlySalary + OtherBenefits;
public float CalculateWorkedSalary() => throw new NotImplementedException();
}

public class ContractEmployee : IWorker
{
public float HourlyRate { get; set; }
public float HoursInMonth { get; set; }
public float CalculateNetSalary() => throw new NotImplementedException();
public float CalculateWorkedSalary() => HourlyRate * HoursInMonth;
}

Se aprecia claramente que cuando el empleado sólo trabaja o por tiempo completo o por horas nos hemos visto obligados a implementa un método que no vamos a utilizar y por lo que tenemos que devolver un error del tipo Método no implementado.

Veamos como quedaría esta clase respetando el ISP

En nuestro ejemplo vamos a crear dos interfaces, uno para tiempo completo y otro para tiempo parcial, y una clase implementará los dos interfaces, ya que es un todo en uno el trabajador, un auténtico currante como yo, y luego tenemos al trabajar a tiempo completo y al que trabaja por horas que cada uno implementara el interfaz que necesita

public interface IFullTimeWorker  
{
float CalculateNetSalary();
}

public interface IPartialTiemTimeWorker
{
float CalculateWorkedSalary();
}
public class AllInOneEmployee : IFullTimeWorker, IPartialTiemTimeWorker
{
public float HourlyRate { get; set; }
public float HoursInMonth { get; set; }
public float MonthlySalary { get; set; }
public float OtherBenefits { get; set; }
public float CalculateNetSalary() => MonthlySalary + OtherBenefits;
public float CalculateWorkedSalary() => HourlyRate * HoursInMonth;
}

public class FullTimeEmployee : IFullTimeWorker
{
public float MonthlySalary { get; set; }
public float OtherBenefits { get; set; }
public float CalculateNetSalary() => MonthlySalary + OtherBenefits;
}

public class ContractEmployee : IPartialTiemTimeWorker
{
public float HourlyRate { get; set; }
public float HoursInMonth { get; set; }
public float CalculateWorkedSalary() => HourlyRate * HoursInMonth;
}
Fíjense que bonito que ha quedado el código, más legible y con menos posibilidades de errores, o bueno esa es la teoría, pero luego en la práctica hay veces que tanto interfaz lía un poco.

Conclusiones

Bueno una vez más hasta aquí mi breve explicación e interpretación de lo que es Interface Segregation Principle. Espero que se haya entendido y que me comentéis que os parece. Dicifil de aplicar, fácil, es una tontería, lo que querais.

Dependency Inversion Principle [DIP]

0 Comentarios

 
 
 

Archivo