No seas estúpido

Alguna vez escuché que cuando leías un libro estabas siendo mucho más inteligente que la persona que lo escribió y sinceramente nunca lo entendí hasta hace unos días, el punto es que mientras que el autor dedico muchos años de su vida a hacer investigaciones, a escribir, corregir y publicar el libro, lo único que hiciste tú fue ir a una librería, pagar unos cuantos pesos y listo, leer verdades absolutas sin saber todos los detalles. Este capítulo quiere lograr que tengas un pensamiento similar y para esto irrumpe diciéndonos que la originalidad está sobrevalorada, y tiene mucha razón. Sigue leyendo si quieres saber por qué a veces el ser original no está bien visto.

No hay mucha gloria en ser estúpido


Al principio me pasaba mucho, cada vez que estaba leyendo un tema nuevo siempre me retaba a mi mismo y en vez de leer el ejemplo que me proporcionaba el libro intentaba llegar a el mediante mi razonamiento y después, al compararlo, si este no era igual me frustraba bastante. Vaya forma de ser un idiota. En tus proyectos es obvio que no debes de seguir este razonamiento pues créeme, alguien ya pasó por lo mismo que tú hace años y ya hay una solución bien diseñada que funciona bastante bien para la mayoría de los casos, el imitar en esta instancia no tiene nada de malo ya que la mayoría de estos ejemplos son públicos y están disponibles para que los uses cuando quieras y lo que es más, harán tus resultados mucho más consistentes y flexibles si lo aplicamos al ámbito del software.

Comencemos por los principios


Los principios de diseño no son otra cosa que lo que ya hablamos en el párrafo anterior pero aplicado al código, es decir, son una herramienta básica que pueden ser aplicados para diseñar o escribir código que lo harán mucho más fácil de mantener y extender. Ahora que ya sabemos de qué van estos principios, entonces podemos comenzar a hablar sobre unos cuantos de ellos.

  • OCP: Sus siglas significan Open-Closed Principle y va acerca del cambio pero un cambio especial, uno que requiere que exista el cambio sin que modifiques el código existente, es decir, abierto para la extensión pero cerrado a la modificación, ¿cerrado a la modificación? ¿De qué vas? Bueno, tranquilo, te lo vamos a explicar de la manera sencilla. Cerrado a la modificación indica que el comportamiento de determinado código no acepta cambios debido a que tú lo blindaste para asegurarte de esto, obvio, después de asegurarte que el código ya tiene el comportamiento particular que tu estabas buscando. Por otro lado, abierto a la extensión se refiere a que ya que tu clase hace exactamente lo que tu quieres la única forma de modificarlo será extenderlo, hacer una subclase de esta y que ahí la persona que quiera cambiarlo entonces haga lo que le de su gana. 
  • DRY: No, no se refiere a que algo estará seco como tal, basta de bromas. DRY significa Don't Repeat Yourself y se refiere que debes de evitar a toda costa el repetir código, si tus métodos hacen una tarea repetitiva entonces podrías hacer un método extra para que esa tarea se haga en una sola locación. 
  • SRP: Single Responsability Principle es a lo que sus siglas se refieren y va acerca de la responsabilidad. Aquí te tienes que dar cuenta que cada objeto en tu sistema debe de tener una sola responsabilidad y que los servicios del mismo tienen que ser relacionados con esta funcionalidad y nada más. De lejos, este es el más difícil de seguir ya que podemos caer en el error de saltárnoslo sólo un poco pero cuando llega el momento de extender esa funcionalidad pues terminamos con un objeto que hace mal muchas cosas en vez de un objeto que haga bien una sola cosa. 
  • LSP: ¿Quién era Liskov? No lo sé, pero este principio tiene que ver con él e indica que los subtipos deben de poder ser sustituibles por sus tipos base, a decir verdad me costó un poco de tiempo digerir este principio pero queda un poco más claro si lo relacionas con la herencia. Si una clase hereda de una clase base entonces esta debe de poder ser sustituida con esta clase base, si esto no se cumple entonces las puertas del infierno pueden ser abiertas y te sufrirás un castigo eterno ya que usaste de manera incorrecta la herencia. Conceptos como la delegación, composición y la agregación que ya deberías de saber están íntimamente relacionado con el uso de la herencia así que no estaría nada mal el que le echaras un ojo de nuevo a estos conceptos.
Conclusiones


Así es, no ser estúpido y usar las soluciones ya propuestas por alguien con más experiencia que tú y aceptadas por toda la comunidad es una muy buena forma de crecer en tu carrera como programador. Ser original está bien, pero a menos que estés programando algo que jamás se haya visto entonces déjame decirte que sólo estarás perdiendo el tiempo. Los principios de diseño están ahí para ser usados, no decepciones al dios de los patrones ya que el castigo es una vida de desdicha. 

¡Nos vemos a la vuelta!

Recuerda que siempre puedes visitar la página de O'REILLY y comprar el libro del cual estos post están basados. 

Comentarios

Entradas populares de este blog

8 pharos

Primer uso de Google Cloud Functions

Dale justo lo que necesita