Consejos para evitar errores en la programación orientada a Objetos

[Alejo]

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.

 

Nolapeles