Principio abierto cerrado (OCP) Parte II

Teniendo en cuenta los comentarios recibidos en la entrada anterior y en forma personal, paso a comentar otra forma de poder cumplir con este principio abierto y cerrado (OCP): la implementación del patrón de diseño strategy.
Este patrón de diseño, establece que los comportamientos no deben heredarse. En su lugar, se deben encapsular usando interfaces.
Para dar un ejemplo, me remitiré a uno ya existente en el libro Head first design patterns.

Debemos programar una simulación de un pato, para ello, creamos una clase abstracta denominada Pato, la cual posee los métodos (o comportamientos) Cuac(), Nadar() y Mostrar(). Todos los patos hacen cuac y nadan, por lo que esta clase implementa dichos métodos. Pero, como todos los patos lucen diferentes, el método Mostrar será abstracto, es decir, se implementará en cada subclase.

Seguir leyendo el post »

Por Juan Barrionuevo

Principio Abierto Cerrado (OCP)

La segunda letra del acrónimo S.O.L.I.D., representa al principio Abierto Cerrado. El cuál establece que "Las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para extensión pero cerradas para modificación". Esto básicamente significa que debemos ser capaces de cambiar el comportamiento externo o las dependencias externas de una clase, sin tener que cambiar físicamente la clase en sí misma. Este tipo de comportamiento nos habilita a cambiar una parte del código sin estar obligado a cambiar otras partes del mismo, siempre y cuando nos mantengamos dentro de los límites del contrato existente.
Suena fácil, pero muchos desarrolladores podemos perder el norte durante la implementación de este enfoque de extensibilidad. No se trata necesariamente por una cuestión de habilidades, sino más bien, que no se nos ha enseñado a abordar este principio en el diseño de clases.

Seguir leyendo el post »

Por Juan Barrionuevo

Principio de responsabilidad única (SRP)

El principio de responsabilidad única (SRP) es el primer principio del acrónimo SOLID y establece que "Nunca debe haber más de una razón para que una clase cambie".
Algo con un propósito, una responsabilidad, siempre va a resultar mucho más fácil de cambiar. Esto es simplemente porque se puede ver mucho más claramente lo que hace y lo que no. Además, como tiene una única responsabilidad, no hay chance de que el cambio en el código pueda afectar a otro código, comportamiento quizás, pero código, no. Y mejora en gran medida la reutilización de código.
Finalmente, el código se hace mucho más fácil de probar ya que se puede realizar el test de una responsabilidad en forma aislada de las demás.

Seguir leyendo el post »

Por Juan Barrionuevo

Los principios S.O.L.I.D.

Toda aplicación nace de los requisitos de una persona que los realiza. Si dichos requisitos fueran inamovibles e inmutables a lo largo del tiempo, las modificaciones de software nunca serían necesarias.

Lamentablemente, esto es sólo una utopía para los programadores y con el correr del tiempo hemos tratado de no caer en las trampas que nosotros mismos nos creamos cuando programamos sin pensar en los cambios que los requerimientos pueden sufrir a lo largo del tiempo.

Entra tantas mejoras que se han ido agregando al desarrollo de software, la programación orientada a objetos (P.O.O.) se ha convertido en un conocimiento que hoy se considera muy importante para esta tarea.

Implementar los principios S.O.L.I.D., nos redundará en una mejora sustancial del diseño y arquitectura de nuestras aplicaciones, haciendo que las mismas sean mucho más flexibles y extensibles.

Este acrónimo mnemotécnico surge de la unión de varios principios básicos de la programación orientada a objetos, explicados en el libro "Agile software development: Principles, Patterns and Practices" por uno de los grandes exponentes de la Artesanía del software: el famoso Uncle Bob (Robert Cecil Martin).

Seguir leyendo el post »

Por Juan Barrionuevo

Principio K.I.S.S. ( parte II )

Habiendo desarrollado en la última entrada de este blog el concepto del principio K.I.S.S. y sus beneficios, veremos a continuación la segunda y última entrega de este principio.


Cómo aplicarlo al trabajo diario
Son muchos pasos los que se deben llevar a cabo, muy simples, pero pueden resultar un reto para algunos.
Tan fácil como suena, mantenerlo simple, es sólo cuestión de paciencia. Sobretodo, con uno mismo.
A continuación, veremos los puntos a tener en cuenta para llevarlo a cabo:

• Ser humilde. No pensar en uno mismo como un super genio. Este es el primer error. Siendo humilde, es muy posible alcanzar el estatus de super genio. Pero, aunque así no se lograse, a quién le importa?! El código es simple y estúpido, por lo que no hay que ser un genio para trabajar con él.
• Dividir las tareas en subtareas que, en principio, no deben llevar más de 4-12 horas de codificación.
• Dividir los problemas en pequeños problemas. Cada problema se debe poder resolver dentro de una o muy pocas clases.
• Mantener los métodos pequeños. Cada método no debe tener nunca más de 10-20 líneas y sólo debe resolver un (y sólo un) problema. Si contiene muchas condiciones, hay que dividirlo en métodos más pequeños. (Esto no sólo los hace más legibles y mantenibles, sino que además, encontrar errores es mucho más rápido.
• Mantener las clases pequeñas. Aplicar la misma metodología que con los métodos.

Seguir leyendo el post »

Por Juan Barrionuevo