Por Luis Rodriguez
En Lean Mind, siempre estamos buscando la mejor forma de resolver los problemas de nuestros colaboradores, aportando el máximo valor. Nos encanta programar y hacer las cosas lo mejor posible.
Una definición que me gusta mucho de la calidad de código, es aquel que es fácil de modificar. Es una definición que da Martin Fowler sobre refactoring incrementar la calidad del código que parafrasea a Kent Beck.
Muchas veces en los proyectos en los que ayudamos, nos encontramos muchos problemas en el código. Uno que es muy destacable y muy común es el acoplamiento, que es la incapacidad de poder cambiar/mejorar el código.
Cuando estamos frente al ordenador desarrollando una nueva funcionalidad, creo que es importante detenernos en los pequeños detalles, de esta forma podremos hacer el código mucho más sostenible. También podemos aplicar este pequeño cambio, cuando estemos aplicando la ley del boyscout o en nuestros refactorings cotidianos.
Viendo el siguiente código, podemos ver que tiene muchos parámetros de entrada, lo cual dificulta la legibilidad y la capacidad de cambio porque hay un acoplamiento fuerte.
public class SignUpService
{
private readonly IUserRepository userRepository;
public SignUpService(IUserRepository userRepository)
{
this.userRepository = userRepository;
}
public void SignUp(string email, string password, string name, int age, string address)
{
if (userRepository.Exist(email))
throw new ArgumentException();
userRepository.Save(email, password, name, age, address);
}
}
Un refactor que se nos puede plantear para aumentar la sostenibilidad es: Introduce Object Param En vez de tener muchos parámetros de entrada en un método, es mejor tener una clase que aglutine todos esos datos de entrada, como se puede ver en el siguiente código:
public class SignUpService
{
private readonly IUserRepository userRepository;
public SignUpService(IUserRepository userRepository)
{
this.userRepository = userRepository;
}
public void SignUp(UserSignUpArgs args)
{
if (userRepository.Exist(args.Email))
throw new ArgumentException();
var user = new Model.User(email: args.Email, password: args.Password, name: args.Name, age: args.Age, address: args.Address);
userRepository.Save(user);
}
}
Ahora la pregunta sería, ¿cuántos parámetros tendríamos que pasar a un método? Según Robert C. Martin, el autor del libro Clean Code. Lo ideal sería que los métodos no reciban ningún parámetro. Esto es porque se reduce la carga cognitiva y es más fácil de comprender cuando se lee.
Se nos puede ocurrir que hagamos todo global y, de esta forma no tenemos parámetros en los métodos, pero al hacer las variables globales, estamos haciendo que la aplicación sea difícil de predecir, porque su estado es global y puede ser modificado desde cualquier punto. Por lo tanto, es mucho más fácil cometer un error. En general, no es una buena idea tener variables globales.
Creo que lo sensato es tener como máximo 3 parámetros. Siempre hay que aplicar el sentido común y tener en cuenta el contexto en el que nos encontremos. Por ejemplo, para el método factoría de un modelo en el dominio, puede ser normal tener más de tres parámetros, como podemos ver en el ejemplo siguiente:
public class User
{
private string Email { get; }
private string Password { get; }
private string Name{ get; }
private int Age { get;}
private string Address { get; }
private User(string email, string password, string name, int age, string address)
{
Email = email;
Password = password;
Name = name;
Age = age;
Address = address;
}
public static User Create(string email, string password, string name, int age, string address)
{
return new User(email, password, name, age, address);
}
}
Conclusión:
Como hemos visto, es una pequeña mejora en el código que parece que no aporta nada, pero, repetida en el tiempo, obtenemos un código mucho menos acoplado, más fácil de cambiar.
Espero que te haya sido de utilidad.
Happy Coding!!!
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista