Refinamiento Sucesivo

Si te mostrara ahora un trozo de código y te dijese: “Mira que limpio está” podrías pensar que esto ha salido a la primera de mi cabeza porque soy  muy bueno pero no es así. Cuando escribes un código la mayoría de veces te  pasará que empiezas a hacer cosas “porque funcionan” sin pensar mucho  en las buenas prácticas sobretodo cuando estás empezando con ellas. Pero no por eso debes dejarlo pasar.

Continue reading

Concurrencia

Concurrencia… Aaaah mi amiga la concurrencia, como te quiero y te odio a la vez. Tú junto con la recursividad has sido, de momento, los dos conceptos  que más me ha costado entender en la informática. Es de esas  cosas que o entiendes a la primera o tardas tiempo hasta que un día, hace  “click” en tú cabeza y todo cobra sentido, vamos a por ti ¿eres realmente tan  necesaria?

Continue reading

Las 4 reglas de un buen diseño

Aparición

¿Que pensarías si te contara que existen cuatro simples reglas que te ayudaran a crear buenos diseños según trabajas? Cuatro reglas con las que aparece el buen diseño por si solo y estas son las cuatro reglas de Kent Beck del Diseño Simple, estas las deben de cumplir nuestra aplicación:

  • Pasar todos los test
  • No debe tener duplicidad
  • Expresar la intención del programador
  • Minimizar el número de clases y métodos

Están ordenadas por importancia de las mismas.

1. Pasar todos los test

Lo primero y principal tiene que ser una aplicación testable, esto es importante y creo que sabes porque pero te lo recuerdo. Si nuestro sistema es testable 100% sabremos rápidamente cuando falla y donde falla gracias a los test (si los ejecutamos cada vez, obviamente). Para que nuestro sistema sea testable nos será más sencillo si respetamos el principio de responsabilidad única del que ya hemos hablado en anteriores ocasiones y si usamos técnicas como TDD que se basa en hacer test antes de la propia implementación. Por ello algo tan simple, a primera vista, como que nuestra aplicación tiene que estar testada de principio a final y ejecutar estos test continuamente hará que sea una aplicación más cohesiva y menos acoplada, ambos parte del objetivo principal de la orientación a objetos.

2-3. Refactorizar

Por cada pocas líneas que escribamos debemos pararnos a pensar si realmente se pueden escribir o estructurar mejor, si hay expresiones que extraer como métodos para que sea más legible, si tenemos variables mal nombradas, etc. Esto es mucho más cómodo si tenemos test que nos aseguran que tras cada cambio todo sigue funcionando correctamente. Este paso es bastante importante ya que de primeras podemos darle una solución a una implementación según nos vienen a la cabeza para que pase nuestro test, pero luego, en frío vemos lo que acabamos de escribir y vemos con mayor claridad que es mejorable, si es así, a por ello mejóralo no lo dejes por miedo!

Muchas veces mientras escribimos nuestra solución estamos tan metidos en el problema y estás tan metido en él que comienzas a escribir trozos de código duplicado sin pensarlo, pones nombres a variables con prisas porque solo quieres ver ya después de horas ver ese test en verde y escribes líneas que en unos días te arrepentirás de no haber hecho como es debido. Así que para, lee y piensa mi yo del futuro le gustaría ver esto.

4. Minimizar clases y métodos

Esta regla está al final porque es la que menos prioridad se le da y es porque muchas veces para ayudar a que la aplicación sea más expresiva y no tenga duplicidad de código, creamos clases o métodos minúsculos añadiendo más y más clases y métodos a la aplicación. Pero no te preocupes, si lo has creado y este tiene una razón de ser es porque debe existir. Y como todo en esta vida, la experiencia te va haciendo ver cuando debes y no extraer esa clase o método. Poco a poco se aprende.

Libro original

¿Cómo construirías una ciudad?

Sistemas

En este capítulo el autor empieza con un símil que me gusta mucho y voy a tratar de traducir lo más fielmente que sé.

¿Cómo construirías una ciudad?

