Webinar TDD y Clean Code: la calidad de código importa

Kent Beck dice “No sé si soy un gran programador, pero definitivamente son un programador con grandes prácticas”. ¿Cuáles son estas grandes prácticas? Test Drive Development y Clean Code son dos de ellas. La adopción de estas prácticas nos ayuda como programadores para que perdamos el miedo a usar código nuevo y confiemos en nuestros compañeros de equipo. También ayuda a reducir la tan odiada documentación o peor, tener documentación incorrecta (como comentarios obsoletos) .

Fernando y Jorge, contribuidores de esta página, dieron este webinar en Software Gurú Campus.

Las diapositivas en Slide Share

Clean Code, primer asalto...

Señores, cuando escuché por primera vez Clean Code como buen programador rápidamente lo relacioné con algún tipo de framework o tecnología y bueno, pues resulta que no. Es más bien una forma de programar como Dios manda y evitar pecar al codear como suele decirse: 'con las patas'.

Casi es seguro que más de alguna vez como programadores hemos regresado a un código propio, le damos una revisada y hasta pena nos da al verlo ya que por la presión del tiempo o por malas costumbres nuestro código resulta un verdadero "espagueti". Y vaya que esto no sólo trata de elegancia. Trata de alta mantenibilidad con todo lo que este factor implica en el desarrollo de sistemas (Invertir tiempo, esfuerzo, retrabajo, dinero. ¿Te suena? amigo inversionista en software). Además como dice el buen Uncle Bob "La única manera de ir rápido, es ir bien" así que tiempo al tiempo y calidad a nuestro código. Seamos profesionales! Y a la vez artistas, hagamos de nuestro código poesía.

Tengo poco de haberme metido con Clean Code y por eso les dejo un tipo de mapa mental (o al menos esa era la intención). Incluye sólo  ideas introductorias ya que hay mucho más, así que os invito a darle rienda suelta a su curiosidad y meterse al mundo de Clean Code, aplicarlo a sus proyectos del día a día y que mejor aplicarlo si están emprendiendo dentro del mundo del software. Hagamos software con calidad!

Not a number es un not a number?

Que tal codeamesteros esta vez andaba revisando unas reglas de análisis estático de código y me encontré con una regla media extraña con el NaN, así que la pregunta es que imprime el siguiente programa?:

    public static void main(String[] args) {
        double notANumber = Double.NaN;
        System.out.println(notANumber == Double.NaN);
    }

la idea es que me dejen en sus comentarios que es lo que CREEN que imprime antes de ejecutarlo, después lo ejecuten y vean el resultado real, investiguen y que comenten por que sucede.

Por esta vez es todo, espero sus comentarios.

CleanCodeando la Planeación

Yo tengo el superpoder de reconocer a gente chingona a primera vista. Algo así como un Chingoneómetro integrado que hace que mis ojitos parpadeen rápido y comience a babear. No es una escena bonita, pero bueno, así me pasa. La cuestión es que, cuando vi un video del Uncle Bob en YouTube hablando de funciones, descompuse el teclado de la compu por tanta baba. Así que tuve que molestar gente (mi segundo superpoder) para obtener todo lo de CleanCoders.com y por eso este grupo de codeamestadores hablan de SOLID y demás. Si no los han visto, ya se están tardando. En esos videos por fin entendí qué era eso de TDD y cómo se usa. 

Podría pensarse que el concepto es sencillo: probar antes de programar... pero la realidad es que va más allá. Estas son las reglas en español del Tío Bob:

Antes que nada quiero aclarar para aquellos que no me conocen que yo ya no hago código productivo. Entonces, ¿cómo me atrevo a hablar de Clean Code y TDD? HEREJE DEL MAL. Mi pretexto es que me alejé del camino del bien porque me chocaba hacer front ends o debuggear para testear. Así que mejor me hice tester, ya que pensaba que eso sería la salvación de la calidad de software. No me juzgen; era más joven y menos sabia. Después herré aún más mi camino qualitoso al hacerme de procesos... pero ya no quiero acordarme. La cosa es que hoy sé que la calidad está en el código y que un código limpio y hecho con TDD me hace llorar.

Mi primera vez con TDD y Clean Code

Que no haga código productivo no quiere decir que no le entre a las Katas de Codeamesta (que próximamente subiremos) y entendí que sólo viviéndolas se pueden entender estas 3 leyes. Con la Kata de StringCalculator y Bowling, entendí la maravilla de comenzar con los escenarios más sencillos y aguantarse de hacer más código productivo del necesario; con la de Pokar, a limpiar y refactorear para que las reglas de negocio las lea cualquier ser humano.

Algo sucede al hacer estas katas y ver esos videos que los conceptos le alteran uno el ADN y uno comienza a CleanCodear aunque no haya código. Algo así nos pasó al estimar y planear un nuevo desarrollo.

Estimando y Planeando a la Clean Coder

Alberto y yo tuvimos que estimar un desarrollo. En realidad Alberto ya lo había estimado con Armando, pero básicamente la regaron: no usaron casos de uso y la arquitectura son los casos de uso. Entonces cuando quisimos planear en base a un diseño y dar entregables funcionales nos dimos cuenta de que no podíamos desacoplar la planeación de nuestro diseño. No era funcionalmente incremental. 

Así que como dije, volvimos a estimar. Esta vez hice casos de uso y los validé con gente de negocio e incluso algunos escenarios de pruebas de funcionalidades base. Ya habiendo entendido qué se espera de nuestra aplicación, hicimos un diseño con la funcionalidad más básica que se nos ocurrió. Nada de configuraciones ni reportes ni logs ni esas cosas que el usuario pide. Partimos el diseño en tareas y estimamos. Poco a poco fuimos “complicando” la funcionalidad. 

