[l-desarrollo] 5 Principios de Programación Orientada a Objetos aprendidos durante los últimos 15 años
Angel Leon
Anoche escribí un articulo sobre 5 principios que sigo cuando estoy
diseñando/programando orientado a objetos que quisiera compartir,
discutir y enriquecer.
Sobre todo quisiera oir la opinion del Prof. Novich nuevamente con
respecto a immutabilidad y que elaborase un poco sobre su experiencia
y opinion, recuerdo haberlo leido hablando de estos tópicos el año
pasado pero no consigo el correo.
El articulo original lo escribí en ingles en mi blog (creo que algunos
terminos son mas claros en ingles para los que leen en ingles aqui
esta el post http://www.gubatron.com/blog/2012/02/01/5-object-oriented-programming-principles-learned-during-the-last-15-years/
), la traducción a español fue realizada por mi amigo Carlos Carbonell
el dia de hoy, gracias!
Sin mas, aqui les dejo mis máximas.
==
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.
_______________________________________________
l-desarrollo mailing list
l-desa...@velug.org.ve
http://listas.velug.org.ve/mailman/listinfo/l-desarrollo