Un motivo de cambio / SOLID

Siempre he pensado que el cambio no es tan malo, pero depende... es en esos momentos en que uno acude a la red: ¿El cambio es bueno o malo? ... el caso es que en ocasiones es mejor estar preparado.

Del mismo modo cambian los requerimientos y no siempre es tan sencillo solventar situaciones si no se realiza un buen diseño y una buena estructura.  Mi amigo de kinder garden  Robert C. Martin, quién publicó 5 principios básicos dentro de Principios de Diseño y Patrones de Diseño, nos dejó una manera de hacer amena esta situación.

No es un estándar y tampoco hay algo que nos obligue a diseñar nuestros programas bajo estos principios, sin embargo, el seguirlos o apegarnos lo más posible, nos llevará a un diseño fácil de mantener,  escalar, más legible, más organizado y por consecuencia de mejor calidad.

Principio de Única Responsabilidad (Single Responsibility Principle)

La primera letra del acrónimo -o mejor dicho acrónimo de acrónimos- SOLID (S: Single Responsibility Principle), es el primer principio descrito por mi amigo. Éste principio establece que una clase debe tener una única responsabilidad -un motivo por el cual existe esa clase- en el sentido de que solo debe de haber una razón por la cuál deba ser modificada, es decir, un solo motivo de cambio.

Si una clase tiene dos o más responsabilidades, es decir, se encarga de tareas que refieren a contextos diferentes, necesariamente llegada la necesidad de cambio asumirá más de un motivo por el cual pueda ser modificada y esto afectará a tareas que no tienen que ver con el origen de dicha clase.

Para no menear tanto "bla bla bla" entremos al detalle ;) ...  Les debo el ejemplo ;)