Single responsibility principle (parte 2)

Esta es la segunda parte de mi post sobre SRP, en la primer parte comentamos que es y una de las formas en que nos afecta, esta vez hablaremos de otra forma en que nos afecta y veremos algo de código, así que agaaaarrrrrrense...

Primero una de las cosas que hay que tomar en cuenta es que el software y en particular las clases en POO son una representación del negocio, por lo que es una forma muy habitual de "encapsular" ese negocio el crear una clase por ejemplo EmployeeBusiness en donde se mete todo lo que tiene que ver con el empleado, a simple vista esto es correcto ya que coo decimos, representa el negocio, pero el problema es que lo estamos viendo desde el punto de vista de la entidad y ahí es donde esta jodido este asunto, que va a pasar con esta clase?

1. Va a crecer enormemente dado todas las operaciones que se pueden hacer con el empleado.
2. Va a tener un montón de dependencias por lo que se corre el riesgo de un alto acoplamiento.
3. Va  tener muchos motivos por los cuales puede cambiar, y acá es donde se rompe este principio.

Pero entonces como CREO YO que se deben de hacer las cosas? bien, pues afectivamente separar bien las cosas de acuerdo al negocio, por ejemplo una clase para manejar las vacaciones del empleado, otra para el cálculo de su nómina, otra para cuando se da de baja y así, como se dan cuenta la separación es efectivamente por negocio y nos damos cuenta ya que cada una de estas clases tiene un "stakeholder" específico y no necesariamente el mismo, por ejemplo la gente de RH es el "encargado" de las modificaciones a las reglas de vacaciones, la gente de nómina es el "encargado" de las modificaciones a las reglas de cálculo de nómina y así sucesivamente. Así tendremos las siguientes características en cada clase:

1. Se hacen pequeñas ya que cada una sirve a un propósito my específico.
2. Las dependencias disminuyen al sólo tener las necesarias para realizar su trabajo.
3. Sólo tiene un motivo por el cual va a cambiar y no sólo un motivo, sino un solo rol que dicta que cambia cómo y porqué.
4. Es mucho más fácil de probar.
5. Cumple con una alta cohesión.

Un ejemplo de este principio lo pueden ver en mi post de patrón decorador para validar en el que las responsabilidades están muy bien definidas y son totalmente independientes cada una de las clases.

Ya se que les prometí código en este post, pero creo que la explicación es lo suficientemente buena como para convencerse de que vale la pena que nuestras clases cumplan con este principio y les dejo la liga mi post donde pueden ver la aplicación de una forma muy clara y sencilla.

Single responsibility principle (parte 1)

Este es el primer post para comentar a cerca de los principios SOLID, en esta ocasión nos enfocaremos en el principio de Single responsibility o Responsabilidad única (la S en SOLID), como ya comentamos en un post anterior los principios de son ciertas características (de diseño) que el desarrollo de software orientado a objetos debe de cumplir para que se diga que está bien estructurado y que ayuda a que el codigo sea entendible y por ende matenible, así que eso es lo que abordaremos en este post enfocandonos al principio de responsabilidad única.

Bien se dice por alli que el que mucho abarca poco aprieta, pues bien, esto llevado a la programación orientada a objetos es éste principio, en el que se describe que una clase debe de tener una única responsabilidad y no más que esa, como nos damos cuenta de que nuestra clase cumple con ella? pues esto es coo muchos dice, cumple con ella si es que tiene una única razon por la que tiene que cambiar, si es así entonces se dice que tiene una sola razón de ser y si esa razón de ser cambia por alguna razón entonces la clase debe de cambiar, pero sólo por eso deber de hacerlo.

Ahora este principio no solo se refleja en clases, sino en métodos, variables, paquetes, componentes y hasta sistemas, como es esto? pues bien, una variable debe de existir para solo una cosa, esto nos lleva a un buen nombramiento de la variable y esto es parte de clean code, esto es si se tiene una variable por ejemplo nombrada x que es de tipo Integer, en si el nombre no nos dice nada, por lo que estaremos tentados a usarla para lo que se nos antoje dentro de nuestro sistema, pudiendo usarla para almacenar la edad de un empleado, como índice para iterar el arreglo de percepciones del empleado (lo bueno es que ese arreglo no es muy grande jeje), etc. esto nos lleva a problemas muy graves de mantenimiento del código, lo que provoca que existan bugs, lo que provoca que nuestros clientes se quejen de lo que hacemos, lo que provoca que la empresa pierda dinero (o reputación), lo que provoca que se pierda la confianza en el desarrollador, lo que provoca que nos despidan, lo que provoca que nos atrasemos en el pago de nuestro lujoso carro (que sacamos a crédito augurando una buena carrera) lo que provoca... bueno, creo que ya di a entender el punto y todo esto por nombrar mal una variable, pero que pasa si a esa variable le nombramos employeeAge, pues ya sabemos que esa variable representa a la edad del empleado y estaremos menos tentados a usarla para almacenar algo distinto a la edad del empleado.

