Recientemente leí un artículo escrito por Hernán Wilkilson sobre las nuevas características incluidas en la versión 8 de Java. Más allá del interesante análisis que hace Hernán, creo que son muy valiosas las ideas compartidas en la conclusión del artículo (recomiendo tomarse unos minutos para leerlo) sobre todo el llamado a los programadores a «abrir a la mente». Profundizando en este llamado quiero sumar algunas impresiones.
Como dice la frase «el que tiene un martillo en la mano sólo ve clavos», las herramientas que utilizamos para resolver los problemas influyen de forma determinante en las soluciones que diseñamos. Si bien ya hace años que tomé conciencia sobre este hecho, me sorprendí muchísimo cuando hace unos meses me sumé a trabajar en un proyecto Java con un equipo de experimentados programadores que en su carrera profesional habían trabajado casi exclusivamente con Java. O sea, habían usado otros lenguajes pero muy por arriba. Por mi parte, he trabajado mucho con Ruby y C#, un poco menos con Smalltalk y Javascript y muy poco con Java, Python y Php. Estas diferencias de experiencia han hecho que a la hora de plantear soluciones nos encontremos con propuestas bastante distintas. Un ejemplo de esto que me resulta muy chocante, y que es muy común en el mundo Java, es la práctica de separar datos y lógica. Esto lleva a tener clases que son simples contenedores de datos y clases que sólo tienen métodos para manipular datos contenidos en otros objetos, algo bastante anti-POO.
Creo que lo ideal para todo equipo sería contar con programadores «políglotas» pero me parece que no es algo muy común. Mi impresión es que en general las empresas muchas veces apuntan a sacar el mayor provecho de sus «recursos» y eso provoca que «los recursos» se especialicen y «encierren» en una única tecnología. Ojo, no es algo que pase sólo en las empresas, muchos veces quienes trabajan en forma independiente también deciden enfocarse/encerrarse tecnológicamente, ya sea por cuestiones de comodidad y/o rentabilidad.
Dada esta situación y desde el punto de vista de equipo creo que puede resultar interesante contar con un un programador de otro pozo, o sea, integrar en el equipo un programador que tenga experiencia en otros lenguajes/tecnologías pues puede aportar una visión diferente y enriquecer al equipo.
Blog de NicoPaez 
Yo trabajo en Java en una pyme y estamos desarrollando (continuamente) un producto y se nos hace bastante difícil no tener las entidades del modelo como «simple contenedoras de datos» ya que depende mucho del cliente particular donde se instala el producto. Al usar JPA-Hibernate y tratar que el producto sea extensible para distintos clientes de a poco sacamos esa lógica de negocio de las entidades. Cuando discutí esto con Pantaleo en Técnicas de diseño me pareció (por ahí le entendí mal) que me recomendaba duplicar las entidades, una con el mapeo y otra como la entidad de negocio pero no creo que esto sea muy práctico.
Por otro lado me gustaría saber si el libro va a estar en el quiosquito de EUDEBA en FIUBA.
Saludos
Estas clases que son simples contenedores de datos y clases que sólo tienen métodos, son lo mismo que las entidades en ASP MVC?, tambien estoy manejando Clases que solo me sirven de puente en mis señales al desarrollar juegos. Que alternativa se puede encontrar y porque no deberían usarse?
Hola Carlos,
No exactamente. Lo que me refiero en el post tiene que ver puntualmente con el modelado de la lógica del negocio. En el auge de J2EE y los EJB había una moda de separar los datos del negocio de la lógica que los manipula, pues ello facilitaba el uso de varas características de los contenedores EJB.
Luego con el correr del tiempo y principalmente a partir de la aparición de otras herramientas y conceptos esta moda fue cambiando pero aún así en algunas cosas hay gente que sigue trabajando así.
Hoy en día algo bastante difundido es lo que plantea Eric Evans bajo el nombre de Domain Driven Design.
Por otro lado lo que vos comentas no parece ser lógica de negocio, sino que tiene más pinta de DTO.
Saludos!
NicoPae
Gracias he estado averiguando mucho sobre lo que hablas y entiendo algunas cosa y me enredo en otras, tambien quisiera saber si me puedes recomendar alguna publicación, libro o blog, acerca del uso de uml en practicas ágiles, tengo entendido que esta en desuso, pero no encuentro alguna herramienta de peso para exponerle a la universidad. perdon pero no encotre otro medio para preguntar.
Las prácticas ágiles no dicen nada particular sobre UML, ni a favor ni encontra. UML es una herramienta de comunicación y a mi criterio no está en desuso. Lo que sí a perdido fuerza es la corriente de herramientas de generación de código a partir de diagramas UML. Hoy en día hay herramienta que continúan ofreciendo esas funcionalidad, pero sinceramente dudo mucho que alguien lo use.
Yo uso mucho UML, pero no necesariamente con herramientas de modelado, sino que lo uso como herramienta de comunicación, suelo hacer diagramas en una pizarra luego sacarles foto.
En cuanto a recursos de estudio de UML, Carlos Fontela escribió un libro que me parece bastante apropiado: http://www.casadellibro.com/libro-uml-modelado-de-software-para-profesionales-recursos-para-profes-ionales-de-sistemas/9788426717955/1969451