¿Podrías administrar todos los detalles por ti mismo? Probablemente no. Incluso administrar una ciudad es mucho para una sola persona. Sin embargo, las ciudades funcionan (la mayor parte del tiempo) Funcionan porque tienen equipos de personas que administran partes de la ciudad, el sistema de agua, etc […] Las ciudades funcionan porque tienen los niveles apropiados de abstracción y modularidad haciendo posible para las personas y “componentes” se las arreglen para trabajar efectivamente, sin entenderla a gran escala. Aunque los equipos de desarrollo a menudo se organizan así también, los sistemas en los que trabajan a menudo no tienen la misma separación de preocupaciones y niveles de abstracción. […] En este capítulo veremos como mantenerse limpio a niveles altos de abstracción, a nivel de sistema.

Y me gusta porque realmente veo así una aplicación o producto software como un ente enorme que tienes que separar en pequeñas “responsabilidades” para poder gestionarlo.

Separar la construcción de un sistema de usarlo

Una de las formas de separar la construcción del uso es mover todos los aspectos de construcción (creación de objetos) a nuestro main. De esta maneja queda un flujo limpio y fácil de comprender, creamos todos los objetos que nos hacen falta en el main y luego los enviamos a la parte de nuestra aplicación donde nos sea necesario. Es decir a nuestro main no le entra información de la aplicación solo envía hacia afuera.

Fábricas

Esto no siempre es posible, por ejemplo si tenemos una aplicación de pedidos, esta tendrá que modificar la lista de pedidos añadiendo un nuevo objeto alguna que otra vez. Para ello podemos usar el patrón Abstract Factory

abstract factory esquema

Como podemos ver nuestro cliente (main) tiene una interfaz genérica para nuestros productos (productoA) y una fábrica (AbstractFactory), de esta manera el conoce que puede crear productos mediante el uso de la fábrica pero desconoce como esta los crea ya que es una interfaz y carece de detalles de implementación. A él lo único que le interesa e importa es que puede crearlos y usarlos.

Inyección de dependencia

La inyección de dependenciaconsiste, como su nombre indica, en añadir, insertar dependencia a un objeto. Esto no es recomendable porque creas una dependencia grande entre objetos pero en ocasiones es la mejor solución que tenemos para asegurarnos de que el objeto B que usamos dentro del objeto A es el que queremos y como lo queremos.

Una interfaz puede ser algo como IDisposable, IEnumerable o IPrintable. Una clase es una implementación real de una o más de estas interfaces: List o Map pueden ser implementaciones de IEnumerable.

Para entendernos: a menudo tus clases dependen unas de otras. P.ej. podría tener una clase database que acceda a su base de datos, pero también desea que esta clase inicie sesión para acceder a la base de datos. Supongamos que tiene un registrador (logger) entonces la base de datos tiene una dependencia al registrador.

Hasta aquí todo bien.

Puede modelar esta dependencia dentro de su clase de Base de Datos con la siguiente línea:

var logger = new Logger ();

y todo está bien Está bien hasta el día en que se da cuenta de que necesita un grupo de registradores: a veces desea iniciar sesión en la consola, a veces en el sistema de archivos, a veces usando TCP / IP y un servidor de registro remoto, y así sucesivamente …

Y, por supuesto, NO quieres cambiar todo tu código (mientras tanto, tienes miles de millones) y reemplazar todas las líneas

var logger = new Logger ();

por:

var logger = new TcpLogger ();

Primero, esto no es divertido. En segundo lugar, esto es propenso a errores. Tercero, este es un trabajo estúpido y repetitivo para un mono entrenado. Entonces, ¿Qué haces?

Obviamente, es una buena idea introducir una interfaz ICanLog (o similar) que implementan todos los registradores. Así que el paso 1 en tu código es lo que haces:

ICanLog logger = new Logger ();

Ahora que la inferencia de tipo ya no cambia de tipo, siempre tienes una única interfaz contra la cual desarrollar. El siguiente paso es que no desee tener un nuevo Logger() una y otra vez. Así que pones la fiabilidad para crear instancias nuevas en una única clase central de fábrica y obtienes un código como:

ICanLog logger = LoggerFactory.Create ();

La fábrica misma decide qué tipo de registrador crear. A su código ya no le importa, y si desea cambiar el tipo de registrador que está utilizando, cámbielo una vez: Dentro de la fábrica.

De esta manera con la interfaz te aseguras que todas las implementaciones de registrador, sea cual sea actúen de la misma forma ya que implementan la misma interfaz. Esta última último tramo de la publicación es una traducción de una respuesta en StackOverflow la respuesta completa aquí

Libro origina