Si se dan cuenta, esta variable tiene una única responsabilidad que es almacenar la edad del empleado, ahora, esto aplica igual para métodos, éstos tambien deben de tener una única responsabilidad, por ejemplo el método que calcula los dias de vacaciones que tiene un empleado, esa es su responsabilidad, no la de ir a la base de datos por las reglas de vacaciones configuradas por el departamento de RH, ni ir a la base de datos para obtener la fecha de ingreso del empleado, este método sólo debe de hacer el cálculo y ya, no más que eso, en cuanto a una clase, pues como ya lo han de intuir, aplica igual ya que ésta solo se debe de encargar de algo en específico y delegar lo más que se pueda a otras clases que podrá usar o desde las que podrá ser usada para lograr un objetivo más general, en paqutes pasa lo mismo por ejemplo un paquete que tega las clases necesarias para la sección de nómina de los empleados que incluye clases para el cálculo, para extracción de datos, excepciones probables y demñas cosas que tienen que ver con la nómina, mas arriba, al sistema completo, que tiene que tener una resposabilidad única que es manejada por la gente de negocio de nuestra organización.

Últimamente se ha escuchado mucho sobre los microservicios, ellos son un ejemplo de responsabilidad única a nivel de deployable y de sistema pues de lo que se tratan es de que cada parte sea los mas independiente posible y tiene una responsabilidad muy específica llegando incluso a ser instalada de forma independiente a las demás características del sistema completo, teniendo su propia base de datos, su propio ambiente, tal vez hasta estar hecho en un lenguaje distinto a los demás y estar instalado en un servidor virtual en la india.

Pues bien, hasta acá le dejamos en la primer parte del Single responsibility principle, espero que se haya entendido de que se trata y que se puede extender mas allá a sólo clases.

En el siguiente post hablaremos de forma mas puntual de este principio con código de ejemplo y toda la cosa.

Principios en el desarrollo de software

Los principios en desarrollo de software son ciertas características de diseño de objetos que permiten que el código sea mas expresivo y por ende mas mantenible, hay varios principios, los más conocidos son los principios SOLID, DRY y KISS, en una serie de blogs entraremos mas en detalle en cada uno de ellos, por lo pronto y de forma muy general doy una breve descripción.

SOLID acrónimo de Single Responsability (responsabilidad única), Open-Close (abierto a extensión y cerrado a modificación),  Liskov Substitution (substitución de Liskov), Interface Segregation (segregación de interfaces) y Dependency inversion (inversión de dependencias) estos son principios que aplican de forma directa en el diseño de clases para programación orientada a objetos, como comenté, mas adelante en algún post revisaremos cada uno de estos principios.

DRY acrónimo de Don't Repeat Yourself (No te repitas a ti mismo), este principio es uno de los más publicitados en el medio y su aplicación va desde una clase hasta un sistema completo, pasando por versionamiento de la base de datos y documentación.

KISS acrónimo de Keep It Simple Stupid (mantenlo simple, estúpido) es un principio también muy conocido pero que es muy difícil de aplicar ya que por naturaleza (no le encuentro otra razón) los desarrolladores somos muy perfeccionistas, pero este principio nos dice que hay que mantener las cosas lo más simple posibles y esto es desde el código, hasta el propio producto igual, pasando por la documentación y el proceso de desarrollo de software.

Estos principios son muy usados y mencionados del desarrollo usando metodologías ágiles (de las que escribiremos en algún post posterior) y es que es muy normal que en este tipo de metodologías dada su naturaleza propicien que los desarrolladores se apeguen a este tipo de principios casi de a fuerzas pero de una forma un poco sutil.

Además de estos principios se podrían mencionar también otras características del software que un buen desarrollo debe de cumplir como el hecho de que todo código productivo debe de estar respaldado por un test o prueba unitaria automatizada y ya hablando de los tests también mencionar que estos tests no deben de ser "low class citizens", es decir, estos tests son igual (o tal vez hasta mas) de importantes que el código productivo, otra característica de un buen código es que debe de ser un código limpio siguiendo ciertos lineamientos encaminados mas que nada a que sea entendible y por lo tanto mantenible.

Bueno, pues esperen próximamente posts relacionados a todo esta madre sin sentido que les acabo de decir.

Saludos.