Etiqueta: Programación
Principios SOLID – Single Responsability Principle
Los principios SOLID fueron acuñados por Robert C Martin (aka Uncle Bob), una de las leyendas de la ingeniería de software y co-creador del manifiesto Agile.
Las siglas SOLID describen 5 principios básicos para la programación orientada a objetos que sirven de base para la escritura de un código más estructurado y limpio:
- Single Responsibility Principle
- Open / Closed principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Hablemos del principio Single Responsibility en esta ocasión. El principio sostiene que una clase debe tener una y sólo una responsabilidad o un único trabajo, y por tanto una sola razón para ser modificada.
Para comprender este principio, veamos esta clase:
public class User {
public int UserId {get; set;}
public string UserName {get; set;}
public string Email {get; set;}
public string AddressLine1 {get; set;}
public string AddressLine2 {get; set;}
public string City{get; set;}
public bool IsLogin(User user){get; set;}
public User UpdateAddress(User user) {}
}
Podemos observar que esta clase tiene cosas relacionadas con la dirección física del usuario, pero en realidad esta clase User sólo debería encargarse de definir campos que estén relacionadas con la entidad User en si (en este caso el UserName y el Email, ya que esta es una clase base para un sistema de Log In). Por tanto, el principio de Single Responsibility no se cumple ya que esta clase tiene muchas responsabilidades (actualizar la dirección del usuario no está tan relacionada con su habilidad de ingresar al sistema)
Por tanto, para este escenario, lo mejor es que todo lo relacionado a la dirección del usuario se separe en una clase cuya única responsabilidad sea actualizar esa información, en lugar de tenerlo todo en la clase User. Crearemos pues la clase Address para mover todos los parámetros y métodos relacionados con la dirección alli:
public class User {
public int UserId {get; set;}
public string UserName {get; set;}
public string Email {get; set;}
public bool IsLogin(User user) {}
}
public class Address {
public int UserId {get; set;}
public string AddressLine1 {get; set;}
public string AddressLine2 {get; set;}
public string City {get; set}
public User UpdateAddress(Address address) {}
}
Podemos observar en este caso cómo las responsabilidades están correctamente repartidas entre las dos clases, y ambas cumplen el principio de Single Responsibility ya que su scope está acotado a una única entidad (User, Address). Por otro lado, si queremos modificar o adicionar campos o métodos para cada entidad, sólo lo haremos para extender la funcionalidad de esa entidad y no debe afectar el código previamente escrito.
En la siguiente ocasión hablaremos del principio Open / Closed.
Scoped vs Singleton vs Transient – ¿Cuál usar?
La inyección de dependencias en .NET Core nos permite de manera simple seguir el patrón DI y optimizar el uso de las clases y servicios que inyectamos a través de la aplicación. Una de las cosas que más hay que tomar en cuenta es el uso de recursos y de memoria que esto conlleva. Si nosotros inyectamos dependencias de manera indiscriminada copiando instancias de objetos cada que hacemos ese proceso, muy pronto empezaremos a llenar la memoria de objetos que probablemente no sean necesarios y al momento de recibir muchas peticiones corremos el riesgo de degradar el performance de nuestra aplicación.
Para optimizar el uso de la inyección de dependencias, .NET Core nos ofrece varios scopes para generar la inyección en la clase Startup.cs
:
- Transient .- Cuando inyectamos una dependencia usando Transient, se generará una copia del objeto cada vez que esta dependencia sea requerida (tanto durante el request como a través de varios requests). Es el tipo de inyección más común pero también el que ocupa más memoria:
services.Addtransient<IMyInterface, Instance>();
- Scoped .- Scoped genera una única instancia del objeto durante el ciclo de vida de un request, pero generará un nuevo objeto en cada request que invoquemos:
services.AddScoped<IMyInterface, Instance>()
- Singleton .- Como su nombre lo indica, Singleton generará una única instancia del objeto tanto durante el ciclo de vida de un request como para todos los requests.
services.AddSingleton<IMyInterface, Instance>()
Entonces, ¿dónde debería aplicar cada caso?. Bien, esto depende del uso que le daremos a nuestra dependencia:
- Por ejemplo, si queremos utilizar objetos donde queremos que dicha operación sea única y que sus propiedades no se compartan por otras instancias (por ejemplo, una transacción única) entonces debemos usar Transient.
- Si por ejemplo, nuestro objeto contiene propiedades que pueden compartirse durante el ciclo de vida de un request (por ejemplo, una conexión a base de datos que va a realizar varias consultas para obtener un resultado único) deberíamos utilizar Scoped
- En cambio, si nuestro objeto necesita compartir propiedades con todas las instancias y todos los ciclos de vida de los requests de nuestra aplicación (por ejemplo, un servicio que conecta a un recurso como una impresora o cualquier servicio que utilice colas de entrada / salida) deberíamos utilizar Singleton.
Espero estos ejemplos les sean de utilidad. Hasta la próxima.
Comentarios recientes