Falto agregar IDesingActivities a ScrumMaster
Introducción
Principios SOLID en C# y .NET: Teoría y Práctica
Requisitos y Herramientas para Curso de Principios SOLID en C#
Prácticas de Código Limpio y Principios SOLID
Principios SOLID en Programación Orientada a Objetos
Principio de responsabilidad única
Principio de Responsabilidad Única en Programación Orientada a Objetos
Aplicación del Principio de Responsabilidad Única en C#
Principio de abierto/cerrado
Principio Abierto-Cerrado en C# para Extender Código sin Modificarlo
Aplicación del Principio de Abierto/Cerrado en Programación
Principio de sustitución de Liskov
Principio de Sustitución de Liskov en Programación SOLID
Aplicación del Principio de Sustitución de Liskov en Código SOLID
Principio de segregación de la interfaz
Principio de Segregación de Interfaces en Programación C#
Segregación de Interfaces en Programación SOLID
Principio de inversión de la dependencia
Principio de Inversión de Dependencia en Programación SOLID
Aplicación del Principio de Inversión de Dependencias en C#
Pruebas Unitarias y Principio de Inversión de Dependencias en .NET
Cierre
Principios Solid en C Sharp: Mejora y Aplicación Práctica
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
En el desarrollo de software, la segregación de interfaces es un principio fundamental que asegura que las interfaces no se sobrecarguen de responsabilidades. Una interfaz bien diseñada debe ser específica para un conjunto de tareas relacionadas, evitando imponer a las clases que implementan dicha interfaz métodos que no necesitan. Vamos a explorar cómo aplicar este principio mediante un caso práctico.
En el escenario presentado, se tenía la interfaz IActivities
, la cual contiene muchas actividades o métodos que no todas las clases necesitan implementar. Por ejemplo:
Developer
solo necesita implementar el método Develop
.Tester
, aunque utiliza IActivities
, no necesita el método Develop
, pero sí requiere de una funcionalidad para pruebas.Scrum Master
no estaría desarollando o probando, sino planificando y comunicando.Estas discrepancias resaltan que las interfaces se han diseñado de forma incorrecta, creando una dependencia innecesaria de métodos que no se aplican a cada rol.
La solución es dividir la interfaz grande en diversas interfaces más especializadas y asignarlas correctamente a las clases correspondientes. En este ejemplo práctico, se crean cuatro interfaces nuevas:
public interface IWorkingActivities {
void Plan();
void Communicate();
}
public interface IDesignActivities {
void Design();
}
public interface IDevelopActivities {
void Develop();
}
public interface ITestActivities {
void Test();
}
Cada clase ahora implementa solo las interfaces que reflejan sus verdaderas responsabilidades:
IWorkingActivities
e IDevelopActivities
.IWorkingActivities
y ITestActivities
.IWorkingActivities
e, hipotéticamente, partes de IDesignActivities
.Este diseño permite un código más limpio y evita errores porque cada clase solo es responsable de las actividades que realmente realiza.
Una buena práctica cuando hay actividades comunes es crear una interfaz madre que herede de otras interfaces. Por ejemplo, la interfaz IActivitiesComplete
puede combinar métodos de múltiples interfaces:
public interface IActivitiesComplete : IWorkingActivities, IDesignActivities, IDevelopActivities, ITestActivities {}
Esta técnica es útil cuando un nuevo rol incluye todas o varias de las actividades, como podría ser el caso de un Architect
, quien participa en cada fase del desarrollo de software.
Para consolidar lo aprendido, puedes intentar crear un nuevo rol dentro de tu proyecto. Elige un rol común en una empresa de software, como un Product Manager
, y diseña interfaces para describir sus actividades específicas. Luego, implementa esas interfaces siguiendo el principio de segregación.
Este tipo de prácticas te ayudará a comprender mejor los beneficios del principio SOLID, aumentando la eficiencia y mantenibilidad de tu código. ¡No olvides que este es un camino de aprendizaje continuo!
Aportes 13
Preguntas 3
Falto agregar IDesingActivities a ScrumMaster
Arquitecto -> Architect 😛
¡Wow! Se puede hacer herencia entre interfaces, esa no me la sabía. 😄
Lindo ejemplo suma! me encantaria que sean “Mas relacionados a trabajos” no un codigo prolijo, y entendible.
Este curso es demasiado bueno para entender SOLID ✌.
Muy bien explicado
Creé una interfaz para los ingenieros Cloud:
namespace InterfaceSegregation
{
public class Cloud
{
public void CreateCloud()
{
System.Console.WriteLine("I'm creating the Cloud Infrastructure");
}
}
}
Y la uso en Program.cs:
using InterfaceSegregation;
new Developer().Develop();
new Cloud().CreateCloud();
Reto:
Role DevOps
namespace InterfaceSegregation
{
public class DevOps : IDeploy
{
public DevOps()
{
}
public void Deploy()
{
Console.WriteLine("The new implementation will be release on November 30");
}
}
}
Activity: Deploy
namespace InterfaceSegregation
{
public interface IDeploy
{
void Deploy();
}
}
Cuando no hay access modifier en una interfaz, esta toma por defecto el accesso private
, aparentemente.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?