domingo, diciembre 10, 2017

Principios SOLID, una conversación


Los principios SOLID datan de principios de siglo —del nuevo, no del viejo—, y establecen unas pautas generales para diseñar software más legible, mantenible y escalable. Hasta aquí, todo bien. SOLID son las 5 siglas, de cinco principios.
“S”, de  Single Resposibility principle, o lo que vendría a ser; que cada clase debe tener una sola responsabilidad. Si es de negocio, ¡es de negocio! no debe incluir lógica de comunicaciones. Nada de andar metiendo IFs en los controladores.
La “O”, de Open/Closed principle, es decir que los objetos o las entidades, deben ser abiertas para las extensiones, pero cerradas para las modificaciones.
—¡Me perdí, a otra cosa! ¿Abiertas? ¿Cerradas?
—Que hagas las clases lo suficientemente generales para que no tengan que modificarse. Y que permitas que otras clases extiendan de ella.
Por ejemplo, si tu jefe te pide que le cambies el comportamiento de algo, no modifiques la clase existente, construye otra. Y a ésta otra, la haces heredar de la primera y pones todo el código nuevo ahí.
Crecer por agregación, no por remplazo.
—Pero, ¿y si la primera clase ya no me sirve? ¿Se ha quedado obsoleta?
—Ahí entra el refactoring. Mueve el código a una clase padre. Y todo lo que no sea código abstracto, lo pones en la nueva clase.
“L” de Liskov Substitution Principle, ««Olé, por Barbara Liskov»». Este principio de sustitución sostiene que las variables de referencia —las que están a la izquierda del signo igual— deben ser o una interfaz, o una clase abstracta. Es decir, no concretas. Que no sean del mismo tipo de las que haces los new. Sí pones la misma clase de un lado y del otro del signo igual… ¡Hay tabla! (Salvo excepciones).
La “I”, viene de Interface Segregation Principle, o lo que en la lengua de Cervantes sería; romper las interfaces grandes en pequeños pedacitos. Nada de métodos @Override vacíos con TODOs que manchan la pantalla. Si tienes una interfaz general que contiene todo el comportamiento, la “Segregues” en varias interfaces pequeñitas. Así solo declarar la tarea que vas a realizar, y en un futuro cercano, reemplazar solo ese comportamiento y no todo.
Por último, la “D” proviene de Dependency inversión principle. Este principio me parece similar o tiene algo que ver con el principio “L”. Ya que hace referencia a que la interacción entre todos los módulos (controladores, servicios, repositorios de objetos, utils) deben ser del tipo interfaz o clases abstractas. Nada de clases concretas. Pero además introduce otro concepto; el que tiene que haber una clase en el medio, que cumpla con algún patrón de creación —Factory method, Abstract Factory, prototype, etc—, que sea el responsable de realizar los “new” (Instanciar los objetos)
—¡Más clases! ¡El código se vuelve imposible de seguir! ¡Cómo lo debbugeo!
—Ya, sí... en un principio se vuelve más difícil… Pero te tengo una sorpresa…
—¿Cuál?
—A todo esto último… lo realiza Spring, cuando escribes la anotación @Autowired. Tú solo preocúpate por declarar bien tus variables.
—¡Tantas clases no se justifican, la mayoría de las veces!
—Es por eso que no debes apagar el cerebro. Piensa cuáles funcionalidades pueden cambiar en el futuro y cuáles no.
—¡Las del core del negocio!
—¡Exacto! Recuerda; clases con una sola responsabilidad, interfaces pequeñas… sobre las variables; que sean interfaces o abstractas. Crece por agregación, y sobre lo último… bueno, déjaselo a Spring o analízalo con más detalle.


No hay comentarios.: