Sastres y emperadores
Esto se va animando: Nico Aragón ha respondido al artículo ¿Está desnudo el emperador? en su propio blog:
Nico es una de esas personas brillantes que impresiona ver trabajar, y la respuesta tiene enjundia suficiente como para llevarla a "portada". Luego repasaré los comentarios a mi propio artículo porque creo haber visto algunos enlaces interesantes a otras páginas, y de paso añadiré los enlaces a las bitácoras de las personas involucradas (¡un saludo a todos!).
Lo bueno de este tipo de discusiones es que te obliga a refinar tu postura o tu opinión. Confieso que me gusta tirar por elevación, llevando primero el asunto a un extremo: ¿y si X fuese mentira? Claro, este sistema exige que a continuación se corrija la puntería. Si se me ocurre alguna respuesta que aporte algo diferente, naturalmente, la publicaré.
Ian Marteens, 12:09 p. m.
38 Comments:
Yo no veo ninguna substancia en la publicación de Nico. Hay partes que son un verdadero galimatías, como lo de los autómatas.
http://en.wikipedia.org/wiki/Technobabble
Todos sabemos que hay herramientas UML pero ¿Y que? ¿Nos hacen ganar algo o son otro engañabobos más?
Lo bueno de este tipo de discusiones es que te obliga a refinar tu postura o tu opinión.
Totalmente de acuerdo. A veces hay que radicalizar posturas para poder destilar el mejor conocimiento.
Siempre hace falta alguien que haga de abogado del diablo y que origine una discusión enriquecedora para todos. En esto Ian eres un maestro, el Sócrates de la programación :-)
Saludos.
Yo pensaba que el abogado del diablo era Nico. El prestigio de UML no es precisamente alto.
Aquí va otro artículo que lo critica:
Use Cases Considered Harmful
Alfredo,
Como bién sabes, en UML hay diferentes diagramas y formas de expresar el funcionamiento de los procesos y sus participantes, y entre ellos, estoy de acuerdo en que el de casos de uso tiene un bajo poder semántico.
Creo que las críticas a UML(que no digo que no tengan base) que estais comentando, son fruto de considerar UML únicamente como una herramienta más de desarrollo.
UML tiene otras muchas partes y diagramas que son muy útiles en diferentes ámbitos (Diagramas de clase, de secuencia,...). No solo cuando estamos desarrollando un sistema de información. También es útil para explicar o documentar conceptos de arquitecturas de sistemas (por ejemplo, cuando se explican patrones arquitectónicos como Broker o Proxy), como lenguaje común entre diferentes equipos de trabajo o incluso para expresar ideas que no tienen que ser precisamente un sistema de información.
Y esto creo que no sólo vale para UML... Por desgracia, creo que no existe ninguna metodología que sea capaz de : partiendo del nivel de abstracción más alto, tener suficiente poder semántico para llegar a expresar todo, hasta el último y más pequeño de los detalles de la implementación.
Quizá siempre habrá un gap entre la idea y su implementación. Otro cantar es cuan grande sea este gap y el grado de esfuerzo necesario para superarlo.
Antes que nada muchísimas gracias a Ian por los exagerados elogios.
Alfredo, debo haberme expresado mal, pero ahora te lo digo más claro: cada cuál usa lo que mejor le cuadra según su experiencia y su circunstancia.
Respecto a si hacen ganar algo, claro que sí. Yo francamente no sé qué esperas que te resuelvan, quizás estás confundiendo su objetivo. Ahora que lo pienso, creo que no tienes ninguna experiencia en un proyecto real con UML ¿Me equivoco?
Los libros a veces exageran, pero el estándar está ahí, las herramientas están ahí y funcionan cuando se usan juiciosamente.
Respecto a lo de los autómatas: decía Ian que la descomposición pasa de funcional a basarse en clasificación. Lo que quería decir, que por lo visto no se entendió, es que los objetos también encapsulan procesos, funcionando como una máquina de estados.
A menudo se cita como un vicio a la hora de diseñar las clases hacer que todas las clases representen procesos, sobre todo porque indica una mentalidad muy propia de la programación estructurada. Pero eso no quiere decir que no haya objetos activos.
Ninguno de los diagramas de UML llega a tener un poder semántico mediano, pero las críticas más fuertes que se le hacen a UML desde el mundo académico son por falta de claridad, precisión y sobre todo consistencia. Si UML es tan bueno ¿Por que no son capaces de describirlo de una forma mínimamente clara?
Los casos de uso son una de las partes más débiles de UML, pero las demás tampoco salen muy bien paradas. Yo creo que los diagramas de secuencia y las tarjetas CRC están muy cerca en inutilidad y poco uso. Bueno, lo de las tarjetas creo que es aun más ridículo :)
Los diagramas de clases heredan los problemas de los originales diagramas ER como por ejemplo la arbitraria distinción entre entidad y relación. En los lenguajes lógicos todo son relaciones.
Lo peor de todo es cuando se genera código automáticamente a partir de un diagrama de clases conceptual.
Para mi está claro que los defectos de UML no hacen ningún bien cuando se usa UML para otras cosas que no son el desarrollo de software.
Un lenguaje de modelado no tiene que describir todos los detalles, por que sino sería un lenguaje de implementación. El problema es que se ha vendido UML como una metodología universal cuando no es más que una notación gráfica muy poco expresiva e inconsistente que en la mayoría de los casos prácticos a demostrado aportar muy poca utilidad.
Existen otros lenguajes de modelado mucho más potentes y mejor definidos como por ejemplo Alloy y ORM.
Mizar, para ser más concreto: yo les veo dos utilidades principales. Una es la de documentar el análisis y los requisitos. La otra es la de generar esqueletos de código. ModelMaker es bueno para las dos cosas, y además es programable.
Pero incluso con programas gratuitos como Dia, se pueden hacer cosas interesantes. Exporta los diagramas a XML y puedes leerlos por programa para, por ejemplo, generar el SQL de la base de datos. A otros les gusta Visio.
Sobre la existencia de ejemplos, ¿qué tipo de ejemplo te gustaría ver?
Lo malo de los ejemplos sencillos es que no justifican unas herramientas que son mejores para mastodontes.
Cada uno usa lo que le cuadra es una forma de negar la posibilidad de discutir sobre el valor de las técnicas de desarrollo de software en base a criterios racionales y contrastables.
Es cierto que el desarrollo de software es una disciplina poco formal, pero lo que hay que hacer es aprovechar al máximo los pocos principios científicos de los que disponemos en lugar de hacer todo lo contrario.
La experiencia sirve de muy poco si no está basada en el conocimiento. Por otra parte, el conocimiento y la capacidad de razonamiento abstracto ayudan a evitar malas experiencias innecesarias.
Y te equivocas en lo de que no tengo experiencia con UML en proyectos reales.
Decir que las herramientas UML funcionan cuando se usan juiciosamente es como no decir nada. Aquí nadie ha negado totalmente la utilidad de UML, lo que se discute es si nos están vendiendo una chorrada como si fuese la gran cosa, y todo apunta a que si.
Alfredo, tus "criterios racionales y contrastables" ya me los conozco. Básicamente consisten en que tú llevas razón, los demás no sabemos nada y dedicas varias horas al día a "demostrarlo" escribiendo comentario tras comentarios en el foro de turno hasta que los demás nos cansamos y nos dedicamos a actividades más productivas.
A mí me parece conveniente saber UML. Pero me parece mucho más importante saber trabajar con otras personas, pues de poco vale una herramienta de comunicación cuando las personas son incapaces de comunicarse.
Tengo mi particular galería de héroes, en la que destacan compañeros a los que he visto poner en marcha equipos de gente y un sistema con lo que tenían a mano, de forma que todo parecía surgir de forma natural.
Es la gente en la que me fijo y a la que escucho en estos temas, gente que ha hecho algo "contrastable" para mí.
Tú lo que me has demostrado es que eres un kamikaze. Para mí no eres "contrastable". Es muy fácil coger lo que dice otro y hacer crítica destructiva (mira qué bien le va a Losantos), pero es mucho más difícil construir.
Que fácilmente pierden los papeles los anti-intelectuales cuando alguien les rebate.
Calma. Pax vobiscum... que son "sólo" temas técnicos (menos mal que no es "furbo" o política).
Nico: más que UML, el problema que me preocupa, porque lo veo venir, es la viabilidad o conveniencia de lo que en castellano antiguo llaman persistence frameworks. Me explico: escribir una aplicación partiendo de clases como Cliente, Factura, Producto, luego definir la forma en que éstas se leen de una base de datos y la actualizan cuando se producen cambios. Es decir: tirar los datasets por la borda.
Me preocupa por lo siguiente:
1- He dado soporte a un par de proyectos grandes diseñados en esta línea, y es jodidísimo mantener este tipo de tinglados. No digo ahora por qué para no extenderme demasiado.
2- ¿Qué métodos tendría una clase Cliente? Aparte de las validaciones básicas, claro... Todo lo "interesante" en una BBDD ocurre en un nivel superior al de clase/instancia.
3- Este enfoque, naturalmente, funciona bien con poca carga. Cuando las cosas se ponen alegres, es una pesadilla.
4- Hay una tendencia en .NET a moverse en esta línea, probablemente con la oposición de Hejlsberg (hay un artículo en Artima en el que habla del asunto). Al final, ObjectSpaces se canceló... pero en beneficio de lo que LINQ pueda traer.
Más en general me preocupa otro problema: hasta el 93, más o menos, participé en un grupo de investigación sobre BBDD orientadas a objetos. No soy un profano en la materia, y he seguido los "avances" en este frente. Sin embargo, las OODB no acaban de cuajar: creo que es un hecho objetivo. ¿Por qué? Mi impresión es que, cuando se trata de grandes sistemas en red, el modelo relacional lleva ventaja, por estar basado en valores, en contraste con el concepto de identidad en las OODB. De hecho, el concepto Service Oriented de Indigo es una confirmación de que el modelo clásico OO tiene problemas en este tipo de redes.
La preocupación, además, no tiene que ver tanto con la programación o la docencia del día a día. Mi interés en Freya es como trampolín: en realidad estoy apuntando a un proyecto más ambicioso de bases de datos orientadas a objetos (Avatar).
Sí... que haya paz !
.. con tanta opinión y contraopinión quizás tendremos que dibujar un diagrama de secuencia para representar este post :-))
Ian,
esto de tu aversión hacia las persistence frameworks ya te lo he leído un par de veces.
Podrías aclararnos tus reticencias y porqué consideras que pueden ser tan perjudiciales (quizá en un post específico) ?
Supongo que tiene que ver con la dificultad de gestionar las instancias de las clases...
Saludos.
Decía Ian sobre los ¿"motores de persistencia"? que:
1- He dado soporte a un par de proyectos grandes diseñados en esta línea, y es jodidísimo mantener este tipo de tinglados.
¿Comparados con qué? Cuando tienes una aplicación de medio millón de líneas con el SQL regado por todo el código, estás jodido. Simplemente agrupar las llamadas a base de datos como métodos de un objeto te permite localizar cambios de forma más rápida.
Otra cosa es que quieras basar todo el programa en una plataforma generalista. Es muy difícil hacer algo así, sobre todo con el tipo de lenguajes que usamos. Ninguno de los productos que salieron para Delphi han tenido un éxito notable.
2- ¿Qué métodos tendría una clase Cliente? Aparte de las validaciones básicas, claro... Todo lo "interesante" en una BBDD ocurre en un nivel superior al de clase/instancia.
Si pudieras escribir toda la lógica en un mismo sitio, ¿te seguiría pareciendo difícil de mantener?
El problema que yo veo es que el código se tiene que repartir entre la base de datos, la lógica de negocio y la interfaz de usuario, en cada sitio posiblemente con un lenguaje distinto. Hacer eso con una librería es... complicadillo.
A mí lo que me gustaría tener es un catálogo completo con una interfaz decente... y única. Una interfaz que se encargase de generar el código necesario para todas las capas del programa, desde el JavaScript a los triggers.
Lo primero que hay que distinguir es entre sistema de información y aplicaciones. Un sistema de información debe de estar compuesto de un sistema de gestión de bases de datos engargado de gestionar la lógica de negocio y un conjunto de aplicaciones dedicadas a la presentación y comunicacion. Este es un patrón fundamental conocido desde los años 60.
Los marcos de persistencia son un desastre por que nos llevan a implementar las reglas de negocio en las aplicaciones de forma procedimental utilizando el modelo de red, o en el mejor de los casos nos llevan a creanos nuestro propio sistema de gestión de bases de datos de propósito específico basado también en el modelo de red. El resultado es que lo que antes era fácil se vuelve muy dificil y el rendimiento es pobre.
Como dice Ian, los datos deben de gestionarse desde un nivel de abstracción superior al de la clase: el de la relación.
Las bases de datos de objetos no solo no terminan de cuajar sino que han sido completamente barridas del panorama. La razón fundamental de su fracaso es que heredan casi todos los problemas de las bases de datos de red. Básicamente son bases de datos de red con características OO. Lo que está triunfando es integrar las características OO en las bases de datos relacionales, algo que debió de haberse hecho desde el primer día. En lugar de añadirle características OO a algo muerto mejor hacerlo con algo vivo.
Por cierto, escribir esto no me ha llevado ni 5 minutos :)
Hombre, en cinco años que llevas repitiendo la misma milonga, ya habrás tenido tiempo de apreder a soltarla instantáneamente.
El problema de ese discurso es que no aporta nada. Los proyectos que estás creando para tu trabajo deben ser realmente maravillosos y fantásticos, pero aunque nos lo recuerdes cada día por Internet, a los demás nos trae al pairo, pues no vemos más que el trailer. Lo mismo pasa con los superchachiguais y supercarísimososea productos de lujo que venden las cuatro empresas que tambien saben más que nadie y que no usa ni dios.
Me darías una sorpresa agradable (de veras) si llegases a sacar algo útil que la gente quiera comprar o por lo menos descargarse. Hasta ahora lo único que hemos visto es que se te va toda la fuerza por la boca, hablando de lo que vas a hacer y cómo todo lo demás contamina los Preciosos Fluidos Corporales.
Ostras Pedrin, cómo se está poniendo el patio... o_o'
Esto se parece ya a los foros de Meristation xDD
¡Bah! que provoque lo que quiera, yo desde luego no me pienso bajar a su nivel. Algunos se descalifican por si solos.
sharq, por favor lee el primer comentario de esta historia: "ninguna sustancia", "galimatías", "technobabble", "engañabobos"... después sigue, pero no está mal para abrir boca.
Conocí a Alfredo en el trabajo y nunca tuvimos ni un roce, al revés. Ni siquiera me parecen mal sus ideas, con las que coincido en buena parte.
El problema es que este hombre lleva años reventando cualquier debate sobre diseño orientado a objetos en distintos foros de programación, empezando en el grupo de noticias de Borland delphi.oodesign y varias listas de correo y grupos de usenet.
El modus operandi es sencillo: cada vez que se menciona algo sobre diseño orientado a objetos aparece insultando, diciendo que la única teoría buena es una supuesta ortodoxia relacional y que todo el que lo ponga en duda es un ignorante anticientífico, antiintelectual y no sé cuántas cosas más.
Esto, aparte de la evidencia de este mismo hilo, lo puedes comprobar fácilmente yendo a la búsqueda avanzada de usenet en Google. Mete "Alfredo Novoa" en la casilla de autor y te van a aparecer más de mil mensajes con los que te puedes entretener cinco minutos o más.
Alfredo tiene todo el derecho del mundo a expresar su opinión. Pero los demás también tenemos derecho a expresar la nuestra sin que venga una persona con esos modales de matón a reventar cualquier diálogo.
Y no te dejes engañar por sus apelaciones a "debates racionales". Alfredo parte de las conclusiones y después se apoya en las falacias lógicas más peregrinas para saltar de verdades obvias a afirmaciones arbitrarias. En todo este tiempo le han refutado punto por punto sus supuestas verdades inmutables, hasta llegar al vapuleo, en diversos foros. ¿Pero de qué sirve? Al rato lo tienes otra vez sosteniendo la misma mezcla de obviedades y disparates.
Ahora puedes decir que soy un follonero si quieres.
Cuando tienes una aplicación de medio millón de líneas con el SQL regado por todo el código, estás jodido. Simplemente agrupar las llamadas a base de datos como métodos de un objeto te permite localizar cambios de forma más rápida.
Probablemente ahí esté una de las respuestas. ¿Es bueno concentrar ese código en un mismo sitio... en este caso particular? Ocurre que:
1- No corresponde a la clase Cliente encapsular consultas. La Cliente, en un "motor de persistencia", se convierte por lo general en una clase inerte, que simplemente aporta la información estructural. Es una tontería tener que escribir estas clases a mano, y si delego esa tarea en una herramienta, ya me da lo mismo si me dan una clase "limpia" que si me dan un tipo de dataset y un tipo de fila trucado, al estilo .NET.
2- Esto es más radical (para no decir "profundo"): no todo en esta vida es "encapsulable". ¿Se puede encapsular el manejo de excepciones? No hay nada más inútil que el Exception Handling Application Block de Microsoft. El nombre es más largo que la descripción de lo que verdaderamente hace. Los lenguajes han terminado por incorporar instrucciones especiales para el manejo de excepciones (errores, en su planteamiento original), pero es un hecho que se trata de una tarea asociada al código que no se puede centralizar por su propia definición. Lo mismo pasa con el control de transacciones... si se quiere hacer bien. Se pueden inventar truquillos OOP, pero sólo resuelven una parte del asunto y muchas veces son caros. El problema del control de transacciones, para quien no lo vea claro, es que no sabes en qué posición va a quedar un método tuyo en una composición modular determinada: uno normalmente debe trabajar con la "reutilizabilidad" en mente, y eso implica no saber con certeza quién va a llamar tus métodos. ¿Debe mi método iniciar y cerrar una transacción? ¿O debe sumarse a una ya existente?
No me entendáis mal: la encapsulación es algo cojonudo. Pero llevamos tanto tiempo "encapsulando", que sólo tenemos ojos para las cosas que podemos encapsular. Es como el refrán del dedo que apunta a la Luna: somos tan sabios que, efectivamente, miramos a la Luna, que es la moraleja oficial del refrán. Sin embargo, solemos olvidarnos del dedo.
3- En cualquier modo, en el caso particular de las aplicaciones de bases de datos, el problema fundamental es otro: mi empresa exige que sus clientes sean mayores de edad. ¿Debo convertir este requisito en una validación e implementarlo en la clase Cliente? Mi respuesta es NO, y estoy seguro completa y definitivamente de ello. ¿Por qué? Pues porque una regla de negocio no debe "soldarse" en el código. Volviendo a lo de antes: las consultas no deben soldarse en el código (y, además, no estoy seguro de que deban encapsularse en el código de una entidad determinada: en realidad, la consulta va asociada a una "función" del programa, no a una "entidad").
Por ejemplo, ahora mismo en las recomendaciones de Microsoft (los patterns and nomeacuerdo), se dice muy claramente que la interfaz de un módulo de capa intermedia no puede ser "genérica". No puede haber un método remoto llamado EjecutaEstaConsulta. ¿Por qué? Pues porque dicen que es un contrato muy "ancho". Debemos programar un RecuperaClientes y un RecuperaProductos, y así sucesivamente.
¿El problema? Que eso lo ha escrito un programador, no un empresario. Cada vez que haya un cambio mínimo en la aplicación, habrá que echar mano del mismo programador que diseñó la aplicación para que añada el nuevo canal de comunicación. Ese tío ha logrado asegurarse un puesto de trabajo per secula seculorom (amén). Ese tío acaba de colgarle un peso enorme al cuello de la empresa para la que trabaja. Ese tío acaba de complicarse la vida, porque difícilmente podrá sacar tiempo para programar esa idea genial que tiene en mente desde hace años. Estas consecuencias "sociales" son fáciles de ver, pero me tomo las molestias de explicarlas por si las moscas.
Por supuesto, podemos "reificar" (eso fue inicialmente Filosofía) las consultas, y crear clases, y volver a aplicar la metodología Object Oriented... pero en realidad, la OO se está usando aquí como usamos el lenguaje ensamblador... o como el compilador normalmente usa el código nativo.
¿Es UML el metalenguaje requerido, entonces? ... porque he reintroducido un nivel de abstracción superior al de la OOP, aparentemente. La respuesta también es NO. UML es Object Oriented, en definitiva. No despega lo suficientemente del suelo para ser realmente útil. Más bien, no se despega nada del nivel de abstracción que sirve para su implementación. Es como implementar Freya mediante un compilador que traduce de Freya a C#. ¿Qué se ganaría? Nada: desvestir un santo para vestir a otro.
Sobre ideas y discusiones: repito, esto no es un consejo de vecinos, recordadlo. Si se impone una idea mala en un consejo de vecinos, el edificio completo la tiene que sufrir. En política, si la gente compra una mala idea, tienes cuatro años (un poco más si eres francés, y puede que toda la vida si la idea es verdaderamente perversa) de sufrimientos.
Pero esto es Informática: si alguien compra una idea mala, sólo fastidia al subárbol del que es el nodo raíz. Es decir, si eres jefe de departamento, puede que jodas a tus subordinados... pero para eso hay un mercado laboral, y la mejor oportunidad está siempre por delante.
Es verdad que lo del "galimatías" parece ad hominem, pero poco antes yo mismo había hablado de "reduccionismo", y mirándolo desde algún ángulo podría incluso parecer un insulto. No lo era.
Please. S'il vouz plait. Si us plau. Bitte. Pozhalusta (eso era ruso)... usad una técnica muy sencilla: insultad la idea. Las personas son sagradas. Las ideas no. En un mundo ideal quizás no habría que insultar nada... pero sería muy aburrido. A mí me gusta insultar. Estoy largando este sermón sólo porque soy el anfitrión y es mi obligación. Como insultar es de humanos (ya se lo dijo Homer Simpson a Flanders), desviad el destino del insulto, como hago yo normalmente. "Tú" (quien sea el "tú") eres un tipo cojonudo, pero te ha poseído una idea tonta. Sé que eres listo y te darás cuenta lo antes posible. Ah, era yo el equivocado. Lo siento. Canto la palinodia y me como la gorra. Ah, tenía razón yo... pues qué satisfacción.
Esto es un puesto ambulante de ideas. Habrá buenas ideas, ideas regulares e ideas estupendas. También hay una barraca para los fenómenos de feria. Ahí, mientras más extravagantes, mucho mejor. Me gusta de vez en cuando soltar una de esas ideas raras, y ver cuánto aguanta en la atmósfera terrestre. Esto funciona, por supuesto, si asumimos que la gente no es tonta. Nadie va a comprarse la "mujer barbuda", ¿o sí? Bueno, en cualquier caso, es su dinero.
:) Y ahora, por supuesto, haced lo que os dé vuestras reales ganas. Pero era mi obligación escribir esto.
Ian,
Perdona por el follón, te aseguro que no he entrado con esa intención. Por mí, si el blogger te lo permite, borra mis últimos comentarios. Realmente es mala idea salirse al terreno personal. La próxima vez respiraré unas cuantas veces hondo antes de contestar :-(
Ahora contesto a lo técnico.
Tranqui: no he mencionado nombres. A veces lo injusto es tratar a todo el mundo por igual, pero no me voy a poner a avivar el fuego. Además, yo tampoco soy un santo. Y para remachar, este tipo de discusiones son muy buenas para la publicidad.
Y aparte de esto, mientras sea posible, intentaré no borrar nunca un comentario (mientras no se trate de una repetición).
Galimatías no es ad hominem, y reduccionismo tampoco. Eres un kamikaze si es ad hominem.
Probablemente ahí esté una de las respuestas. ¿Es bueno concentrar ese código en un mismo sitio... en este caso
particular? Ocurre que:
1- No corresponde a la clase Cliente encapsular consultas. La Cliente, en un "motor de persistencia", se convierte por lo general en una clase inerte, que simplemente aporta la información estructural. Es una tontería tener que escribir estas clases a mano, y si delego esa tarea en una herramienta, ya me da lo mismo si me dan una clase "limpia" que si me dan un tipo de dataset y un tipo de fila trucado, al estilo .NET.
No sé si me dices que la clase cliente puede encapsular consultas o que no. Yo he trabajado así siempre.
2 [...] problema del control de transacciones, para quien no lo vea claro, es que no sabes en qué posición va a quedar un método tuyo en una composición modular determinada: uno normalmente debe trabajar con la "reutilizabilidad" en mente, y eso implica no saber con certeza quién va a llamar tus métodos. ¿Debe mi método iniciar y cerrar una transacción? ¿O debe sumarse a una ya existente?
Lo más limpio es sumarse a una transacción existente. La implementación más natural es con un bloque de control de excepciones con algo como try op1;op2;op3;commit except rollback;raise end. Si una operación se hace siempre en solitario habría que meter el bloque try dentro o pasar por el coñazo de llamarla siempre con un bloque o hacer algún tipo de macro.
3- En cualquier modo, en el caso particular de las aplicaciones de bases de datos, el problema fundamental es otro:
mi empresa exige que sus clientes sean mayores de edad. ¿Debo convertir este requisito en una validación e implementarlo en la clase Cliente? Mi respuesta es NO, y estoy seguro completa y definitivamente de ello. ¿Por qué?
Pues porque una regla de negocio no debe "soldarse" en el código.
En un programa web la regla de negocio suele estar "soldada" en varios sitios. En la base de datos, en el CGI (o equivalente) y en el JavaScript de la página que contiene el formulario. Lo pueden tomar también de metadatos que guardes en algún sitio, por ejemplo la base de datos o un fichero DFM para el caso.
Volviendo a lo de antes: las consultas no deben
soldarse en el código (y, además, no estoy seguro de que deban encapsularse en el código de una entidad determinada: en realidad, la consulta va asociada a una "función" del programa, no a una "entidad").
¿Y un método no es una función? Una función asociada a una entidad.
Por ejemplo, ahora mismo en las recomendaciones de Microsoft (los patterns and nomeacuerdo), se dice muy claramente que la interfaz de un módulo de capa intermedia no puede ser "genérica".
¿Y a quién se le ocurre leer recomendaciones de Microsoft? :-)
Por lo que leo... el problema es que buscas un nivel superior para todo. Eso es facilísimo. Define un "top-level" de la aplicación en forma interactiva. Es la última novedad ;-)
:) Depende del "homo". Ya sé que "reduccionista" no es insulto, sobre todo porque no lo usé en mal sentido. Era un intento de apaciguar los ánimos repartiendo las culpas por igual. Todos sois bienvenidos. Muchas veces incluso se aprende más de quien piensa radicalmente diferente de uno mismo. Si montamos lo del grupo de usuario, vamos a crear una sección o puede que un concurso, para La Idea Más Estrafalaria (reservándonos el derecho de declarar desierto el premio si es necesario).
Ya que insiste en jugar a esto pues juguemos.
Parece que para Nico decir algo con lo que él no está de acuerdo es reventar un debate, y que no sabe defender una postura sin recurrir a los ataques ad hominem. Habla de cosas sobre las que no tiene ni idea como de bases de datos o del número de programas que vende otra persona. Sus argumentos en este hilo no merecen tal nombre y se resumen bien en lo de que cada uno haga lo que le cuadre que total todo da igual sobre todo si se tiene tanta experiencia como él.
A mi me tuvo engañado bastante tiempo y parece que a otros aun les tiene engañados. Ha memorizado unas cuantas retahílas pseudo técnicas que ha leído en publicaciones de baja calidad, y al principio da el pego. Pero en cuanto rascas un poco la superficie ves que no hay nada más que cuatro recetas de cocina memorizadas y mucho morro.
Niega que la informática deba de acercase a la ciencia y según él las matemáticas no sirven para nada por que no es capaz de comprenderlas ni de encadenar un razonamiento abstracto. Para él todo se basa la experiencia y en aporrear el teclado a lo loco. Conozco gente con una amplísima experiencia en hacer las cosas mal, y eso no les convierte en modelos a seguir.
Me ha demostrado en numerosas ocasiones que es una persona profundamente anti intelectual y que está completamente cerrado a aprender nada nuevo. Cuando nuestro antiguo jefe de departamento le decía delicadamente que tenía lagunas en su formación no sabía ni de lo que le estaban hablando.
En este tiempo en el que contribuyo de vez en cuando en diversos foros y listas de correo, nadie ha conseguido refutar el núcleo de mi posición, que no es ni más ni menos que la posición mayoritaria dentro de los investigadores y expertos en sistemas de bases de datos, que casualmente son los que más entienden sobre sistemas de bases de datos. Cuando hablo con algunos de ellos casi nos aburrimos de lo acuerdo que estamos.
Por cierto, mil mensajes en seis años da una media de menos de medio mensaje diario, y la mayoría son muy cortitos (debería de escribir más por que es algo muy enriquecedor). Me paso el día pegado al ordenador escribiendo código y no fumo ni bebo café, así que en los descansos de cada hora me gusta echarle un vistacillo a páginas o foros de programación, y cuando veo a alguien que va a cometer un error le intento avisar, no veo nada malo en ello. También hago lo mismo algunas veces cuando veo que alguien está perjudicando a otros difundiendo información errónea o engañosa. Si quisiera hacerlo siempre no me llegarían las horas del día.
Por ejemplo creo que Ian cometería un grave error si intenta desarrollar un SGBD de objetos o un marco de persistencia y lo digo de corazón, a Ian de momento no le tengo ninguna manía :)
Hace años que he perdido casi todo el interés por la OO. Me parece un campo estéril, que ya no da para más y que se domina muy fácilmente. Así que si alguien se quiere entretener cinco minutos leyendo mis mensajes mejor que busque en comp.databases.theory.
Allí mis opiniones coinciden con las de la mayoría. Otra lectura muy recomendable es dbdebunk . Allí no escribo pero estoy de acuerdo en un 99,98% de lo que dicen sobre bases datos y OO. En mi opinión es la mejor página sobre bases de datos con diferencia y una de las mejores sobre desarrollo de software en general.
También intercambio correspondencia regularmente (privada y en listas de correo) con expertos en bases de datos de primerísima fila internacional, y en ocasiones me piden su opinión antes de publicar o me regalan sus libros. Esto es algo en lo que no llevo demasiado tiempo y quiero profundizar. Es realmente enriquecedor tratar con esta gente de una formación exquisita y que estaban allí cuando se inventó todo.
Vaya, me salió mal el enlace:
www.dbdebunk.com
El jefe tiene muy mala leche, pero es una de las mentes más claras del mundo del software
Alfredo, para,, para,,, para,,,, ya no más.
Ya lo dijo Ian en un post anterior insulta las ideas no a las personas.
Eso después de ponernos a la par
Es curioso. El jefe de departamento mencionado nos hizo tomar un curso sobre análisis y diseño orientado a objetos.
Después encargó a un compañero que elaborase un nueva norma de desarrollo para el departamento, precisamente la que introdujo UML y el uso de Together.
Alfredo: he estado mirando lo de dbdebunk. ¿Les has comprado artículos? Porque por lo visto, esta gente no abre la boca si no arrimas la billetera, y no precisamente para que no le entren moscas.
¿Hay algún otro sitio donde expliquen de qué va su teoría ultramegachachi-relacional? Me parece bien que cobren por su trabajo, que de eso también vive uno, pero la verdad es que eso de pagar primero para enterarme luego me parece más cosa de cienciólogos que de científicos.
Ian, en dbdebunk tienen muchos artículos en "abierto" aunque son un poco difíciles de encontrar. Lo de cobrar lo hacen desde hace unos pocos años. A mi me parece perfectamente razonable que cobren por sus artículos, tu también cobras por tus cursos, aunque también me parecen muy caros (los artículos de dbdebunk, no tus cursos :).
Lo normal es que los liberen dentro de unos años.
Si que les he comprado bastantes, pero allí no explican la base de su modelo ultramegachachi-relacional o relacional a secas, eso está en los libros. Los artículos normalmente son sobre temas puntuales.
Yo tengo todos sus artículos (libres) de allí y otras webs coleccionados en formato Word, al que quiera se los mando.
En http://www.thethirdmanifesto.com/
tienes algo de material y te puedes apuntar a la lista de correo para preguntar lo que quieras, pero no creo que se pueda comprender bien sin leer el libro entero.
Si quieres hasta te regalo mi copia de la segunda edición, que es casi igual a la tercera (la tercera me la regaló Darwen), y de paso le repito a Nico que le devuelvo sus libros cuando quiera :-)
Una cosa: Estaba ahora mismo intentando entrar al blog de Nico, y la URL de "espira.net" ahora apunta a un registrador de dominios... Qué ha pasao? :-?
(Alfredo macho te has pasao... eso del sabotaje está mu feo xDDDDDDD)
¡Madre mía! Es verdad. Estoy ahora en la red de Ono (lo digo por si la culpa es de algún servidor DNS al que se la ha ido la olla).
Yo no fui :)
Gracias por el aviso. Los del registro tienen algún problema con la tarjeta y han suspendido el servicio para "que no se me olvide" :-)
No me había fijado en el icono de sharq... yo aprendí a programar con uno de esos (16 kb).
Publicar un comentario
<< Home