Mientras diseñábamos nos preguntábamos ¿cuál es el siguiente caso de uso más sencillo? ¿Quién debe hacer eso? Nos dimos cuenta que estábamos aplicando una variante de “As the tests get more especific, the code gets more generic” y “Single Responsability”.

Conforme avanzábamos en la planeación, dibujábamos en el pintarrón el pedacito de diseño que hacía la funcionalidad más específica y escribíamos tareas para una funcionalidad más genérica… El resultado, los últimos sprints fueron más rápido de diseñar y planear.

Y ahora, a codificar

El desarrollo comenzó con la estimación aún calientita y muchos unknowns. Incluso, hoy revisamos con arquitectura nuestro hermoso diseño y uno de los Arquitectos dijo, quitándose los lentes y removiendo una lagrimita, “si hubieramos hecho esto hace un año”. En fin. Ahora los programadores tienen que volver a estimar, tomar decisiones sobre la implementación y la organización de su grupo y si todo resulta como dice la teoría, Clean Code nos hará más rápidos… ya se enterarán.

Uncle Bob dice que TDD no es religión, yo la verdad tengo mi cartita de Uncle Bob en la cartera.

El diseño interno visto desde fuera

Que tal gente, este es mi primer post y antes de empezar les quiero dar las gracias al equipo de codeamesta ya que ustedes son las espermas que a partir de su perseverancia, inteligencia innata y esfuerzo empiezan a engendrar un buen desarrollo, incrustándose en en el IDE y el compilador para dar como resultado un hermoso código, código que al principio todos miran y dicen que bonito es, pero que conforme pasa el tiempo terceros dicen no manches como es que llegó a estar esto como está, pero lo bueno es que es tarea de nosotros mismos el hacer que este código crezca con la posibilidad de una vida mejor a la de sus antecesores y que al final del camino sea un código de bien y que ayude a la sociedad a lograr su cometido.... ha cabrón como que ya me fui por otro lado, bueno el chiste es que gracias a ustedes por hacerme crecer y creer.

Ahora si empezamos.....

En la semana pasada estábamos en la junta diaria y un desarrollador comentó que ya casi terminaba su tarea que solo le faltaba llenar un POJO necesario para crear estadísticas y que era responsabilidad de otro crear, en ese momento sentí algo raro en la panza, ¿por qué esperar si tu tarea es hacer ciertas transformaciones sobre datos, no llenar un POJO para estadísticas? y recordé los principios enseñados por en tío Bob, y empecé a divagar y pensar sobre eso y llegue a la conclusión que lo que el desarrollador pensaba es meter en su clase una instancia del POJO para poder así llenarla para luego crear su respectivo método getter para que quien la usara pudiera obtener el POJO creado y hacer uso de él, en ese momento algo no me gustó y pensé en proponer algo para dejar un poco mas mejor esa clase y les dije cuidado al hacer eso, por que es como llamar al chamuco para que te haga un favor, al principio te puede hacer respirar y hacer que la situación en la que está "mejore" de pronto, pero te vas a quedar con un pedo más en la cabeza y no vas a estar a gusto con la decisión que tomaste y a largo plazo puede ser que te cause mas problemas de los que te "resolvió", así que lo que vimos es que esa clase tendrá más de una razón por la que podría cambiar, si el POJO cambia hay que cambiar la clase y si la forma de hacer la transformación cambia entonces hay que cambiar la clase lo cual vimos que no es lo mejor de acuerdo al principio de responsabilidad única, así que llegamos a una mejor solución en la que la clase que hace la transformación sólo hace eso, la transformación, pero puede entregar también una descripción de lo que hizo y quien es, de forma que la clase externa sea quien genere el POJO y así hacer que esta clase de transformación tenga una responsabilidad única.

Bueno lo chistoso acá es que me pongo a pensar en cuánto código así de feo generé yo en su momento y que seguramente aún sigo generando y me doy cuenta que no se por que pero cuando el desarrollador tira código no piensa claramente, o se nubla, tal vez por que está en "la zona", pero cuando el mismo desarrollador ve un código o escucha de otro su posible solución dice ....mmmmm.... como que algo está jodido ahí y entramos en el asunto de que no es lo mismo ver algo desde afuera que estar en la situación, es como cuando te vas de parranda y ves a una chava que te late, pero no sabes por que te friqueas y no haces nada y no sabes por que, pero cuando esa mista situación le pasa a tu amigo le dices no mames yo ya hubiera hecho x, y o z, esto para mi es exactamente lo mismo y es en donde creo en que es bueno que alguien desde fuera del desarrollador vea el código y de su punto de vista, para esto es para lo que yo creo que deben de servir mas las inspecciones de código.

Bueno, espero que les haya sido entretenida la lectura y que pensemos ¿qué podemos hacer para pensar claramente al tirar código? ¿como puedo ayudar a los demás a encontrar una mejor solución?, así que a ser críticos de nuestro código y del de nuestros compañeros que aunque al principio pueda ser molesto al final te genera mas experiencia y armas para solucionar futuras situaciones en el bar, antro o donde sea que estés.

Bueno, tal vez se pregunten donde quedo yo en el asunto de la esperma y todo ese choro,pues yo soy el tío del código, lo aclaro por que ya que leí el post como que parecía que estaba evitando decir algo sobre mi y nunca dejaba claro mi lugar en esa historia, así que ahí está antes de que me albureen.


NOTA: Este post está basado en un suceso real y ha sido exagerado para tratar de hacerlo mas entretenido jeje.

EL PRINCIPIO DE LISKOV SUSTITUTION

