Number of attributes in a class

Number of attibutes in a class

Anything more than 10 attributes is starting to smell.

“No shit is accepted.”

Courtesy of Javier Peris Morillo.

Anuncios

Software con bajo acoplamiento y máxima cohesión

¿Hay algo más bello que un programa hecho con bajo acomplamiento y máxima cohesión?

Aparte de estar bien diseñado, cumpliendo tan solo estos 2 requisitios, la calidad del software aumenta MUCHÍSIMO, por lo tanto mi consejo es que, por favor, ¡una clase/método nunca debería saber más de lo necesario!

Algo tan sencillo habitualmente es pasado por el forro de los cojones.

Principios SOLID

S – Single Responsibility Principle.

Una clase debería tener una única responsabilidad, bien definida. De esta manera solamente debería haber un motivo por cambiar su implementación.

Por ejemplo, una clase Persona nunca debería ser responsable de guardarse en un archivo a sí misma. Por lo tanto, un método Persona.Save(Stream output) viola este principio. En este caso, la clase Persona no solamente tendría como responsabilidad albergar los datos relacionados con la entidad correspondiente, sino también saber cómo guardarla. Tendría, por tanto, al menos 2 motivos para cambiar:

  • si la entidad Persona cambia
  • si los detalles del guardado (por ejemplo, el formato) cambian.

O – Open / Closed Principle

El comportamiento de una clase debería poderse modificar sin tener que cambiar su implementación.

Esto significa que la clase debe ser extensible, pero a la vez, robusta: no queremos tener que andar toqueteando todos sus métodos cada vez que una especificación cambie.

L – Liskov Substitution Principle

Una clase base debe ser SUSTITUIBLE por cualquiera de sus clases derivadas sin producir ningún efecto indeseado.

I – Interface Segregation Principle

Las interfaces deben ser reducidas. Deben permitir una granularidad alta.  Las interfaces grandes y difíciles de implementar SON CONTRAPRODUCENTES.

Es preferible tener varias interfaces pequeñas que una grande. Implementarlas será mucho más fácil y el diseño tendrá más sentido. Aparte de eso, al usar interfaces pequeñas nos forzamos a definir claramente los requisitos y las dependencias de cada método.

D – Dependency Inversion Principle

Trata de depender de abstracciones, no de implementaciones.

Cuando dependemos de abstracciones, tenemos claro qué es lo que necesitamos, aunque no definimos una forma específica de hacerlo. Una interfaz, ReproductorMusica puede tener el método Play. Sabemos qué es lo que hace, pero no cómo lo hace. Esto nos brinda una gran flexibilidad y dota al código de más capacidad semántica.