En LeanMind, nos encanta mejorar el código de los proyectos en los que trabajamos y también compartir esos descubrimientos con los demás.

Es importante escribir código sostenible, porque de esa forma, es más barato añadir funcionalidad o quitarla, aparte de que lo agradecerán los compañeros y mi yo del futuro. En esta ocasión me gustaría hablar de la cantidad de parámetros en un método. La firma de un método es una de las primeras cosas que un desarrollador observa para comprender qué hace. Si un método recibe demasiados parámetros, se vuelve más difícil de entender, mantener y probar, porque es complicado recordar el orden de los parámetros, si agregamos otro parámetro, todas las llamadas quedan afectadas y el código pierde expresividad. Como se puede ver en el siguiente ejemplo:

class ReportService {
    generateReport(title: string, author: string, startDate: Date, endDate: Date, includeSummary: boolean, format: 'pdf' | 'excel' | 'csv' | 'json'): void {
		// lógica para generar informes
    }
}

Como bien dice Robert C. Martin en su libro Código Limpio, los mejores métodos son los que no tienen parámetros, agrega que un método con más de tres parámetros resulta sospechoso.[01] También tenemos que tener en cuenta que cuantos más parámetros tenga un método, seguramente esté rompiendo el principio de responsabilidad única[02]

Una de las estrategias que podemos usar, es definir colaboradores que podamos inyectar por constructor. Un caso que vemos con bastante frecuencia son las fechas. Muchas veces lo que se puede hacer es definir un DateTimeService e inyectarlo en el constructor, como se muestra en el siguiente ejemplo:

public class UserService
{
	private readonly DateTimeService dateTimeService;
	private readonly UserRepository userRepository;
	
	public UserService(DateTimeService dateTimeService, UserRepository userRepository)
	{
		this.dateTimeService = dateTimeService;
		this.userRepository = userRepository;
	}
	
	public void CreateUser(string email, string password)
	{
		var user = new User(
			email: email,
			password: password,
			dateTimeCreation: dateTimeService.UtcNow());
		userRepository.Save(user);
	}
}

Otra estrategia que podemos usar es aplicar Parameter Object como muy bien lo explica Martin Fowler en su mítico libro Refactoring[03], es decir, si no tenemos más remedio que pasar muchos parámetros al método, los podemos agrupar en una clase, como se muestra en el siguiente ejemplo: Métodos con mucho parámetros

function sendEmail(to: string, subject: string, body: string, isHtml: boolean) {
  // lógica para enviar el email
}

sendEmail("user@example.com", "Bienvenido", "<h1>Hola</h1>", true);

Después de aplicar el refactor Parameter Object

type EmailMessage = {
  to: string;
  subject: string;
  body: string;
  isHtml: boolean;
};

function sendEmail(message: EmailMessage) {
  // lógica para enviar el email
}

Podemos ver en el siguiente ejemplo que la llamada al método se simplifica mucho y queda mucho más clara

sendEmail({
  to: "user@example.com",
  subject: "Bienvenido",
  body: "<h1>Hola</h1>",
  isHtml: true
});

Conclusión

Reducir el número de parámetros en un método no es solo una cuestión estética, sino de claridad, mantenibilidad y calidad del software. Un método con menos parámetros es más fácil de entender, menos propenso a errores y más flexible frente a cambios futuros.

---

Referencias: [01] Clean Code por Robert C. Martin, página 40 [02] Agile Principles, Patterns, and Practices in C# por Robert C. Martin, página 155 [03] Refactoring, improving existing code por Martin Fowler, página 238