El propósito de una abstracción es separar comportamiento e implementación. Es decir separar la abstracción de cómo esta es implementada, así implementaciones de la misma abstracción pueden ser sustituidas libremente.

El principio de Liskov Sustitution se vuelve muy importante en el diseño de un programa ya que de este depende mucho la mantenibilidad y la correcta funcionalidad de un sistema cuando nuevas implementaciones son creadas.

El principio dice lo siguiente:

Si tenemos una objeto o1 de la clase A y un objeto o2 de la clase B entonces en un programa escrito en función de B podemos sustituir el objeto o1 por o2 si alterar la funcionalidad del sistema si A es un subtipo de B.

public class LiskovSustitution {
    public static void main(String[] args) {
        OtroItem o1 = new OtroItem();
        Item o2 = new Item();
        hacerAlgo(o1); Aquí podemos reemplazar o1 por o2 sin afectar la funcionalidad.
    }

    static void hacerAlgo(Item b){
        b.update();
    }
}

class OtroItem extends Item{
    public void hacerOtraCosa(){
        System.out.println("Hacer otra cosa");
    }
}

class Item{
    public void update(){
        System.out.println("Item updated");
    }
}

El problema viene con un mal manejo de la herencia. Imaginen el caso donde se tiene una clase Set que hereda de List (podríamos decir que un Set es un List dada la herencia). Como ya sabemos la clase Set guarda solo una instancia del mismo objeto aunque este le sea pasado dos veces, es decir si hacemos Set.add(objeto) y de nuevo Set.add(objeto) solo una instancia es almacenada a diferencia de List que guardaría las dos instancias. Ahora bien imaginen el caso donde un método requiere de un List para trabajar pero dada la herencia es posible pasar un objeto de la clase Set, es muy probable que con esto cambiemos la funcionalidad de ese método si darnos cuenta hasta el punto en que el sistema quede inestable.

Con este ejemplo vemos como un subtipo cambia la funcionalidad de su tipo padre. Ademas de violar el principio de liskov sustitution también esta faltando al principio open close modification.

Tomando nuestro ejemplo anterior:

public class LiskovSustitution {
    public static void main(String[] args) {
        OtroItem o1 = new OtroItem();
        Item o2 = new Item();
        hacerAlgo(o1); Aquí podemos reemplazar o1 por o2.
    }

    static void hacerAlgo(Item b){
        b.update();
    }
}

class NoUpdatableItem extends Item{
    public void update (){
        throw UnsoportedOperation();
    }
}

class Item{
    public void update(){
        System.out.println("Item updated");
    }
}

Si un subtipo no tiene todas las operación que su tipo padre, entonces este no se debe considerar como un subtipo, es decir si NoUpdatableItem no soporta la operación update entonces no se puede decir que sea un Item. Esto es un indicativo que algo anda mal en nuestro diseño. Por otro lado si cada que creamos un nuevo subtipo la clase que hace uso del polimorfismo debe ser cambiada esto también es un indicativo que algo va mal en el diseño. Por ejemplo:

public class LiskovSustitution {
    public static void main(String[] args) {
        OtroItem o1 = new OtroItem();
        Item o2 = new Item();
        hacerAlgo(o1); Aquí podemos reemplazar o1 por o2.
    }

    static void hacerAlgo(Item b){
        if( ! b instanceof NoUpdatableItem)
b.update();
    }
}

class NoUpdatableItem extends Item{
    public void update (){
        throw UnsoportedOperation();
    }
}

class Item{
    public void update(){
        System.out.println("Item updated");
    }
}

Esta variante en el método static void hacerAlgo(Item b) tiene que hacer uso de instanceof para saber si una operación es permitida. Es decir, si el método que es cliente de nuestra clase tiene que saber el tipo de dato que se le pasa para saber que operaciones puede realizar es sin duda un mal diseño y una violación al princiopio que aquí estamos analizando.

Lo correcto para nuestro ejemplo seria separar los Items en dos tipos diferentes, UpdatableItems y NoUpdatableItems.

class Item{
    String nombre;
    public Item(final String nombre){
        this.nombre=nombre;
    }
}

class UpdatableItem extends Item{

    public UpdatableItem(String nombre) {
        super(nombre);
    }

    public void update(){
        System.out.println("Update item");
    }
}

class NoUpdatableItem extends Item{

    public NoUpdatableItem(String nombre) {
        super(nombre);
    }
}

Y llegaramos a crear subtipos de UpdatableItems estos subtipos deben mantener la misma funcionalidad que su clase padre para poder ser considerados subtipos de UpdatableItems.


Importante: este post es autoría de Carlos, quien no lo subió por causas de fuerza mayor provocadas por su voluntad.

El Principio de Responsabilidad Única (The Single Responsibility Principle)

El Principio de Responsabilidad Única (The Single Responsibility Principle)

Bueno Team, el día de hoy revisaremos uno de los principios de SOLID, el cual es el principio de responsabilidad única, bueno para comenzar este termino o mas bien principio fue introducido en los 90 por Robert C. Martin o más conocido por el Tio Bob y lo define de la siguiente manera “El Principio de responsabilidad única establece que cada modulo de software debe tener una y sólo una razón para cambiar”, esto de entrada suena bien y con mucha lógica, pero primero hay que establecer que el Tio Bob cuando dice modulo de software incluye una amplia gama de opciones donde aplicar dicho principio ya que esto aplica para diseño, clases, funciones, variables, etc...

