Atributos de clase: Encapsular Vs Maps

[Xerelo]

Estoy leyendo un libro sobre programación a objetos Head First Object-Oriented Analysis&Design. Me parece que es muy ameno, y aporta unas cuantas ideas interesantes sin profundizar en aspectos teóricos.

Sin embargo, en el tema de atributos de clase, no comparto la recomendación de potenciar el uso de Maps frente a la creación de clases para encapsular atributos. Debido a mi falta de experiencia en este tema, me gustaría conocer la opinión de otras personas.

Para poneros en situación, voy a describir un par de ejemplos del libro donde recurren a las propiedades en Maps.

En uno de los ejemplos, se crea un inventario de instrumentos, siendo Instrumento una clase genérica pero instanciable (precio, referencia), donde los atributos específicos de cada instrumento se guardan en una clase por cada tipo de instrumento, pero referenciada como atributo de la clase Instrumento.

Posteriormente con el fin de mejorar la flexibilidad del software, lo que recomiendan es sustituir la clase encapsulada ( con las propiedades específicas de cada instrumento) por un Map con esos mismos atributos.

Bien, las ventajas que ofrece este método son:
-No tener que crear una clase por cada nuevo instrumento
-Facilita el código ya que no es necesario distiguir entre las distintas clases de propiedades de instrumentos.

En mi opinión este método aporta una excesiva libertad que puede dar problemas, ya que en el código no queda constancia de los atributos que se esperan para cada instrumento, y permite la creación de objetos con propiedades erróneas o incompletas.

Evidentemente, eso se puede solucionar creando código de comprobación de propiedades en cada instrumento, pero precisamente eliminaría la ventaja de usar Maps, no necesitar nuevo código para añadir instrumentos ni para comprobar que las propiedades son correctas.

¿Es realmente útil el uso de Maps para guardar atributos de clase?

[GreenEyed]

IMHO, una barbaridad de recomendación. Para eso usa un lenguaje con tipado debil sin comprobación de propiedades en tiempo de compilación y listo.

Lo cual viene a re-demostrar que no por que algo esté escrito en un libro, tiene por que ser cierto ni adecuado . He conocido a algunos autores "reconocidos" de libros de Java y si la gente supiera la verdad detrás de algunos libros (no sólo de Java, si no técnicos en general) se le pondrían los pelos de punta.

S!

[Xerelo]

Viendo tu contundente respuesta, creo que o he exagerado un poco lo de la recomendación, o realmente es tan mala idea como me imaginaba.

Quizás por ser un ejemplo sencillo que trata de explicar una serie de conceptos básicos, superponiendo prácticas erróneas para explicar mejor las ventajas de lo correcto, ha hecho que se les fuera la mano, pero el "proyecto" termina tal cual lo he comentado. La evolución del ejemplo es ésta

-Crear una clase con los atributos comunes y específicos de una guitarra, ya que al principio sólo se venden guitarras
-Añadir un nuevo instrumento, entonces es cuando aparece la clase Instrumento con las propiedades comunes y las clases [instrumento]Specs con las específicas de cada instrumento.

Hasta aquí estaba de acuerdo con las mejoras propuestas, y entendía la utilización de pasos "erróneos" para explicar mejor las diferencias con las buenas prácticas.

-Finalmente se pide añadir muchos nuevos instrumentos, y por las razones que ya he comentado, deciden eliminar las clases [instrumento]Specs y sustituirlas por una sola clase IntrumentoSpecs con un Map de propiedades (esto no lo expliqué bien antes) .

Literalmente dicen

When you have a set of properties that vary across your objects, use a collection, like a map, to store those poperties dynamically.
You'll remove lots of methods from your classes, and avoid having to change your code when new properties are added to your map

Después hacen un ease-of-change test, donde se habla de lo estupendo que es no tener que tocar el código para añadir nuevos instrumentos o propiedades de los instrumentos.

Creo que es bastante evidente que las propiedades específicas de un instrumento en concreto no es algo que vaya a variar tanto, y además, no entiendo la ventaja que supone encapsular únicamente el Map en su propia clase, podrían haberlo dejado como atributo de Instrumento.

En capítulos posteriores, en un tema que trata sobre arquitectura, vuelven a recomendar la misma solución para un juego de guerra, creando una clase genérica Unidad, con una variable que almacena el tipo de unidad, y un Map para las propiedades. Curiosamente esta vez, no deciden encapsular el Map en su propia clase.

[dackiller]

En mi opinion personal como programador autodidacta, creo que las ventajas y desventajas depende de como apliquemos las herramientas.

Es decir, que podemos conseguir mil formas de obtener los mismos resultados, la cuestion esta en el metodo que cada uno de nosotros usemos para obtener los resultados.

Creo que lo que comentas del libro, podria ser una solucion de miles de soluciones que bien puede ser valida. En lo que no estoy de acuerdo es en que se esta usando un metodo que me parece estar fuera de contexto y mas aun cuando es de java que es pura programacion de objetos, ovbiando conceptos basicos como poliformismo y herencia.

Joder.... Entonces ? Como se aprende a programar POO con soluciones en las que no aplicas conceptos de POO como poliformismo o herencia...

Jeje, aprende lo que sirva de ese libro y regalalo...

Saludos..

[HackmanC]

Hola,

Iniciado por Xerelo

... Creo que es bastante evidente que las propiedades específicas de un instrumento en concreto no es algo que vaya a variar tanto, y además, no entiendo la ventaja que supone encapsular únicamente el Map en su propia clase, podrían haberlo dejado como atributo de Instrumento. ...

Creo que el problema básicamente está sobre la definición y el ejemplo. Creo que la definición es adecuada pero el ejemplo es malo, o está mal aplicado. Concretamente ese patrón de diseño se aplica bastante en Jasper, Commons, JPA, HIbernate, etc., con el objetivo de abstraer las librerías para su uso genérico.

Básicamente, ¿Como represento los datos de un reporte, una base de datos o un archivo XML si todos son diferentes?

No puedo crear una clase por cada tipo de reporte, ni por cada tabla de la base de datos, o miles de clases para cada archivo XML que vaya a procesar. Pero sí puedo crear una clase que las represente a todas. En el caso del XML una clase que represente los nodos. Y posiblemente use una colección genérica (generics) de cualquier tipo para representar los atributos y los datos.

El problema es que el ejemplo es pésimo, en un juego de guerra no habrán mas de una docena de tipos de unidades, en ese caso ... ¿porqué no usar la programación orientada a objetos consecuentemente así como lo menciona dackiller y GreenEyed?

* Es casi lo mismo que había escrito dackiller.

Saludos,