Objetos Relevantes versus Arquitectura Espuma
Leo la siguiente opinion sobre iterar y despues de releer los comentarios varias veces, y volviendo a los conceptos que estudie, os recuerdo que cuando yo estudiaba la programacion orientada a objetos no era fundamental como ahora. Habia dos procesos separados por una fina linea, el analisis y el diseño. El analisis era el trabajo con los conceptos de negocio y el diseño era la implementacion de esos conceptos de negocio, y ambos eran susceptibles de iterar, sobre todo por que hay pequeñas "chapuzas" de implementacion o "pos ya que" del cliente que modifican el trabajo de analisis y diseño. El primer gran proyecto que aborde como analista, ha pesar de mi nula experiencia, fue un proyecto orientado a objetos, y el analisis inicial fue definir cualquier entidad como objeto, independiente de la relevancia que tuviera en el sistema, ademas tratamos la base de datos relacional como una base de datos orientada a objetos. Para colmo no existia hibernate, POJOs ni EJBs ... la complejidad del sistema crecio exponencialmente conforme se añadian funcionalidades nuevas se hizo inmantenible, la verdad es que funcionalmente era un pequeño proyecto pero la arquitectura diseñada era como la espuma cuanta mas agua mas crecia. La empresa en la que trabajaba trajo a un "guru" de programacion orientada a objetos para minimizar el problema. Nos explico un nuevo concepto para mi, que lo tradujimos como "objetos relevantes" , en una aplicacion se deben definir como objetos solo aquellas entidades que son relevantes para el sistema, el analisis implica encontrar los objetos relevantes para la aplicacion a implementar, sobre los que se puede iterar sin problemas e incluso se pueden definir rapidamente los metodos publicos, aunque "dummy" para que el diseñador empieze a trabajar, este enfoque y el de que hay que trabajar con las personas del equipo son los principios sobre los que trabajo, y por suerte, no he vuelto a caer en un error del estilo de la arquitectura espuma Es muy importante aprender de los errores, aunque duela reconocerlos.
Posted at 01:28PM dic 09, 2007 by Batch for the Java TM in General | Comentarios[3]
Muy bueno!
Enviado por 201.208.215.109 en diciembre 09, 2007 a las 09:50 PM GMT+01:00 #
interesante, podrías hablar un poco más sobre el concepto de "objeto relevante"? no se si me ha quedado muy claro... objeto relevante al análisis? o al negocio?
Enviado por M4RC0 en diciembre 10, 2007 a las 10:39 AM GMT+01:00 #
Hay dos tipos de objetos relevantes, segun la fase en la que se este.
Si estamos en analisis son de negocio, si estamos en diseño son de arquitectura mas negocio, el saber que objetos son relevantes es lo mas dificil de la programacion orientada a objetos.
Enviado por batch4j en diciembre 10, 2007 a las 06:50 PM GMT+01:00 #