Con esto en mente por el momento podemos pasar a lo siguiente a que se refiere con una y sólo una razón para cambiar, esta idea lo que quiere decirnos es que cada modulo de software debe tener una responsabilidad bien definida y encapsulada, este concepto esta muy relacionado a un principio de diseño de separación de responsabilidades que habla de modularidad y encapsulación, la realidad es que esta idea le vemos día a día he incluso la implementamos, en nuestro trabajo las responsabilidades están bien definidas, las responsabilidades del su jefe y ustedes como parte de su equipo de trabajo, de entrada esta idea suena bien ya que si la aplicamos para muchas cosas en nuestra vida puede aplicar para diseñar software, una ves aceptada la idea de repartir responsabilidades bien definidas llega la pregunta, ¿que define una razón para cambiar?, algunos pensaran puede ser la resolución de bug encontrado en alguno de nuestros módulos o aplicar un refact a nuestro modulo, aquí lo que nos comenta el Tio Bob que estos dos temas, tanto resolución de bugs y refact no cuentan como razones para cambiar un modulo, ya que la aplicación de estos dos son mas responsabilidad del desarrollador mismo.

Dado que soy un fan del Fútbol pondré unos ejemplos esperando que esto ayude un poco a comprender este principio, primero la idea separación de responsabilidades, por un lado tenemos al dueño del equipo que tiene a grandes rasgos la parte administrativa de dicho equipo esa es su responsabilidad, por otro lado esta el director técnico del equipo y su responsabilidad es clara dirigir al equipo de fútbol y pues también están los jugadores y su responsabilidad de jugar al fútbol, veamos otra idea del este principio que es que un modulo sea capaz de realizar otras responsabilidades no quiere decir que deba hacerlo, esto lo podemos ver en el equipo de fútbol, que aun que el director técnico sea un ex-jugador de fútbol no quiere decir que deba entrar a jugar durante un partido aun que pueda y sepa hacerlo su responsabilidad esta clara dirigir al equipo de fútbol, de igual forma aun que el dueño sepa de fútbol no quiere decir que deba dirigir al equipo para eso esta el director técnico, y así podríamos seguir definiendo cada responsabilidad de cada modulo en el equipo de fútbol sin importar en que nivel se encuentra ya sea diseño, clases, funciones, variables, etc... como definimos previamente.

 Bueno ahora la pregunta ¿que define una razón para cambiar? Bueno esto va enfocado a la responsabilidad que tiene un modulo para atender las necesidades de un actor( persona, grupos de personas, módulos, etc...) , veamos lo desde el ejemplo del equipo el dueño del equipo tiene la necesidad de tener un equipo ofensivo por lo cual requiere un director técnico que cumpla con estas características, la única razón de cambio para el modulo de director técnico seria que el dueño ya no quisiera un director técnico ofensivo si no mas bien defensivo, esta cambiando la necesidad del dueño, dado que si cambia un director técnico ofensivo por otros de las misma características lo veríamos mas como corrección de un bug o refactor dado que el director técnico no estaba funcionando como lo esperado, lo mismo lo podemos ver a nivel del director técnico y los jugadores cuando cambia la estrategia o parado del equipo se puede tomar como una razón de cambio, pero cuando cambia a un jugador sin alterar la estrategia se podría ver como una resolución de un bug o un refact. Espero que este ejemplo le haya servido para entender la idea de el principio de responsabilidad única, pero dejemos un poco la teoría y veamos un ejemplo mas practico y enfocado al software que es lo que nos gusta e interesa.


Con mi equipo de trabajo hemos estado realizando Katas que la idea básica es ponernos ejercicios diarios que nos ayuden a mejorar y perfeccionar nuestras habilidades al momento de programar, muy parecido a una kata dentro de las artes marciales, bueno una de estas Katas era sobre un programa que se encargaba de actualizar el inventario de quesos de una empresa llamada GildedRose la cual contaba con varios tipos de quesos y dependiendo el tipo se actualizaba de una forma u otra, las características que se actualizaban ere la calidad del queso y su fecha limite de venta, la idea de esta kata era partir de un sistema ya echo y que estaba englobado todo en una sola clase y la idea era utilizar los principios de SOLID y rehacer este sistema sin alterar el funcionamiento actual de dicho sistema y a continuación les mostrare como aplique el principio de responsabilidad única, donde lo separe en 3 actores el sistema, los tipos de quesos y las reglas de negocio.


Código al Inicio de la Kata:

package gildedrose;

class GildedRose {

    Item[] items;

    public GildedRose(final Item[] items) {
        this.items = items;
    }

    public void updateQuality() {
        for (int i = 0; i < items.length; i++) {
            if (!items[i].name.equals("Aged Brie")
                    && !items[i].name.equals("Backstage passes to a TAFKAL80ETC concert")) {
                if (items[i].quality > 0) {
                    if (!items[i].name.equals("Sulfuras, Hand of Ragnaros")) {
                        items[i].quality = items[i].quality - 1;
                    }
                }
            } else {
                if (items[i].quality < 50) {
                    items[i].quality = items[i].quality + 1;

                    if (items[i].name.equals("Backstage passes to a TAFKAL80ETC concert")) {
                        if (items[i].sellIn < 11) {
                            if (items[i].quality < 50) {
                                items[i].quality = items[i].quality + 1;
                            }
                        }

                        if (items[i].sellIn < 6) {
                            if (items[i].quality < 50) {
                                items[i].quality = items[i].quality + 1;
                            }
                        }
                    }
                }
            }

            if (!items[i].name.equals("Sulfuras, Hand of Ragnaros")) {
                items[i].sellIn = items[i].sellIn - 1;
            }

            if (items[i].sellIn < 0) {
                if (!items[i].name.equals("Aged Brie")) {
                    if (!items[i].name.equals("Backstage passes to a TAFKAL80ETC concert")) {
                        if (items[i].quality > 0) {
                            if (!items[i].name.equals("Sulfuras, Hand of Ragnaros")) {
                                items[i].quality = items[i].quality - 1;
                            }
                        }
                    } else {
                        items[i].quality = items[i].quality - items[i].quality;
                    }
                } else {
                    if (items[i].quality < 50) {
                        items[i].quality = items[i].quality + 1;
                    }
                }
            }
        }
    }
}

