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