Métodos Comunistas y Propiedades Capitalistas

No, este no es un artículo sobre política, sigue siendo sobre programación orientada a objectos (OOP), específicamente sobre métodos públicos y propiedades privadas, de allí el título.

Todo surge por un comentario que me hizo un querido amigo al leer mi publicación sobre las reglas pigbar de programación. El me comentó:

"Mr. Bladi, entiendo sus reglas acerca de que las propiedades deban ser privadas por aquello del encapsulamiento, ¿pero que todos los métodos deban ser públicos? eso me cuesta entenderlo, eso implica que no existen métodos privados, y yo debo saber lo que un objeto hace sin preocuparme del cómo, por lo que esos métodos privados pueden ser útiles."

... largo es el camino del aprendizaje ... pensé ... jajaja

y procedí a explicarle.

Le dije:
Tienes razón y estás equivocado. Todo al mismo tiempo como el gato de schrödinger.

Tienes razón porque el concepto de encapsulamiento implica que se guarda o encapsulan tanto las propiedades como los métodos en una clase, escondiendo los detalles de la implementación, y eso está súper bien.

Pero, y siempre hay un pero, estás equivocado por que el problema con los métodos privados es que esa funcionalidad que escondes dentro de las entrañas inescrutables de un método privado, no puede ser compartida por otras clases o partes del programa. En otras palabras, sí necesitas o llegas a necesitar que ese comportamiento se realice en otra parte del sistema, vas a tener que recurrir a algunos recursos poco recomendados como son el tristemente celebre Copy & Paste o recurrir a librerías con clases utilitarias, las cuales también son  poco recomendadas y las considero ofensivas en la OOP.

¿Me explico?

Por otra parte ese comportamiento, funcionalidad o utilidad del método escrito en forma privada, no forma parte de ningún contrato por el que deba trabajar la clase, no forma parte de ninguna interface, por lo que no podemos trabajarlo usando ese valioso y sagrado mecanismo de programar para una abstracción, para una interface o para un contrato.

La única forma de acceder esa funcionalidad es dentro de la clase misma donde nunca podrá ser compartida y, en mi experiencia, en la programación de sistemas no conozco aún una funcionalidad tan peculiar, tan única en si misma, que no merezca ni pueda ser compartida o generalizada dentro de una abstracción.

De acá se desprende el axioma: Todo método privado, TODOS; son candidatos a una abstracción, a una nueva clase, y deben ser migrados a esa abstracción.

Es por ello que impongo férreamente , con disciplina dura, el uso de los antes mencionados principios en lo referente a la visibilidad de propiedades y métodos. 

Por su parte, las propiedades deber ser privadas y en lo posible nunca expuestas al mundo exterior. Ellas forman parte del estado del objeto y son sus elementos mas sagrados. Con ello quiero reflejar que todos los objetos deberían ser inmutables para proteger al sistema de las consecuencias nefastas que derivan del control o gestión sobre los cambios de estados en las clases.

Es por ello que manifiesto que no deben existir setters, que las propiedades deben ser final y que los getters no son recomendados. Todo sea por preservar la inmutabilidad de la clase, favorecer el encapsulamiento y el ocultamiento de la implementación y, por qué no, de la estructura interna del objeto.