Veamos el Sistema ya con los cambios:

package gildedrose;


public class GildedRoseSystem {
    
    private ItemUpgradeInstanceable factory;

    public GildedRoseSystem() {
        this(GildedRoseMainFactory.getItemUpgradableFactory());
    }

    public GildedRoseSystem(final ItemUpgradeInstanceable factory) {
        this.factory = factory;
    }

    public void updateItem(final Item item) {
        ItemUpgradeable upgratable = this.factory.getInstance(item);
        upgratable.updateQuality(item);
        upgratable.updateSellIn(item);
    }

}

El sistema tiene como responsabilidad es actualizar de cada tipo de queso(item) su calidad y su fecha limite de venta, sin siquiera saber el detalle de como se actualiza cada propiedad de los tipos de quesos, ni que reglas de negocio aplican para cada propiedad y tipo de queso, su responsabilidad es clara, modular y encapsulada.


Veamos ahora un ejemplo de los tipos de quesos(item):

package gildedrose;


public class NormalItemUpgradeable implements ItemUpgradeable {
    
    private GildedRoseBusiness business;

    public NormalItemUpgradeable() {
        business = new GildedRoseBusiness();
    }

    @Override
    public void updateQuality(final Item item) {
        this.business.degreteQualityInOne(item);
        if (item.sellIn <= 0) {
            business.degreteQualityInOne(item);
        }
    }

    @Override
    public void updateSellIn(final Item item) {
        this.business.degreteSellIn(item);
    }

}

Los quesos normales saben que su calidad se degrada en uno y que si su fecha de venta limite ya paso se degrada al doble, ha reglas de negocio que se aplican a dicho degradado pero es una responsabilidad que no es propia del tipo de queso. Veamos otro tipo de queso:

package gildedrose;

public class BackstageSpecialItemUpgradeable implements ItemUpgradeable {

    private GildedRoseBusiness business;

    public BackstageSpecialItemUpgradeable() {
        business = new GildedRoseBusiness();
    }

    @Override
    public void updateQuality(final Item item) {
        business.incrementQualityInOne(item);
        updateQualityInSpecialSellinTime(item);
    }
    
    @Override
    public void updateSellIn(final Item item) {
        business.degreteSellIn(item);
    }

    private void updateQualityInSpecialSellinTime(final Item item) {
        if (item.sellIn < 11)
            business.incrementQualityInOne(item);
        if (item.sellIn < 6)
            business.incrementQualityInOne(item);
        if (item.sellIn <= 0)
            item.quality = item.quality - item.quality;
    }

}

Este queso a diferencia del normal aumenta su calidad con forme se acerca a su fecha limite de venta en uno, dos o tres dependiendo el rango de proximidad a dicha fecha y una ves que llega a la fecha la calidad es cero, a cada incremento se le aplica una regla de negocio que no es responsabilidad como tal de el queso.

Veamos a continuación el negocio:

package gildedrose;


public class GildedRoseBusiness {
    
    public void degreteSellIn(Item item) {
        if (!item.name.equals("Sulfuras, Hand of Ragnaros")) {
            item.sellIn = item.sellIn - 1;
        }
    }

    public void incrementQualityInOne(Item item) {
        if (item.quality < 50) {
            item.quality = item.quality + 1;
        }
    }

    public void degreteQualityInOne(Item item) {
        if (item.quality > 0) {
            item.quality = item.quality - 1;
        }
    }

}

Ven esta clase se encuentran todas las definiciones del negocio en cuanto al decremento e incremento de la calidad sin importar como las aplique cada item y al decremento de la fecha limite.


Cual es la idea, bueno el sistema su responsabilidad es garantizar que de cada item se tiene que actualizar la calidad y la fecha, dirige la actualización, los tipos de item su responsabilidad es saber como se actualizan si incrementan o decrementan y cuantas veces ocurren estos incrementos y decrementos, y el negocio es quien establece los limites para cada incremento y decremento. Esto en que no ayuda, de entrada las responsabilidades están bien definidas, modulares y encapsuladas, aun que el sistema pudiera realizar todas las operaciones no seria bueno que lo hiciera ya que seria muy rígido y frágil ya que cada cambio que se realizara se afectaría todo el sistema, con esta separación de responsabilidades es menos rígido o en otras palabras muy fácil de realizar cambios y menos frágil un cambio no me rompe todo el sistema, dado que si el negocio cambia para cambiar los rangos de incremento o decremento los tipos de queso no se ven afectados su responsabilidad sigue siendo la misma o si se agregan, quitan o cambian su implementación los tipos de quesos el sistema no se ve afectado.


Para concluir podemos decir que el principio de la responsabilidad única es de los mas simples de los principios de SOLID, pero a la ves es de los mas difíciles de hacer bien, ya que a pesar que la separación de responsabilidades es algo natural en nuestro día a día, encontrar y separar bien estas responsabilidades en un programa es algo mas complicado y lo mejor es practicarlo he ir lo mejorando.


Por mi parte no me queda mas que agradecerles su tiempo y espero que el tema haya sido de su agrado y les sirva para su día a día y recuerda...




... hackea tu código!!!

Open Closed Principle

Como todos los desarrolladores de software sabemos, lo único constante en nuestro perfil es que siempre habrá cambios, por ello la necesidad de crear una metodología capaz de adaptarse a esos cambios y lograr un diseño que nos permita minimizar los posibles impactos de los mismos.

