leanmind logo leanmind text logo

Blog

BDD

Behaviour-driven Development es una técnica para tomar mejores requisitos de producto.

Controla los parámetros de un método

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!!!

Publicado el 18/02/2025 por
Luis image

Luis Rodriguez

¿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?

Impulsamos el crecimiento profesional de tu equipo de developers