Crónicas del Buen Programador: 5 Principios de Programación Orientada a Objetos aprendidos durante los últimos 15 años

Fue hace unos 15 años cuando creé por primera vez mi primera clase.

Cuando empecé, pensaba en la programación Orientada a Objetos como un paradigma asombroso que debía conocer, recuerdo tener todos esos modelos mentales de los objetos y el aprendizaje de todo este nuevo vocabulario que realmente no entendía del todo hasta que años más tarde diseñé e implemente sistemas más grandes y más complejos.

Al principio, recuerdo mirar los objetos como una colección de funciones que mantenía una referencia común para mantener los estados internos, a la vez que me perdía de todas esas grandes características de la herencia y clases abstractas. Miraba las “interfaces” y las usaba como una receta sin realmente conocer su verdadero poder, miro al pasado y me doy cuenta de que mis conocimientos estaban muy limitados y espero que cuando mire este post dentro de 15 años piense lo mismo.

Existen un montón de libros sobre las mejores prácticas de programación que deberían leer, en este breve post compartiré con ustedes 5 principios que sigo y que prometo les servirán para mejorar el comportamiento de su código, para que sea menos propenso a errores, y para que sea simple y elegante. Estos consejos probablemente aplicarán mejor si programan en cualquier lenguaje como Java o C#, no estoy seguro si se pueden seguir estos principios al 100% en otros lenguajes OO (como por ejemplo aquellos que permiten herencias múltiples).

1. Principio NTR.
Este es uno de los más aconsejados, y yo también lo recomiendo. NO TE REPITAS, de verdad, no lo hagas, el código se volverá en tu contra. Sólo repite si es muy difícil no hacerlo o si estás absolutamente seguro de que no te repetirás por tercera vez, aunque te prometo que esa tercera vez llegará para ti o para la persona que tenga mantener que mantener ese código.

El beneficio obvio de no repetirte es que podrás mantener el código con facilidad haciendo los cambios necesarios en un solo lugar, el beneficio adjunto será que el código comenzará escribirse por sí mismo como una ecuación perfecta a medida que crece. Programar basado en el principio de NTR permitirá que tu código sea reutilizable y mantenible, ya que de una u otra forma todos los demás principios de los que hablaré están relacionados con esto.

2. Mantén el alcance (scope) al mínimo, se lo más privado posible.
Mantén las variables lo más cerca posible de su ámbito local como sea posible. Esto te ahorrará muchos dolores de cabeza, te protegerá de errores en la lógica de tu programa por haberle hecho algo a una variable o cambiar algo en el lugar incorrecto, y también te mantendrá las cosas más simples.

Esto también puede hacerte pensar que tus clases deben exponerse lo menos posible. Mantén tus variables locales, si no pueden ser locales, trata de mantenerlas como miembros privados, si tienen que ser utilizadas por clases que vayan a extender la funcionalidad mantenlas privadas, sólo usa variables públicas cuando realmente sepas que se puede hacer algo público y que nadie va a corromper el funcionamiento del objeto si en algún momento juegan con la clase.

Mantener el alcance (scope) al mínimo, también puede prevenir los problemas en objetos de larga duración como objetos únicos a los que otros objetos puedan acceder. Si abusas del uso de las propiedades de un objeto podrás encontrarte con situaciones en las que un objeto pueda modificar el estado interno de otro y que este a su vez está siendo utilizado por otro ocasionando un comportamiento inesperado, esto tiende a suceder muy a menudo en entornos multihilo donde los programadores no son cuidadosos y se olvidan de que algunos objetos pueden ser accedidos por diferentes hilos / clientes al mismo tiempo; reduce el alcance (scope), eso te protegerá.

3. Se funcional
A veces te sentirás tentado a ser perezoso y no pasar parámetros a un método pensando que eres muy listo y que es mejor cambiar alguna propiedad interna del objeto de modo que otra función de la misma clase pueda acceder a ella; gran error. Esto puede ser equivalente al consejo de los lenguajes de programación funcional, donde se dice que el uso de variables globales es una mala idea. Sí, tenemos propiedades de los objetos por varias razones, pero si la lógica de un método depende del estado de una variable, también podrías ser explícito y pasarla en el método como parámetro.

Esto está en cierto modo relacionado con el principio de mantener el alcance (scope) al mínimo, y en cierta medida relacionado con el consejo de algunos programadores que dicen que se debe mantener los objetos tan inmutables como sea posible.

4. Sólo vale la pena extender las clases abstractas.
Si tienes el control sobre la clase que estás a punto de extender (si está en tu código base), antes de extenderla echa un vistazo y asegúrate de que es una clase abstracta. Las clases abstractas están destinadas a ser extendidas, por lo que puedes estar seguro de que estás haciendo lo correcto.

Si estás extendiendo una clase que no es abstracta, probablemente deberías más bien extender por delegación (en el caso de Java que no soporta herencia multiple) o mejor aun, compon la funcionalidad que necesitas en la clase nueva. Si no tienes acceso al código de la clase que se extiende, las cosas podrían no comportarse de la manera que esperas, no todos los programadores son tan reflexivos como tú.

5. Mantén la duración de un objeto lo más corta posible.
Esto se relaciona con mantener el alcance (scope) al mínimo y tratar de evitar objetos únicos tanto como sea posible (dependiendo de la conveniencia), en el caso de java el JRE tiene un mejor tiempo de recogida y te ahorrará de problemas como pérdida de memoria. Pon esas fábricas a trabajar.

Siéntete libre de disentir y compartir tus principios favoritos. Si llevas mucho tiempo codificando de seguro que tiendes a pensar en estas cosas también, y me encantaría aprender de sus experiencias.

Traducido del artículo original “5 Object Oriented Programming Principles learned during the last 15 years” por Carlos Carbonell.

[ad#Google Adsense-468x15ContentLinkunit]

Sobre el Autor

Angel León (aka Gubatron) es un Ingeniero de Software Venezolano (UCAB) que ha desarrollado desde sencillos sistemas con bases de datos relacionales, servicios webs distribuidos para millones de visitantes mensuales, software p2p de uso masivo, hasta aplicaciones para dispositivos mobiles, todo esto empleando gran variedad tecnologías abiertas (Linux, Android, Java, Python, PHP, C++, Javascript).

Estas crónicas son inspiradas en el libro “The Pragmatic Programmer” (un libro que debería ser un texto obligatorio en todo curso de Ingeniería de Software) junto con las experiencias de Angel León durante los últimos 8 años desarrollando software en Venezuela y los Estados Unidos.

[ad#Gubatron-AmazonAd-PPBook-120×240]
  • Rafael

    Que buen articulo, aunque fue publicado hace mucho tiempo me veo en la necesidad de comentar porque me aclaro MUCHAS dudas xD
    Justo estoy haciendo un pequeño sistema en entorno web usando PHP5, y para obtener experiencia (aparte de que me gusta arriesgarme en cierto modo) decidí usar la POO, y justamente por dejar un objeto mucho tiempo en la ejecución de un script daba lugar a MUCHOS errores, en fin los mejores consejos que he leído hasta ahora sobre POO.