En este post explicaré uno de los principios Solid introducidos por Bob Martin (“Uncle Bob”), El principio Open/Closed el cual dice lo siguiente.

“Las entidades del software (clases, módulos, métodos, etc.) deben estar abiertas para extensión, pero cerradas para modificación.”

Este principio nos ayuda a tener un diseño en nuestros sistemas altamente desacoplado, ya que está basado en la creación de clases extensibles sin necesidad de modificar el código existente, es decir, se debe lograr un diseño que nos permita extender funcionalidad sin modificar lo que sabemos no se debe modificar. Sin embargo lograr esto es difícil, se debe conocer claramente cómo funciona el sistema, cómo interactúan y se comunican los componentes que lo integran y así poder predecir los puntos del sistema  en los cuales podría llegar a extenderse la funcionalidad.

Por ejemplo, tenemos un sistema de productos que se encarga de actualizar la calidad de los mismos, la calidad es solo un valor numérico que se incrementa (siendo 50 el valor máximo) o decrementa (siendo 0 el valor mínimo) según las reglas de cada producto y existen productos que no se actualizan.

En este tipo de sistemas es normal encontrarnos con algo como esto, para facilitar la explicación todos los atributos de la clase serán públicos.

class SistemaProductos{
    .
    .
    .
    public void updateQuality() {
        for (int i = 0; i < products.length; i++) {
            if (!products[i].name.equals("Increase")
                    && !products[i].name.equals("KeepQuality")) {
                if (products[i].quality > 0) {
                    products[i].quality = products[i].quality - 1;
                }
            } else {
                if (products[i].quality < 50) {
                    if (products[i].name.equals("Increase")
                            && !products[i].name.equals("KeepQuality")){
                        products[i].quality = products[i].quality + 1;                        
                    }
                }
            }         
        }
    }
}

Lo primero para poner en práctica este principio es identificar en tu diseño las partes del sistema que pueden llegar a extender su funcionalidad, en el ejemplo anterior vemos que existen diferentes requerimientos que nos informan de posibles cambios futuros como por ejemplo, productos que actualicen su calidad el doble de rápido, o productos que después de determinada calidad comiencen a disminuir en lugar de seguir aumentando, si no prestamos atención a este diseño, en un futuro podríamos tener un sistema tan grande y difícil de entender que el agregar una funcionalidad sería muy costoso, para evitar esto se puede aplicar el principio Open/Closed con ayuda de la abstracción ya sea por Herencia o con uso de interfaces, en este ejemplo, usaremos las interfaces.

Creamos una interfaz que nos ayuda a entender la tarea del sistema, QualityUpdater (No entraremos en detalle sobre nomenclatura de interfaces).

public interface QualityUpdater {
  public void updateQuality(final Item item);
}

esa interfaz formará parte de la clase producto.

public class Producto {
  public String name;

  public int quality;

  public QualityUpdater qualityUpdater;

  public Producto(final String name, final int quality) {
      this.name = name;
      this.quality = quality;
  }
}

Ahora el sistema debe hacer uso de la interfaz para actualizar el producto, y cada producto puede tener su propia versión concreta del QualityUpdater, de esa manera logramos desacoplar esa funcionalidad del sistema.

public class SustemaProductos{
   .
   .
   .

   public void updateQuality() {
      for (Producto product : products) {    
          product.qualityUpdater.updateQuality(product);
      }
   }
}

Es importante mencionar que un producto debe tener un QualityUpdater para poder actualizarse si no se agrega un QualityUpdater al producto tendremos una Excepcion.

Para los productos que aumentan su calidad tendríamos una implementación de la interfaz que contenga su propia lógica, algo como esto:

public class IncrementProduct implements QualityUpdater {
  private static final int MAX_QUALITY_PRODUCT = 50;

  @Override
  public void updateQuality(final Producto producto) {
      if (hasQualityToIncrease(producto)) {
          increaseQuality(producto);
      }
  }

  private static boolean hasQualityToIncrease(final Producto producto) {
      return producto.quality < MAX_QUALITY_PRODUCT;
  }

  private static void increaseQuality(final Producto producto) {
      producto.quality ++;
  }
}

Para los productos que disminuyen su calidad tendriamos una implementacion de la interfaz que posee su propia logica al igual que la anterior, seria asi.

public class DecrementProduct implements QualityUpdater {
  private static final int MIN_QUALITY_PRODUCT = 0;

  @Override
  public void updateQuality(final Producto producto) {
      if (hasQualityToDecrease(producto)) {
          decreaseQuality(producto);
      }
  }

  private static boolean hasQualityToDecrease(final Producto producto) {
      return producto.quality > MIN_QUALITY_PRODUCT;
  }

  private static void decreaseQuality(final Producto producto) {
      producto.quality --;
  }
}

Al agregar una nueva funcionalidad a un sistema no nos debemos olvidar de seguir soportando las funciones actuales del sistema, en el ejemplo anterior pasamos por alto que existen productos que no se actualizan, para solucionar esto creamos una función que nos informa si el producto actual es actualizable o no.

public class Producto {
  .
  .
  .

  public boolean isUpdatableQuality() {
      return qualityUpdater != null;
  }
}

Y nuestro sistema ahora sera capaz incluso de evaluar productos que no son actualizables.

public class SistemaProductos{
  .
  .
  .

  public void updateQuality() {
      for (Producto product : products) {
          if (product.isUpdatableQuality()) {
              product.qualityUpdater.updateQuality(product);
          }
       }
  }
}

Y así nuestro sistema de vuelve extendible de funcionalidad (Creando implementaciones para el QualityUpdater) sin necesidad de modificar lo existente (Para la clase sistema es transparente la implementacion de QualityUpdater que posee el producto).

En este ejemplo usamos un diseño por composición, en este tipo de diseños es muy común encontrarse con clases que parecieran no conocer todos sus atributos, es decir, la clase Producto desconoce la existencia de la interfaz QualityUpdater que posee, por ello la necesidad de llamar la interfaz dentro de la clase producto.

product.qualityUpdater.updateQuality(product);

Y no solo eso sino que la interfaz no tiene acceso directo a los atributos del producto por lo que se debe pasar como parámetro, si bien es un diseño que para muchos será incorrecto, es mejor tener un sistema desacoplado por composición que sufrir los dolores de cabeza de agregar funcionalidad a un sistema mal diseñado.

Es importante recalcar que el cambio siempre está presente y puede llegar un momento en que las necesidades del negocio puedan llegar a ser tan grandes que nos topemos con el hecho de que lo existente ya no es suficiente para cubrir todos los requerimientos, en este caso no habrá otra solución que cambiar lo existente, mas sin embargo, el impacto será menor por el alto desacoplamiento que ofrece un sistema regido por este principio.

Gilded Rose Kata con SOLID

Me encontré la Kata de Gilded Rose en uno de mis libros de cabecera The Coding Dojo de Emily Bache. En breve prometo traducir la Kata al español, pero por ahora, pueden encontrar de que se trata acá.

En esos días el tema de SOLID andaba caliente en entre el grupo de codeadores, que si la responsabilidad del soltero que si se abre y se cierra o que si se invierten. La cuestión es que por más estudio y videos sólo se aprende a programar pues… programando. Así que les lancé el reto que inicialmente era de Refactor y le di un twist aplicando los SOLID Principles.

Emily es una programadora muy linda y hasta proporciona los junits en su GIT porque ya saben, hacer refactor sin junit es como matar gatitos o tuitear lo que comiste. Pero yo soy un poco menos linda y más latosa por lo que les di el código productivo sin junits. Ya sé, algunos me dirán Rox que culeis, pero no es la primera vez que me lo dicen:

Así que el reto era:

1. Dar cobertura y hacer refactor sin tocar la clase Item class o la propiedad Items 
2. Aplicar uno o varios principios SOLID al código refactoreado. Ahora sí ya podían tocar cualquier código. 

Los programadores de cabecera de este honorable blog de fanáticos del código limpio y las inspecciones explican de que va cada principio y enseñan su código en nuestro GIT para su deleite y crítica.

Single Responsibility por Luis y por Víctor

Open Closed Principle por Toño

Liskov Substitution por Carlos

Interface Segregation por Yorch

Dependency Inversion

¡Espera más principios prontamente!

solId (Interface Segregation Principle)

Buenas tardes y bienvenidos a su blog codea-mesta, siguiendo con la mítica y fabulosa saga de SOLID [como me emociono!!!] les vengo a platicar un poco del principio de segregación de interfaces. Aqui el Yorch [ZetoWP] diciendo “Dj, Spin that $#17”.

Platiquemos de SOLID, específicamente de la I que viene de Interface Segregation Principle o Principio de Segregacion de Interfaces. Peroquée es lo que esto significa? veamos... Wikipedia nos dice lo siguiente.

http://en.wikipedia.org/wiki/Interface_segregation_principle

The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use. ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them...
...

Y esto qué quiere decir??? Se acuerdan de lo que sus maestros les decían? Recuerdan el divide y vencerás? sabe usted dónde están sus hijos a esta hora? [ok, ya estoy divagando]. El asunto es muy sencillo, si tienes una interfaz que esta haciendo muchas cosas por qué no separarla en varias interfaces que hagan una sola cosa???

Nosotros como coders conocemos el poder de las interfaces y clases abstractas, ese poder que nos deja utilizar una solución muy específica para hacer la chamba que requerimos, esa posibilidad de poder utilizar nuestras clases como plug-ins, esa versatilidad para intercambiar las partes sin que se vea afectado el resto de nuestro programa (main) con un comportamiento diferente y mismos resultados, o así debería de ser. Sin embargo en ocasiones dejamos que una sola interfaz se encargue de todo, convirtiendo nuestro esfuerzo se liberación independiente en algo que depende de muchas partes. Veamos un ejemplo.

En GildeRose se tiene que estar actualizando valores de los productos que tienen, tanto la fecha en la que se tiene que vender como su calidad, esto de diferentes formas según el tipo que sea. Esto nos da la idea de generar una interfaz [o una clase abstracta] y que para cada tipo se haga su implementación, correcto? Veamos esta interfaz:

public interface ItemUpdater {

    void updateSellIn(Item item);
    
    void updateQuality(Item item);

}

Una interfaz muy sencilla que nos deja hacer las implementaciones como necesitemos. Suena a una buena y elegante solución. Veamos una implementación:

public class RegularItemUpdater implements ItemUpdater {


    @Override
    public void updateSellIn(final Item item) {
        item.setSellIn(item.getSellIn() - 1);
    }


    @Override
    public void updateQuality(final Item item) {
        item.setQuality(item.getQuality()-1);
    }
}

y así podríamos tener múltiples Items con diferentes políticas. Si bien es correcto imaginemos que un equipo de trabajo se encarga únicamente de las políticas de SellIn y otro de las políticas de Quality, esto nos deja dos problemas:

- Desde que están en la misma clase ambas políticas si se tiene que alterar el RegularItem se tendría que trabajar 2 equipos con el mismo código al mismo tiempo, cosa que resulta en ocasiones en problemas con tu sistema de versionamiento.

- La segunda, dado lo mismo, un equipo conoce las políticas del otro!!! Esto podría ser información sensible para la empresa!!! sin contar el hecho de que un equipo puede añadir bugs al desarrollo del otro equipo!!!


Esto nos deja con un proyecto el cual no se puede desarrollar ni liberar independientemente, ya que para que el equipo sel libere a producción el equipo Quality debe liberar antes... y vice versa!!! esto es un problema.

Ya que entendimos el potencial problema que tenemos, y con un poco de Single Responsability Principle, podemos hacer el siguiente refactor:

    public interface SellInUpdater {

        void updateSellIn(Item item);
    }

    public interface QualityUpdater {

        void updateQuality(Item item);
    }


 


public class ItemUpdater {


    private QualityUpdater qualityUpdater;
    private SellInUpdater sellInUpdater;

    public ItemUpdater(SellInUpdater sellInUpdater, QualityUpdater qualityUpdater) {
        this.sellInUpdater = sellInUpdater;
        this.qualityUpdater = qualityUpdater;
    }

    public void updateItem(Item item) {
        this.sellInUpdater.updateSellIn(item);
        this.qualityUpdater.updateQuality(item);
    }

}

Esto, sabiéndolo manejar y tal vez usando algo de Dependency Injection Principle, nos puede solucionar la vida y tener a dos equipos trabajando por separado y de una forma más limpia y organizada. 

Interface Segregation Principle se trata de independencia, independencia para poder liberar, independencia para poder decidir, independencia de lo que no nos sirve [creo que necesitamos algo de ISP en varios gobiernos del mundo, o no?] y esto es lo que nos dará más potencia a nuestras interfaces, claro, esto puede hacer que tengas un mar de interfaces e implementaciones pero recuerda los beneficios y que es un principio, no una regla. Si crees que te puede ayudar en tu  proyecto no dudes en usarlo!!!

Bueno, si le entendieron le entendieron, y si no pues pueden dejar un comentario y con gusto trataré de responder lo mejor que pueda, hasta luego y que tengan una buena codeada.

Principio de Responsabilidad Única (SRP - Single Responsability Principle)

Principio de Responsabilidad Única

(SRP Single Responsability Principle)

Este principio, desde mi punto de vista, es la base para lograr un buen diseño de tu software y la verdad es muy fácil de entender, la definición nos dice:

Tu clase solo deberá tener una razón para cambiar.

Esto también deberá llevarse a nivel de métodos, entendiendo que la razón principal se va descomponiendo en pequeños fragmentos de tareas para cumplir el objetivo inicial.

...ahora como yo lo veo….

Si tienes una clase que vas a actualizar porque se mejoró un cálculo y luego porque cambiaste de motor gráfico y después porque agregaste un nuevo reporte y quien sabe porque no funciona si no haces un cambio en ésta clase; bueno he aquí muchas razones por las cuales tu clase cambia, esto hace evidente que algo anda mal en el diseño de nuestro programa. Llego la hora de aplicar... ¡SRP is comming!.

Tratando de ayudar al entendimiento de este principio, expondré un ejemplo:

Caso de Uso: Una tienda tiene artículos a la venta, de estos artículos las principales características son la calidad y los días disponibles para venderlos, ambos valores se ven afectados conforme transcurren los días, aunque no para todos los artículos y no de la misma forma.

Un primer diseño de esta clase fue:

public class Item {
    private String name;
    private int sellIn;
    private int quality;
    private QualityUpdater qualityUpdater;
    private SellInUpdater sellInUpdater;


    public Item(String name, int sellIn, int quality) {
        this.name = name;
        this.sellIn = sellIn;
        this.quality = quality;
        selectUpdaters();
    }

    private void selectUpdaters() {
        this.sellInUpdater = DispacherUpdaters.getSellInUpdater(name);
        this.qualityUpdater = DispacherUpdaters.getQualityUpdater(name);
    }

    public String getters() {...}

    public void setters() {...}

    public void update(){
        updateSellIn();
        updateQuality();
    }

    private void updateQuality() {
        qualityUpdater.updateQuality(this);
    }

    private void updateSellIn(){
        sellInUpdater.updateSellIn(this);
    }
}

Con este primer diseño los artículos que no cambian deben tener un QualityUpdater y un SellInUpdater que no hagan nada. Esto quiere decir que los updaters no son necesarios para todos lo artículos y además ésta misma clase busca sus updaters que utilizará para actualizar la calidad y los días de venta; otra responsabilidad a parte de mantener su información. Una forma de aplicar SRP seria:

1. Separar la lógica de los articulos que cambian y los que no.
2. Inyectar, para los artículos que cambian, la forma en que estos cambian.

public class Item {
    public String name;
    public int sellIn;
    public int quality;

    public Item(String name, int sellIn, int quality) {
        this.name = name;
        this.sellIn = sellIn;
        this.quality = quality;
    }

    public String getters() {...}

    public void setters() {...}
}

public class ItemUpdateable extends Item implements Updateable{

    private QualityUpdater qualityUpdater;
    private SellInUpdater sellInUpdater;

    public ItemUpdateable(String name, int sellIn, int quality) {
        super(name, sellIn, quality);
    }

    public void setQualityUpdater(QualityUpdater qualityUpdater) {
        this.qualityUpdater = qualityUpdater;
    }

    public void setSellInUpdater(SellInUpdater sellInUpdater) {
        this.sellInUpdater = sellInUpdater;
    }

    @Override
    public void update() {
        sellInUpdater.updateSellIn(this);
        qualityUpdater.updateQuality(this);
    }
}

Con esta solución tenemos dos clases resultantes, así los artículos que no cambian utilizan la clase Item y los artículos que son variables utilizan ItemUpdateable y además la forma en que actualizan la calidad y los días para venta son inyectadas.

Aplicar SRP nos ayudará a tener un mejor diseño de nuestro software, será fácil de entender y de modificar…¡Suerte!