style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Rituales de Arquitectura y patrones: De la importancia de amarrar al gato - Once and Only Once Balances Yagni – Parte 1 SGCE2013

El maestro de zen y sus discípulos comenzaron su meditación de la tarde.El gato que vivía en el monasterio hacía tanto ruido que distrajo los monjes de su práctica, así que el maestro dio ordenes atar al gato durante toda la práctica de la tarde.
Cuando el maestro murió años más tarde, el gato continuó siendo atado durante la sesión de meditación. Y cuando, a la larga, el gato murió, otro gato fue traído al monasterio y fue atado durante las sesiones de práctica.
Siglos más tarde, eruditos descendientes del maestro de zen escribieron tratados sobre el profundo significado espiritual de atar un gato para la práctica de la meditación

Hace algunos años asistí a un evento que Sun organizo para promocionar Java aqui en Mexico (Java Dev Days creo que se llamaba). En aquel entonces entre a una presentacion, creo que era de Sang Shin (el creador de JavaPassion) en la que explicaba lo simple que era utilizar JRuby con Ruby on Rails para crear una pagina de “hola mundo”. Era algo mas o menos como este video: http://www.youtube.com/watch?v=sas3KCKwyHI. Era la primera vez que veia a RoR asi que por ese lado me parecio educativo… sin embargo, la mayor parte de audiencia… se estaba durmiendo!

Eso llamo mi atención… por que estaban todos tan aburridos, por lo que había podido observar los días anteriores, gran parte de ellos eran programadores empresariales, con el tipo de clientes que yo he tenido, de los que te dan bien poca información para trabajar, exigen muchísimo, y lo quieren todo para ayer…, así que empece a escuchar los comentarios que en voz baja (o no tan baja) intercambiaban entre bostezo y bostezo:

  • ¿Eso es simple? Se tardo como 15 minutos en hacer una pantalla de hola mundo!
  • Que aburrido, yo podria hacer eso con JSP es 1 minuto
  • De donde saca este compadre que eso es simple? Ya viste la mega estructura de directorio que esos comandos crearon? eso no tiene nada de simple!
  • Se nota que este presentador se la pasa dando cursos, pero nunca ha chambeado en la vida real, ya lo quisiera ver con su RoR teniendo que sacar la chamba a las 3 de la mañana

Al menos las 2 filas sentadas delante de mi no estaban ni remotamente impresionados con RoR. Y por que habrían de estarlo si en JSP se puede hacer un hello world con simplemente poner algo como esto:

<HTML>
 <HEAD>
  <TITLE>Hello World</TITLE>
 </HEAD>
 <BODY>
  <H1><%= "Hello World!"  %> </H1></BODY>
</HTML>

Ciertamente el argumentar que los 15 minutos del video de múltiples pasos son mas simples que esto, es un absurdo.

Ah bueno, diran algunos, (como pensaba una parte de mi) es que el chiste de el ejemplo con RoR no es mostrar los simple que es hacer un bobo “Hello World” si no mostrar el potencial que tiene la arquitectura MVC de RoR para hacer cosas mucho mas complejas…

A ver si entendí… ¿me estan diciendo que me voy a complicar la vida haciendo algo fácil mucho mas difícil y eso va a resultar en una simplificación de lo difícil? Mas complejidad hoy == Menos complejidad mañana? Eso viola YAGNI. (Yagni significa: No lo vas a necesitar)

Y no es que haya que evitar violar YAGNI no mas por seguir la tradición, como en el caso del gato en el monasterio. Yagni tiene una razón de ser: en el desarrollo de sistemas, el cambio es la única constante, y si te adelantas y construyes algo antes de tener bien claro si de verdad lo necesitas, cuando llegues al punto en que realmente lo vas a usar, es muy probable que lo que realmente necesitas termine siendo muy distinto de lo que habías predicho. Esto no significa que tu código no debe ser flexible, pero debes tener mucho cuidado, por que puedes terminar con una solución con sobreingenieria, lista para situaciones que nunca llegaran a ocurrir. Si consumes energía de mas hoy, peleando con los fantasmas de cosas que nunca llegaran, cuando por fin lleguen los enemigos reales, ya no tendrás fuerza para enfrentarte con ellos.

Ahora bien, uno de los grandes problemas que tenemos en el aprendizaje de la programación, es que cuando estamos aprendiendo, tenemos que construir ejemplos como un Hello World en RoR para entender como funciona. Pero como instructores, tenemos que tener mucho cuidado en decir “miren, con este ejemplo les voy a demostrar lo simple que es esto…”. No. No se hace un hello world en RoR por que sea simple. Evitemos confundir a nuestros alumnos. No vamos al gimnasio a sudar por que sea menos cansado que quedarnos en casa viendo la tele. Vamos por que al hacerlo mejoraremos nuestras habilidades, vamos para prepararnos para situaciones futuras. Asi pues, en programacion, no solo manda Yagni, tambien tenemos otro principio: OAOO. (OAOO significa, una y solo una vez).

OAOO es la causa raiz de la aparente complejidad de RoR, y el archienemigo del copy&paste. OAOO tiene otros nombres, se le conoce tambien com principio DRY (Do not repeat yourself: No te repitas). No es bueno tener copias del mismo codigo regadas por todo el proyecto, por que si hay un bug en alguna de ellas, y no seguiste OAOO, vas a tener que encontrarlas y corregirlas a todas, en vez de resolver el problema en un solo punto.

OAOO y YAGNI son como el Ying y el Yang. Se balancean. Sin OAOO, YAGNI lentamente nos estrangularía. Con OAOO, siempre tienes un sistema que puedes mejorar (frase de Ron Jeffries).

OAOO solito tambien nos mataria, llevandonos a un eterno refactorizado de codigo buscando el santo grial del código genérico de menor numero de líneas posibles sin detenernos jamás…

Necesitamos ambos. Necesitamos balance.

Cuantas veces se han enfrentado en su trabajo a codigo como este:

DAO:

    public List<Product> getProductList() {
        logger.info("Getting products!");
        List<Product> products = getSimpleJdbcTemplate().query(
                "select id, description, price from products",
                new ProductMapper());
        return products;
    }

Servicio:

    public List<Product> getListOfProducts() {
        logger.info("Getting products!");
        List<Product> products = getProductsDao().getProductList()
        return products;
    }

Controller:

    public List<Product> getProductsToList() {
        logger.info("Getting products!");
        List<Product> products = getProductsServices().getListOfProducts()
        return products;
    }

Que valor agrega esto? Por que no podemos simplemente hacerlo asi (nada de capa de Servicios, nada de capa de DAOs):

Controller:

    public List<Product> getProductsToList() {
        logger.info("Getting products!");
        List<Product> products = getSimpleJdbcTemplate().query(
                "select id, description, price from products",
                new ProductMapper());
        return products;
    }

Por que es que si no amarras al gato antes de meditar…. digo, por que es es que los principios de arquitectura multicapa dictan que asi se haga… ¿en serio? ¿en serio esa la respuesta? NO!

Si no satisface una necesidad inmediata y no ayuda a OAOO (obviamente la redundancia en esto no ayuda a OAOO) no debemos hacerlo. Estamos quemando tiempo y energía preciosos en  “busy work” que nadie nos va a agradecer.

Herejia! Me han dicho muchos cuando les digo que dejen de tener tanta capa nada mas por que si. Las capas son NECESARIAS. No puedes quitarlas.

Claro que puedes, y no soy el unico que lo piensa. JBoss Seam se diseño precisamente con la idea de eliminar tanta capa innecesaria. Y eso fue hace AÑOS. ¿Por que a la mayoria no “le ha caido el veinte” de que hacer capas por hacer capas no es correcto? ¿por que amarramos todavia al gato y compramos un nuevo gato cada vez que iniciamos un nuevo proyecto? Tradicion.

Ahora, las tradiciones no son todas malas, (aquellas culturas con tradiciones que no ayudan a su supervivencia sencillamente se extinguen) . De donde viene la idea de que poner tanta capa ayuda en algo?

De eso les hablare en mi siguiente post de esta serie…

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de Jose Manuel

Yo soy un programador

Yo soy un programador principiante/novato y en mis proyectos siempre utilizo esa estructura dao-service-controller (MVC), no digo que la implemente de la manera correcta pero la implemento. Y yo me preguntaba, ¿Por qué? Pero como soy un novice, me decía: "tu haz lo que ves". Y pues como yo veo que todos utilizan esta estructura pues ni modo chato.

Pero, ¿acaso no es propósito de los patrones de diseño dar una estructura genérica para solucionar problemas comunes? ¿No se pierde la versatilidad al no usar los patrones? Digo, por ejemplo; los DAOs nos permiten la independencia con una base de datos en especifico... Osea, ademas de ser soluciones a problemas comunes los patrones de diseño también son buenas practicas, no?

¿No se pierde todo esto al simplemente crear una aplicación de 1 capa? ¿No va en contra de los preceptos de la programación? Ahora sí que desobedeces al orden superior, ser rebelde es bueno también jaja. Muy interesante tu post.
Saludos.

Imagen de luxspes

Pero ¿que no es muy importante amarrar bien al gato?

Yo soy un programador principiante/novato y en mis proyectos siempre utilizo esa estructura dao-service-controller (MVC),

Mmmm, no se si te estoy entendiendo bien, pero dao-service-controller no es MVC (model-view-controller). Checa aqui la diferencia

no digo que la implemente de la manera correcta pero la implemento.

Traduccion: No digo que amarrar al gato sirva para algo... pero lo amarro ;-)

Y yo me preguntaba, ¿Por qué? Pero como soy un novice, me decía: "tu haz lo que ves". Y pues como yo veo que todos utilizan esta estructura pues ni modo chato.

Traduccion: Y yo me preguntaba, ¿Por qué? Pero como soy un novice, me decía: "tu haz lo que ves". Y pues como yo veo que todos amarran al gato pues ni modo chato.

Pero, ¿acaso no es propósito de los patrones de diseño dar una estructura genérica para solucionar problemas comunes?

Si, eso podria decirse.

¿No se pierde la versatilidad al no usar los patrones?

Si, se pierde, pero la versatilidad tiene costo, y si ese costo supera al valor que ofreces, no vale la pena.

Digo, por ejemplo; los DAOs nos permiten la independencia con una base de datos en especifico...

Yo, en 13 años dedicandome a esto, nunca he tenido el caso de que me digan a medio desarrollo: Esto ya no va a ser en SQLServer, va a ser en Oracle: ¿tu si? ¿que tan frecuentemente te pasa? Y en caso de que pase, seria un "change request" ¿quieres que ahora corra en otra base de datos? Sin problema, te cuesta esto: $,$$$,$$$.

Digo, claro que algo como los DAOS hace mucho sentido si estas armando un "sistema de caja" que vas a vender para muchos clientes, los cuales no sabes que bases de datos usarán. En ese caso, la versatilidad se paga con tu acceso a mas clientes en el mercado. Pero si estas haciendo una solucion custom, para un solo cliente ¿que caso tiene?

Y por otro lado, JPA/Hibernate ya se encarga mediante sus "dialects" de hacer que tu codigo sea automaticamente "multi-base de datos" ¿para que cansarte entonces con DAOs si usas JPA/Hibernate? ( ¿para que el gato quede bien amarrado? )

Osea, ademas de ser soluciones a problemas comunes los patrones de diseño también son buenas practicas, no?

Las "buenas practicas" no existen. Existen "las buenas practica en la circunstancia tal, o cual". Si tratas de usar una "buena practica" sin tomar en cuenta el contexto, solo por tradicion y repeticion, la echas a perder.

¿No se pierde todo esto al simplemente crear una aplicación de 1 capa?

¿No se pierde el gato si dejas de amarrarlo?

Esa es la pregunta equivocada. La pregunta correcta es:

¿No se pierde tiempo y dinero consiguiendo gato, cuerda y palo para amarrarlo? ¿No sufre el gato al estar amarrado?

Mismo caso con las best practices. Consumen tiempo y dinero, hacen que el programador sufra, y el cliente no pueda tener lo que quiere en la fecha que lo necesita. Bajo algunas circunstancias, la ganancia obtenida al utilizarla justifica ese tiempo y dinero... bajo otras circunstancias no... todo depende...

¿No va en contra de los preceptos de la programación?

Cuales? En que contexto?

No van en contra del rito sagrado, dejar al gato corretear libre por ahí? o poner una puerta y cerrarla para que no entre? o darle de comer a esa hora para que no de lata? (o, peor aun... no tener gato?)

Ahora sí que desobedeces al orden superior

No hay orden superior, solo hay circunstancias.

ser rebelde es bueno también jaja.

Exacto. Siempre y cuando te rebeles "correctamente". Paradojico no?

Muy interesante tu post.

Gracias.

Imagen de ezamudio

Patrones

Creo que el problema con los patrones es que no se ha entendido bien su propósito y por eso se abusa de ellos.

Los patrones de diseño sirven para tener un lenguaje común a la hora de implementar cosas que son utilizadas muy frecuentemente. Pero no significa que los tienes que usar siempre. Ni todos. Antes tal vez le preguntabas a alguien "oye, creo que aquí necesitamos asegurarnos de todo mundo use la misma instancia de este objeto, o sea que debería haber una sola en toda la aplicación, cómo puedo hacer eso?" y la respuesta era algo larga, mmm pues podrías hacer que todos los métodos sean estáticos, y usar la clase directamente, o tal vez podrías poner un solo método estático que devuelva una instancia del objeto y ahí crear una sola... y luego "oye eso sí funcionó pero hay problemas cuando dos o más hilos invocan el método estático que devuelve la instancia, parece que se crean dos o tres" mmmmm ah pues es que entonces hay que ponerle unos candados para que solamente el primer hilo sea el que crea la instancia y blablablablablablabalblablabalbalbalbalbalbla... hoy simplemente la respuesta es "implementa el patrón Singleton".

El hecho de que exista un patrón no significa que lo tienes que usar siempre. Y ese ejemplo en particular que puso luxspes es muy común, se implementa sin ser necesario. Es en cierta forma una optimización prematura y eso es la raíz de todos los males...

En cuanto a las otras preguntas: No, no se pierde la independencia con la base de datos al implementar todo en una capa. Una solución muy simple para eso del DAO es definir una interfaz y luego implementarla; todos los que usan el DAO deben programar contra la interfaz, y en un solo lugar debe haber una forma de instanciar la implementación y pasarla a todos los que la necesitan. Si quieres cambiar de base de datos, implementas un nuevo DAO y reemplazas el anterior, y ya. Las capas no son para eso. Ves por qué luego se abusa de los patrones? El diseño de capas no tiene como objetivo la supuesta independencia de la base de datos, eso se logra con una vil interfaz. Por lo tanto estás usando un patrón sin saber siquiera para qué se supone que es realmente.

Es como echarle limón a un taco de cochinita pibil, porque pues a los tacos se les echa limón, sin saber que el objetivo del limón es darle cierta acidez, para resaltar los sabores de los ingredientes del taco, y eso no es necesario en el caso de la cochinita porque se cocina con jugo de naranja agria.

Imagen de ezamudio

preceptos

Y de qué preceptos hablas? Porque cuando yo empecé a programar ni siquiera existían los patrones de diseño. En 1998 hice una especie de repositorio con varios ejemplos de código en Objective-C para hacer distintas cosas como sincronización entre hilos, objetos con una sola instancia, distintas formas de composición y abstracción, etc; les decíamos "recetas" y el repo pues era el recetario; la idea era que cuando alguien tenía una duda de cómo implementar algo podía buscar en el recetario a ver si algo le servía. Lo malo es que no soy bueno para nombrar cosas y entonces los nombres de las recetas eran tipo "cómo crear una clase que tenga una sola instancia".

Imagen de luxspes

Jugo de naranja agria

Esto me encantó:

Es como echarle limón a un taco de cochinita pibil, porque pues a los tacos se les echa limón, sin saber que el objetivo del limón es darle cierta acidez, para resaltar los sabores de los ingredientes del taco, y eso no es necesario en el caso de la cochinita porque se cocina con jugo de naranja agria.

Imagen de Jose Manuel

Mmmm, no se si te estoy

Mmmm, no se si te estoy entendiendo bien, pero dao-service-controller no es MVC (model-view-controller). Checa aqui la diferencia

Será que me confundí, ya que he visto proyectos con la estructura dao-service-controller que ademas tienen el MVC, sera que me falta estudiar mas sobre estos diseños.

Bueno, si la versatilidad no es propia del proyecto esta no sera incluida, perfecto. Dada mi nula experiencia laboral no me he enfrentado con los "final boss" por lo tanto todo lo que escribo tiene como fuente mi ignorancia en los temas y lo poco que he podido aprender.

De acuerdo, una buena practica (mejor dicho contextual practices) se elige según la situación. Pero entonces eso quiere decir que solo debemos escoger la correcta, dejarnos de hacer marketing y usarlas. Por lo del tiempo y dinero no sabría que escribirte pero, puedo darme una idea de la situación.

¿Y los mandatos de la programación no son mejorar el desarrollo del software? Todos los patrones, estructuras, convenciones, etc. ¿Olvidarse del gato no va de cierta manera en contra de esto? Entonces, me olvido del gato, de la cuerda y del palo. ¿Qué queda entonces? ¿No es esto retroceder? ¿Qué pasara cuando no haya capas que permitan el mantenimiento y/o modificación las aplicaciones?

¿Será mejor aprender a controlar el gato dadas las circunstancias especificas? O puede que no este caminando por el camino zen jeje.
Saludos.

Imagen de luxspes

Lo importante es recordar que lo importante es relativo

¿Y los mandatos de la programación no son mejorar el desarrollo del software?

El mandato del proyecto, es satisfacer la necesidad del cliente. Nada mas.

El mandato de tu profesion, es hacer algo de lo que puedas sentirte orgulloso, y que cuando otro desarrollador tenga que darle mantenimiento no sufra.

Todos los patrones, estructuras, convenciones, etc. ¿Olvidarse del gato no va de cierta manera en contra de esto?

Olvidarse o no del gato, es circunstancial. Si estas meditando en Bastet, el gato es crucial, si no. no.

Entonces, me olvido del gato, de la cuerda y del palo. ¿Qué queda entonces? ¿No es esto retroceder?

Depende... adorar y meditar al respecto de Bastet no se considera muy moderno... ¿o si?

Retroceder o avanzar, tambien es circunstancial, depende de hacia donde quieres ir

¿Qué pasara cuando no haya capas que permitan el mantenimiento y/o modificación las aplicaciones?

Sepa... igual y el cliente tirara tu sistema en Java y lo cambiara por uno hecho en Genexus... Y entonces... ¿de que te habra servido meterle tanta capa?

¿Será mejor aprender a controlar el gato dadas las circunstancias especificas?

Dependera... de las circunstancias especificas...

O puede que no este caminando por el camino zen jeje.

Todos los viajes inician con 1 solo paso: Shu Ha Ri

Imagen de ezamudio

gato

No es que se trate de olvidarse del gato. Hay que analizar el por qué del gato. En el ejemplo, el gato es una estupidez, una tradición idiota que surgió de seguir haciendo lo mismo sin preguntar por qué se hace. Cuando te imponen una manera de hacer algo, hay que cuestionar por qué.

Siguiendo ese ejemplo, olvidarse del gato no sería retroceder, al contrario, sería dejar atrás una costumbre idiota que no tenía ningún propósito más que con el gato original.

Imagen de Jose Manuel

Vaya, esta mañana-tarde ha

Vaya, esta mañana-tarde ha estado genial. He aprendido muchas cosas y me he dado cuenta de varias otras; de donde estoy, de como pensaba, como entendía el desarrollo de software. De lo que me falta y de lo que me sobra, sin duda este post ha hecho mucho por mi. Espero poder dar mi primer paso pronto.
Saludos y gracias.

Imagen de echan

que blasfemia .. seras

que blasfemia .. seras expulsado del mundo empresarial :)

.... de alguna forma tambien la limitante del lenguaje nos orilla a organizar la aplicacion de esa manera .. hablando de Ruby puedes tomar otra aproximacion como arquitectura DCI o el modelo de Actores. Al final de cuentas son patrones y no reglas y hoy gracias al opensource podemos ver diferentes formas de organizar aplicaciones.

Imagen de ezamudio

lenguaje?

No hay absolutamente nada en Java que te obligue o siquiera te encamine a escribir siempre usando capas.

Imagen de echan

hello word no cuenta.. pero

hello word no cuenta.. pero trata de escribir algo mediano en java .. por salud mental terminaras organizando el codigo de alguna manera (capas)

Imagen de ezamudio

en lo que sea

Trata de escribir algo mediano en el lenguaje que sea, por salud mental terminarás organizando el código de alguna manera.

El objetivo de las capas no es organizar código, sino poder particionar una aplicación para que se encuentre en varios equipos distintos, para poder luego hacer balanceo de cargas, redundancia, temas de seguridad en red, etc. Es un diseño modular. Que el código quede organizado de cierta forma es casi un efecto secundario.

Trabajo diario con una aplicación que hice yo mismo, que mide 185KLOC efectivas. No sé si eso se considere mediano, grande o qué cosa. Tiene un diseño modular, pero no son capas. El código está organizado en módulos de IDEA (o proyectos de Eclipse), cada uno de ellos en uno o varios paquetes.

No hay que confundir la organización de código con la arquitectura de una aplicación. El modelo de capas no es para organizar código.

Imagen de echan

cierto que el diseño de

cierto que el diseño de software no es ciencia exacta y creo que es el punto de @ luxspes pero


Que el código quede organizado de cierta forma es casi un efecto secundario

la Orientacion a Objetos es un efecto secundario? .. puedes tener 3 clases y cada una representar una capa.. capas es solo una etiqueta pero puedes ponerle otro nombre Rol, Contexto, Modulo, etc.


No hay que confundir la organización de código con la arquitectura de una aplicación.

Cierto .. la arquitectura es mucho mas que eso.

Imagen de luxspes

Layer vs Tier ¿Capas?

No hay que confundir la organización de código con la arquitectura de una aplicación. El modelo de capas no es para organizar código.

En parte tienes razon... y en parte no...

Creo que es un problema de traduccion ingles/español:

La arquitectura "Multi-tier" es una separacion fisica del las parte de la aplicacion. (Esta es la parte en la que tienes razon)

Por otro lado...

La arquitectura "Multi Layered " por otra parte si organiza codigo y se enfoca en agrupa funcionalidad relacionada dentro de una aplicacion en distintos "layers" que son apilados verticalmente uno sobre el otro.

El problema es que en español, usamos "Capa" como traduccion tanto para Layer como para Tier....

Segun Google Translate: Tier = Nivel y Layer = Capa

Imagen de luxspes

Estilos arquitecturales. Emergencia Organica

cierto que el diseño de software no es ciencia exacta y creo que es el punto de @ luxspes pero

No exactamente, mi punto es que el diseño de software no debe basarse en tradicion.

Que el código quede organizado de cierta forma es casi un efecto secundario

Mas bien, la organizacion del codigo debe fluir organicamente del balance entre OAOO y YAGNI. La organizacion debe ser un resultado emergente de ese balance

Pero de eso hablare en la segunda parte...

la Orientacion a Objetos es un efecto secundario? ..

Pues, en cierto sentido, si, es un efecto secundario de la incapacidad del cerebro humano para escribir grandes programas sin una estructura que lo auxilie.

puedes tener 3 clases y cada una representar una capa.. capas es solo una etiqueta pero puedes ponerle otro nombre Rol, Contexto, Modulo, etc.

Capas es mas que una etiqueta. Capas es un estilo arquitectural, existen varios. No te cases con uno. Analiza la situacion. Elije el mejor para TU situacion.

Y date cuenta que el mejor para TU situacion, puede ser una combinacion de varios... o uno completamente nuevo

No hay que confundir la organización de código con la arquitectura de una aplicación.

Bueno, hay arquitectura fisica, y hay arquitectura logica, y la logica si tiene que ver con el codigo.

Imagen de luxspes

Enfasis en esto.

Enfasis en esto:

No hay absolutamente nada en Java que te obligue o siquiera te encamine a escribir siempre usando capas.

En WebObjects, por ejemplo, @Chochos y yo usabamos arquitectura Domain Driven (y ni sabiamos que asi se iba a llamar.. bueno yo al menos no lo supe hasta años despues...)

Desde entonces, he buscado frameworks en Java y en .NET que se le acerquen a WebObjects... En general se quedan cortos...

Imagen de ezamudio

what?

Creo que estás queriendo distorsionar lo que digo, no sé si intencionalmente. Citándome fuera de contexto...

Aquí el párrafo completo otra vez, con el principio y el final resaltados, porque podría leerse sólo esas dos partes:

El objetivo de las capas no es organizar código, sino poder particionar una aplicación para que se encuentre en varios equipos distintos, para poder luego hacer balanceo de cargas, redundancia, temas de seguridad en red, etc. Es un diseño modular. Que el código quede organizado de cierta forma es casi un efecto secundario.

Puedes implementar el patrón o modelo de capas (tanto tiers como layers) usando programación puramente procedural, o con OOP o en un esquema híbrido. Tal vez con programación funcional también. No es algo exclusivo de OOP. No van "de la mano", en el sentido de que no es necesario implementar capas siempre que usas OOP, ni es necesario usar OOP para poder implementar capas.

Imagen de echan

Capas es mas que una


Capas es mas que una etiqueta. Capas es un estilo arquitectural, existen varios.

Mi punto es que la arquitectura o estilo arquitectural no es solo una etiqueta, "capas" es una etiqueta de las partes que organizan la arquitectura pero le puedes poner otro nombre Modulo, Componente, Servicio, Actor, etc. tal como muestra link http://msdn.microsoft.com/en-us/library/ee658117.aspx


No hay absolutamente nada en Java que te obligue o siquiera te encamine a escribir siempre usando capas

claro tu programa no compilaria si fueran obligatorias


en distintos "layers" que son apilados verticalmente uno sobre el otro

las capas tambien se pueden organizar horizontal o transaversalmente..

Imagen de beto.bateria

Gatos y oracion, hay que olvidarlos.

Lo mas importante es la correcta asignacion de tareas, a un tier, layer, clase, a la nueva supertecnologia que resuelve todo, o a lo que tu quieras o creas. De hecho los patrones utilizan esta buena asignacion y los resultados son excelentes. El problema es que mistifican (el gato atado) una solucion y se deja de usar el sentido comun. Cuantas veces he oido, eso no puede hacerse porque es mala practica, yo solo me rio en mis adentros, y dijo, estos pobres no dejan su gato libre (texto adaptado al contexto)

Imagen de echan

Que el código quede


Que el código quede organizado de cierta forma es casi un efecto secundario

en un lenguaje como Java la unidad minima de organizacion es la Clase (OO) y por lo tanto no es un efecto secundario sino obligatorio organizarlo de esa manera. En un lenguaje como Clojure la organizacion minima son funciones y por lo tanto no es secundario ... etc, etc


El objetivo de las capas no es organizar código, sino poder particionar una aplicación para que se encuentre en varios equipos distintos, para poder luego hacer balanceo de cargas, redundancia, temas de seguridad en red

¿y tomcat apa? sus componentes no estan distribuidos y puedo replicarlo para tener alta disponibilidad, distribucion de carga etc .

Imagen de luxspes

La distorsion no es mi intencion :-S

Creo que estás queriendo distorsionar lo que digo, no sé si intencionalmente. Citándome fuera de contexto...

Glup... lo malo de este foro, es que no hay manera de saber exactamente a quien te diriges cuando dices eso... pero nop, si algo que puse dio la impresion de distorsion intencional, pido disculpas, no es asi, supongo que entendi mal... :-S

Imagen de luxspes

Efecto emergente (mas detalles en segunda parte)

en un lenguaje como Java la unidad minima de organizacion es la Clase (OO) y por lo tanto no es un efecto secundario sino obligatorio organizarlo de esa manera. En un lenguaje como Clojure la organizacion minima son funciones y por lo tanto no es secundario ... etc, etc

Efectivamente, no es un efecto secundario. Pero el hecho de que existan cosas como lenguajes como clojure o como java, si es un "efecto" de la necesidad de nuestro cerebro de organizar las cosas (solo que no diria yo que es secundario, si no mas bien: emergente)

Imagen de echan

@luxspes @ ezamudio no hay

@luxspes @ ezamudio no hay intencion de ofender solo argumentar un poco para hacer mas divertido este sitio :) .Saludos

Imagen de ezamudio

ofender?

Alguien se sintió ofendido?

Lo de citarme fuera de contexto es para echan, que me respondió a la última frase de un párrafo y por eso hice la aclaración.

Lo de tomcat es un ejemplo distinto y no tiene nada que ver con lo que menciono de las capas.

Si no tienes ninguna restricción externa, puedes replicar tu aplicación usando tomcat o cualquier otro contenedor que tenga esa facilidad del balanceo de cargas/failover, y listo. Si de repente algún componente de la aplicación tiene una restricción que no le permita replicarse, entonces tienes que hacer algo para aislar ese componente y distribuir la aplicación de alguna forma.

Ejemplos de esas restricciones:

- el componente se conecta a un servicio externo que solamente acepta una conexión y tiene que venir desde una misma IP siempre.
- el componente debe estar en un solo equipo porque ese equipo está en una zona especial de la red (la DMZ, o es un equipo que tiene una vpn host-to-host, etc).
- el componente requiere de hardware especializado que no es fácilmente replicable porque es carísimo y sólo se encuentra instalado en un equipo.

Para todos esos casos, puedes poner toda la aplicación en ese mismo equipo pero pues no podrás poner instancias en otros equipos; en el momento en que necesites hacer algún balanceo o mecanismo de failover usando otros equipos, tendrás que particionar la aplicación. Si desde el principio la tenías en capas, pues será relativamente fácil; si no, pues habrá que aplicar un refactoring para aislar el componente y poderlo separar físicamente del resto de la aplicación.

Y tal vez con eso muchos piensan "ajá! entonces está bien siempre usar capas porque qué tal que un día me pasa eso"... pero pues alcen la mano los que han tenido que lidiar con una situación así, de manera inesperada, es decir, que no estaba especificado desde el inicio sino que un buen día ya terminado el proyecto resulta que hay que hacer esos cambios...

Imagen de luxspes

Falla del foro

Alguien se sintió ofendido?

Todos felices por aca ;-)

Lo de citarme fuera de contexto es para echan, que me respondió a la última frase de un párrafo y por eso hice la aclaración.

Con esto me salgo del tema pero... ¿el codigo de Javamexico esta en algun lado? ¿github? ¿es java? ¿se vale contribuir con algun pull request que resuelva el hecho de que no hay forma de saber a quien se le respondio que?

El cambio es la única constante...

Claro, no puedes ammarrar siempre al gato 100 años despues sólo porque alguna véz un gato hacia siempre travesuras, pero, ¿Que hay de la prevención?. En un sistema pequeño (que hoy en día asi le llaman a todos porque surge de una pequeña necesidad, pero despues hacen su carta a los reyes magos y ese pequeño sistema se convierte en el eje central de la administración de un macrotema) puede paraecer que es inutil utilizar un diseño fuerte para definir que la funcionalidad se clasifica en "capas". Yo no tengo mucha experiencia en proyectos como el autor del post, pero en estos casi 5 años de chamba, no he estado en algún proyecto en el que se haga lo que inicialmente se definió. Entonces, por qué si sabemos que algo va a cambiar, ¿Por qué no hacerlo dinamico al cambio desde un principio?. A veces, me meto al curiosear al github para ver qué y cómo hacen X, Y, Z otras personas y pienso "a shingá!, por qué tanta vuelta para hacer esto?" y despues de un rato de tratar de comprender la intensión del autor me queda claro que un principio de diseño está presente "Classes should be open for extension, but closed for modification." y eso te hace ir por un camino mediante el se debe escribir una forma de Adaptación. Supongamos un "sistema pequeño" el cual tiene un requerimiento "bien definido" El sistema debe escribir blah blah!:

Despues del analisis diseño nuestro sistema quedó listo para producción.

... void  imprimeBlahBlah(){
    ...print("blah blah!");
}

El usuario del sistema está contento porque se hizo lo correcto

¿Que pasa ahora? El suaurio del sistema necesita saber a qué hora se esribió el mensaje. Ok, sin problemas, el cambio es pequeño y lo tenemos antes de salir a comer. El código nuevo es:

... void imprimeBlahBlahConFecha() {
    ...print(new Date() + " blah blah!");
}

Perfecto, el cliente queda nuevamente impresionado y contento.

Somos buenos, realizamos lo que el cliente esperaba y el impacto en un contról de cambios fué de sólo una linea! "CHIDO, SOMOS LOS MEJORES!"... 2 años después se requere modificar el sistema, el sistema tiene otro sistema que necesita utilizar al primero para escribir su mensaje (como ya tenemos un sistema que imprime mensajes, ¿Cómo pa qué hacer otro?) asi que solicitamos el cambio a los nuevos Ingenierazos expertos para que escriban el mensaje que el nuevo sistema les va a mandar... Sin problema, somos expertos ahi va:

... void imprimeBlahBlahConFecha() {
    imprimeMensaje(new Date() + " blah blah!");
}

... void imprimeMensaje(String mensaje) {
    ...print(mensaje);
}

Listo, derechito a producción. El nuevo sistema puede llamar a imprimeMensaje(String) y tan sólo costó $$,$$$ el cambio al primer sistema. En este caso, todo estuvo bien, se tiene un software funcional y cumple con lo que se definió.

Dejen cito nuevamente el principio de diseño "Classes should be open for extension, but closed for modification."... Ajáaaa... algo hicimos mal porque siempre modificamos lo que "ya estaba definido" (y todo por no amarrar al condenado gato!).

Si vemos el ejemplo del código anterior vamos a notar que solo se modificaron pocas lineas de código pero el impacto fue grande ¿Por qué? pos porque aunque poco código tenga en terminos porcentuales el impacto fue grande se cambió en un caso el 100% eso queire decir que se retrabajo el sistema entero (Ya han hablado acerca de la deuda técnica) "Y TODO POR NO AMARRAR AL GATO!!". No quiero decir que se tenga que crear un MessageFactory que nos de una instancia del mensaje listo para imprimir o un MessagePrinter que genere un mecanismo de impresión del mensaje o MessageObserver que imprima el mensaje cuando algo cambia de valor o ... n patrones útiles/inútiles que como bien se indican en posts anteriores "no deben implementarse para todos los casos".

Bueno, esa ha sido parte de mi experiencia chambeando. Personalmente no creo que reducir capas/quitar patrones sea una solución correcta. Por cierto, me gusta esa frase que no recuerdo quien la mencionó (Si nadie la reclama fue Einstein jejejeje): "La unica constante es el cambio". Entonces hagamos siempre nuestros sistemas flexibles al cambio y para ello requerimos patrones para que hablemos el mismo idioma y capas que hasta la de los tamales tiene separados los de mole, dulce y Oaxaqueños

Imagen de ezamudio

javaMexico

Esta madre es drupal, una versión vieja además. No tengo idea si puedes hacer pull request porque no sé dónde se hospede ese proyecto, pero tendrías que programar en php y se te va a contaminar el cerebro.

Mejor métele mano al javamexico 2.0 que está en Grails, en github (github.com/javamexico)

Imagen de avefenix_x

Aveces te hacen amarrar el gato aun que no quieras.

Hay que tomar en cuenta de que cuando llegas a trabajar o meditar a algunos lugares el amarrar el gato ya es algo comun.. y lo que te queda por hacer es tambien amarrarlo.
Mas sin embargo cuando demuestras que el gato ya no hace daño a lo que realizas es posible dejar de amarrarlo.
Me a tocado trabajar en lugares donde amarras o amarras el gato.. y no hay forma de quitarlo en ese momento. despues el tiempo realizara lo propio para que lo dejen de amarrar, esto puede no llegar a suceder. :)
Tambien me ha tocado ver que algunos dicen que el gato no debe de amarrarse pero lo amarran en lo oscurito y es lo mas desepcionante.

Saludos.

Imagen de luxspes

¿Quieren cambio 2 años despues? Que paguen

Dejen cito nuevamente el principio de diseño "Classes should be open for extension, but closed for modification."... Ajáaaa... algo hicimos mal porque siempre modificamos lo que "ya estaba definido" (y todo por no amarrar al condenado gato!)

Este es precisamente el tipo de pensamiento que es peligroso. ¿Hicimos mal? Depende.

Para el caso especifico que planteas: "2 años después se requere modificar el sistema...". Con la pena, pero si el cliente quiere un cambio 2 años despues, pues tendra que pagar un change request por las horas que se requieran para hacer las cosas.

Al aplicar patrones, debemos pensar: Como beneficia esto al proyecto? Quiero pagar el precio de un punto de extensibilidad aqui? En la mayoria de los casos, (como en el de tu ejemplo) la respuesta es un rotundo: No.

Imagen de luxspes

Adaptacion vs Cambio

Hay que tomar en cuenta de que cuando llegas a trabajar o meditar a algunos lugares el amarrar el gato ya es algo comun..

Si eso pasa

y lo que te queda por hacer es tambien amarrarlo.

Ahi ya no estoy tan de acuerdo

Mas sin embargo cuando demuestras que el gato ya no hace daño a lo que realizas es posible dejar de amarrarlo.

Exacto, la clave esta en demostrar. Quitar las capas genera ahorros en numeros de lineas de codigo , y en facilidad al depurar un problema. Ademas, a menor numero de lineas de codigo. menor numero de bugs.

Me a tocado trabajar en lugares donde amarras o amarras el gato.. y no hay forma de quitarlo en ese momento. despues el tiempo realizara lo propio para que lo dejen de amarrar, esto puede no llegar a suceder. :)

La cosa es buscar no amarrar al gato a menos que haga sentido. No ser agresivo, siempre es mejor conseguir el cambio por la via de la amabilidad. Pero hay que ser asertivo. Si sabemos que algo esta mal, decirlo con amabilidad pero con firmeza. Ya si no te quieren escuchar, pues alla ellos. Concentrate en hacer correctamente tu chamba y deja que el resto fluya.

Tambien me ha tocado ver que algunos dicen que el gato no debe de amarrarse pero lo amarran en lo oscurito y es lo mas desepcionante.

Si, totalmente de acuerdo

Imagen de luxspes

Quitar por quitar es tan malo como poner por poner

Bueno, esa ha sido parte de mi experiencia chambeando. Personalmente no creo que reducir capas/quitar patrones sea una solución correcta.

Quitarlas por quitarlas, es tan malo como ponerlas por ponerlas. Hay usarlas cuando es debido (pero ese sera tema de mi siguiente post).

Lo cierto es que en Java, el JSR 299 (Weld, derivado de JBoss Seam, tiene como uno de sus propositos explicitos "colapsar" las capas)

Por cierto, me gusta esa frase que no recuerdo quien la mencionó (Si nadie la reclama fue Einstein jejejeje): "La unica constante es el cambio".

De mis frases favoritas.

Entonces hagamos siempre nuestros sistemas flexibles al cambio

"Siempre" es una palabra MUY peligrosa. Casi nunca hace sentido decir que se va a hacer algo siempre. Hagamos nuestros sistemas flexibles al cambio cuando haga sentido.

Efectivamente el cambio es la unica constante, lo cual quiere decir, combinado con la ley de Murphy, que la parte de tu proyecto que cambiará, tipicamente sera esa que pensaste que no. Asi que no te adelantes.

Yagni nos recuerda que hay casos en donde es mejor reaccionar que ser proactivo

y para ello requerimos patrones para que hablemos el mismo idioma y capas que hasta la de los tamales tiene separados los de mole, dulce y Oaxaqueños

Bonita analogia, pero desafortunadamente, el software cambia mucho mas frecuentemente que las recetas de tamales....

Imagen de Nopalin

Flojera

Desde mi punto de vista, la mayoria de los programadores empresariales tratan de trabajar lo menos posible.

Voy a decir una suposicion, ya que aunque nadie lo diga todos estan suponiendo cosas. Si el monje amarra el gato cada vez que hace ruido durante su meditación, esa tradición de amarrar al gato siempre no se hubiera realizado, solo se haria si el gato molestara, pero que tal si es mas costoso detener la meditacion, interrumpir a todos, agarrar al gato y amarrarlo que amarrarlo desde el principio. Las futuras generaciones tal vez no sabrán el motivo real del por que se amarra al gato, sin embargo en su momento fue un hecho probado que era la mejor solucion y aunque nadie lo sepa, hacer ese esfuerzo extra al principio nos está indicando que en promedio estamos reduciendo esfuerzo.

Lo que comenta luxpess de tener muchas veces capas y capas (o niveles) en nuestra aplicación deberia ser analizado para dejarlo en lo menos costoso posible, en promedio. El ejemplo que el dio de tener un DAO, un BSI y un CONTROLLER a mi me resulta el menos costoso, explico: tu tienes tu controller que básicamente son las llamadas que hace el GUI, el BSI que es solo el acceso a la metodos de negocio y DAO que tiene la lógica. Desde que se llama al BSI se inicia la transaccion, por lo que llamar uno o muchos metodos de un DAO o de muchos DAO es indistinto para la transaccion, lo que ésto implica que podemos reutilizar metodos y por ende ahorrarnos trabajo. Ahora vamos a suponer que el cliente te pide un modulo web programado en php para reportes, pues solo expones varios BSI's como web services y listo, te ahorrante un montonal de trabajo con el simple hecho de mantener los BSI que ni es tan complicado. ¿Y si el acceso fuera desde un smartphone?, una TV inteligente? un refrigeador inteligente? lo mismo.

Comparto la idea de luxpess de hay que quitar codigo que no sirva, pero habra otro codigo que siempre debes poner independientemente de si lo usaras al inicio o no, ya que como él mismo dice nunca sabes lo que el cliente te va a pedir y hay que estar preparado para al menos las solicitudes mas comunes, que esas las vamos descubriendo conforme vamos ganando experiencia.

Por que dije que a los programadores empresariales les gusta aplicar la ley del menos esfuerzo? Por la sencilla razon de que si el proyecto lo hacen en 1 semana o un mes, a ellos les pagan el mes y a nosotros no, mientras mas nos tardemos mas perdemos. Entonces al programador empresarial le da igual hacer un hola mundo en un jsp y aventarse todo en un jsp, que al cabo en dos años cuando le pidan agregar algunos modulos extras y no encajen en su arquitectura, a él le pagaran los meses extras que se tarde el proyecto.

Pongo un ejemplo rapido, tengo un cliente que se dedica al almacenaje de material. Uno de sus clientes le dijo, oye pa que me obligas a hacer interfaces entre mi software y el tuyo para automatizar algunos procesos si tu puedes usar mi software en tu empresa y olvidarte del tuyo. Mi cliente le dijo: ah ps no hay problema nomas instalamelo y capacítame a la gente. El proyecto se propuso en noviembre del año pasado, tenia que arrancar en febrero del 2013, y cuando llego febrero que siempre no, que en abril, cuando llego abril que siempre no, que en junio, orita en junio dijeron que hasta agosto y estoy casi seguro que en agosto diran que hasta enero del 2014. ¿Ustedes creen que mi cliente me hubiera perdonado mas de medio año de atraso? jajajajaja

Ya por ultimo, las capas son necesarias, lo vivimos dia a dia y se ha comprobado que es la manera mas eficiente de trabajar y escalar. Por ejemplo la compañia de telefonos no viene y nos entrega el sobre con nuestra factura, utiliza un intermediario para ello que es la capa de entrega. En una empresa están las divisiones y los niveles y es cuando encapsulas la chamba que le toca hacer a cada uno. Una tortilleria esta la capa que produce las tortillas (la maquina que nunca deja de rechinar), la que recoje las tortillas, la que cobra y el repartidor. Casi cualquier ejemplo que pongan se caracteriza por tener niveles y lo que nos indican es que cada una existe por que cada una hace chamba en especifico. ¿Si no por que se crearon los motores de base de datos? ¿por que no se dejaron esas funciones dentro del lenguaje como tenia fox pro o access? por que desde mi punto de vista lo mejor es diferenciar el trabajo que realiza cada capa o nivel.

sobres

Imagen de ezamudio

capas?

Nopalin, estás confundiendo capas con separación de funciones. Es bueno separar funciones. No siempre es necesario separarlas por capas. Capas es una manera de organizar esa separación de funciones, pero no la única.

El servicio postal no es una capa de la compañía telefónica, es un servicio completamente separado. El ejemplo de la tortillería es un poco más interesante; si lo usas con algún producto más complicado, tienes el modelo de pipeline, una línea de producción, donde hay varios componentes conectados en serie, la salida uno es la entrada del siguiente. Pero luego hay otros componentes que ya no son necesariamente parte de esa línea: la persona que cobra y la persona que reparte son aparte (obvio no tendrían nada que hacer si no hay tortillas pero no son parte de la línea de producción).

Ayer vi esta presentación muy interesante de una manera distinta de hacer aplicaciones en Java, que me parece muy atractiva. Hacerlas microservicios tipo UNIX, y al final tienes una arquitectura "hexagonal" (o puedes usar el polígono de tu preferencia, la cosa es que son más como nodos en un gráfico o red, y nada que ver con capas).

http://www.infoq.com/presentations/Micro-Services

Imagen de Nopalin

Si tal vez tienes razon,

Si tal vez tienes razon, muchas veces mi ingles no me da para más y entiendo algo que encaje en mi descripción en lugar de lo que quieren decir.

Cual seria entonces la diferencia real entre una capa y separación de funciones? a final de cuentas una capa hace otra funcion, que no?

Imagen de luxspes

La flojera, en un programador, es una virtud

Desde mi punto de vista, la mayoria de los programadores empresariales tratan de trabajar lo menos posible.

Todo buen programador trata de trabajar lo menos posible, la primera virtud del buen programador es la flojera

Voy a decir una suposicion, ya que aunque nadie lo diga todos estan suponiendo cosas.

Si, siempre, malo no es suponer, lo malo es no hacer publico lo que supones, asi que, adelante

Si el monje amarra el gato cada vez que hace ruido durante su meditación, esa tradición de amarrar al gato siempre no se hubiera realizado, solo se haria si el gato molestara, pero que tal si es mas costoso detener la meditacion, interrumpir a todos, agarrar al gato y amarrarlo que amarrarlo desde el principio.

Hasta aqui ok...

Las futuras generaciones tal vez no sabrán el motivo real del por que se amarra al gato, sin embargo en su momento fue un hecho probado que era la mejor solucion

¿Seguro? Tal vez hubiera sido mejor cerrar la puerta... no tienes forma de saberlo

y aunque nadie lo sepa, hacer ese esfuerzo extra al principio nos está indicando que en promedio estamos reduciendo esfuerzo.

¿Seguro? Digo, tal vez en el pasado... pero ¿modernamente? ¿como sabes sigue siendo mejor esfuerzo? lo malo de que se vuelva tradicion, es que entonces, intentar cambiarlo es herejia y el solo hablar en contra, ya lleva castigo... y eso lleva a que el sistema ya no se optimice

Lo que comenta luxpess de tener muchas veces capas y capas (o niveles) en nuestra aplicación deberia ser analizado para dejarlo en lo menos costoso posible, en promedio. El ejemplo que el dio de tener un DAO, un BSI y un CONTROLLER a mi me resulta el menos costoso,

Veamos por que

explico: tu tienes tu controller que básicamente son las llamadas que hace el GUI, el BSI que es solo el acceso a la metodos de negocio y DAO que tiene la lógica. Desde que se llama al BSI se inicia la transaccion, por lo que llamar uno o muchos metodos de un DAO o de muchos DAO es indistinto para la transaccion, lo que ésto implica que podemos reutilizar metodos y por ende ahorrarnos trabajo.

Lo siento, no me quedo claro. Si hablas de esfuerzo para la maquina, si, es negligible. Pero yo hablo de esfuerzo para el programador, y son significativamente mas lineas las que escribes si pones capa sobre capa sin pensar, que si no. Y a mayor numero de lineas de codigo mas dificil administrarlas, depurarlas, etc.

Ahora vamos a suponer que el cliente te pide un modulo web programado en php para reportes, pues solo expones varios BSI's como web services y listo, te ahorrante un montonal de trabajo con el simple hecho de mantener los BSI que ni es tan complicado. ¿Y si el acceso fuera desde un smartphone?, una TV inteligente? un refrigeador inteligente? lo mismo.

Aqui hay 2 opciones:

  1. Supongamos que no te piden nada de eso. Supongamos que ya no te piden nada. ¿Quien te paga el esfuerzo extra de ponerle cuanta capa? La respuesta es nadie
  2. Supongamos que si te lo piden. Bueno, si te lo piden y no estaba en alcance original, tiene que pagar, ¿por que regalarles la chamba haciendolo mas facil por adelantado? En el momento que lo pidan, sera el momento en que emplees esfuerzo en hacerlo, y no antes

Comparto la idea de luxpes de hay que quitar codigo que no sirva, pero habra otro codigo que siempre debes poner independientemente de si lo usaras al inicio o no, ya que como él mismo dice nunca sabes lo que el cliente te va a pedir y hay que estar preparado para al menos las solicitudes mas comunes, que esas las vamos descubriendo conforme vamos ganando experiencia.

Y precisamente, por que no lo sabes, es mejor no ponerlo... aplica YAGNI a menos que OAOO te diga lo contrario.

Imagen de ezamudio

separación de funciones

Una manera de lograr separación de funciones es con capas.

Imagen de luxspes

Programadores empresariales y esfuerzo

Por que dije que a los programadores empresariales les gusta aplicar la ley del menos esfuerzo?

No lo se... pero sigamos leyendo...

Por la sencilla razon de que si el proyecto lo hacen en 1 semana o un mes, a ellos les pagan el mes y a nosotros no, mientras mas nos tardemos mas perdemos.

Entonces tu supuesto es (corrigeme si estoy mal):
Un empresarial se puede tardar lo que quiera por que le pagan por mes
Un freelancer esta sujeto a tiempos y pierde entre mas se tarde

Ok, sigamos adelante

Entonces al programador empresarial le da igual hacer un hola mundo en un jsp y aventarse todo en un jsp, que al cabo en dos años cuando le pidan agregar algunos modulos extras y no encajen en su arquitectura, a él le pagaran los meses extras que se tarde el proyecto.

Entonces, a un empresarial le pagaran entre mas trabaje, si se tarda mas, le pagan mas, eso es lo que estas diciendo aqui.

Lo siento, pero estas cayendo en contradiccion, al principio dijiste: "a los programadores empresariales les gusta aplicar la ley del menos esfuerzo". Pero lo que estas diciendo ahora, es que a los programadores empresariales les pagan mas entre mas esfuerzo hagan!

Bajo tus propias premisas, has caído en contradicción: Si un programador empresarial se define como alguien al que le pagan mas por hacer mas chamba, entonces no estará orientado al menor esfuerzo, si no al mayor esfuerzo.

Pero sigamos leyendo

Pongo un ejemplo rapido, tengo un cliente que se dedica al almacenaje de material. Uno de sus clientes le dijo, oye pa que me obligas a hacer interfaces entre mi software y el tuyo para automatizar algunos procesos si tu puedes usar mi software en tu empresa y olvidarte del tuyo. Mi cliente le dijo: ah ps no hay problema nomas instalamelo y capacítame a la gente. El proyecto se propuso en noviembre del año pasado, tenia que arrancar en febrero del 2013, y cuando llego febrero que siempre no, que en abril, cuando llego abril que siempre no, que en junio, orita en junio dijeron que hasta agosto y estoy casi seguro que en agosto diran que hasta enero del 2014. ¿Ustedes creen que mi cliente me hubiera perdonado mas de medio año de atraso? jajajajaja

De nuevo lo siento, pero tu ejemplo no te ayuda, solo refuerza la contradicción.

Ya por ultimo, las capas son necesarias, lo vivimos dia a dia y se ha comprobado que es la manera mas eficiente de trabajar y escalar.

Es necesario por que es necesario. Falacia de pensamiento circular.
Es necesario por que es lo que he vivido, se ha comprobado, pero no ofreces evidencias, esto es Falacia magister dixit

De nuevo lo siento...

Por ejemplo la compañia de telefonos no viene y nos entrega el sobre con nuestra factura, utiliza un intermediario para ello que es la capa de entrega. En una empresa están las divisiones y los niveles y es cuando encapsulas la chamba que le toca hacer a cada uno. Una tortilleria esta la capa que produce las tortillas (la maquina que nunca deja de rechinar), la que recoje las tortillas, la que cobra y el repartidor. Casi cualquier ejemplo que pongan se caracteriza por tener niveles y lo que nos indican es que cada una existe por que cada una hace chamba en especifico.

Repartición del trabajo y "capas" no es lo mismo. Hay muchas formas de repartir el trabajo en un software, y no todas usan capas

¿Si no por que se crearon los motores de base de datos?

Esa ya es otra historia... pero no fue para tener capas, de hecho, en aquel entonces, la tendencia era hacer todo dentro de la base de datos.

¿por que no se dejaron esas funciones dentro del lenguaje como tenia fox pro o access?

Otra historia mas... pero ya sera para otro dia...

por que desde mi punto de vista lo mejor es diferenciar el trabajo que realiza cada capa o nivel.
sobres

Y tienes total derecho a tu punto de vista... aunque, en este caso, lo siento, pero estas equivocado.

Imagen de rodrigo salado anaya

Los patrones!

.._..._...._....._......_......._
--..--..--..--..--..--..--..--..--

Los patrones dentro del desarrollo de software se dan en todos los niveles, incluso a cualquier nivel de nuestra existencia, por ejemplo una buena analogía para el ejemplo de las capas de Luxspes (creo yo) sería un topo, un topo tiene ojos y no por eso los usa, aun que la naturaleza tomo un rumbo diferente en la fisionomía del topo no se aleja casi nada en su estructura genética (obvio no soy genético) a la de una rata y las ratas tiene muy buena vista. En el curso de la adaptación puede que se necesite prescindir de herramientas valiosas y alejar la tentación de usarlas por muy buenas que sean.

Estoy consiente que es mejor encontrarte con un código legado que tenga un fuerte sentido del orden en donde yo pueda navegar con relativa facilidad porque comparte los patrones de diseño que e aprendido y pueda modificar sin esperar que todo deje de funcionar porque el desarrollador anterior le dio lo mismo y reinvento el hilo negro con casi todo.

Lo que me causa curiosidad es la fuerza con que muchos nos aferramos a la idea de la correctidud pensando que lo lograremos si seguimos los cánones de la industria que son por decir algunos: usar las herramientas que nos dicen, las versiones que nos dicen, con las practicas que nos piden en fin, apenas vi un video que me pareció interesante y valiente, que habla mucho de no seguir lo que ya esta escrito, y empezar a tomar riesgos en el diseño para bien del proyecto y no solo por seguir las mejores practicas escritas en piedra, incluso llegar a crear su propias 'mejores...' , claro que no digo que mandemos todo por un c[ao]ño y que las mejores practicas no sirven, si no preguntémonos porque todos los mamíferos tenemos el recto justo del otro lado de la nariz (eso si es un buen patrón de diseños).

Sigamos nuestro instinto ya que lo humanos somos unas máquinas insaciables de buscar patrones aveces incluso hasta donde no los hay.

Muy buen Post : )

Imagen de ezamudio

GANADOR

Este post fue uno de los 3 ganadores, felicidades, tienes pase para SGCE2013.

Imagen de Nopalin

ezamudio y si separar las

ezamudio y si separar las funciones es un patrón aceptado, cual seria el problema en usar capas?

luxpess:

¿Seguro? Tal vez hubiera sido mejor cerrar la puerta... no tienes forma de saberlo

Que tal si en 500 años despues el lugar sigue en las mismas condiciones? no tienes forma de saberlo pues no viviste hace 500 años.

Y precisamente, por que no lo sabes, es mejor no ponerlo... aplica YAGNI a menos que OAOO te diga lo contrario.

Comente que la experiencia nos dice cuales son las funciones mas comunes que los clientes piden despues de instalar una primera versión. En base a esa experiencia es decicion de uno hacer ese esfuerzo extra para que en un futuro te sea mas facil implementar alguna requisicion. Como dije, en promedio es menos costoso la inversion inicial que hacerlo a la mera hora que te lo piden, o al menos es mi caso, por eso no aplico YAGNI, si no mas YAGNIY, (you arent gonna need it yet, jajajaja)

Bajo tus propias premisas, has caído en contradicción: Si un programador empresarial se define como alguien al que le pagan mas por hacer mas chamba, entonces no estará orientado al menor esfuerzo, si no al mayor esfuerzo.

Tal vez es mi mala redacción o definicion de ideas, pero lo que trato de decir es que la mayoria de programadores empresariales trabajan para sacar la chamba sin necesidad de ponerse a pensar que si le invierten tantito mas esfuerzo al principio en un futuro ls ayudará a ahorrar tiempo y costo, como quiera ellos tendran el justificante del tiempo y les seguiran pagando por quincena.

Es necesario por que es necesario. Falacia de pensamiento circular.
Es necesario por que es lo que he vivido, se ha comprobado, pero no ofreces evidencias, esto es Falacia magister dixit

En algun momento dije es necesario por que es necesario? Dije es la solución mas aceptable por que lo vivimos dia a dia. ¿Quieres pruebas? mira como esta organizada la empresa donde trabajas o alguna para las que trabajas, en casi todas donde se hace mas de una funcion existen niveles.

Imagen de arterzatij

Mas sobre el tema

No quiero agrabiar a nadie con esto que quede claro pero me parecio interezante investigar temas relacionados y tambien me encontre este articulo:

http://www.petrikainulainen.net/software-development/design/the-biggest-...

Imagen de luxspes

Buena liga!

No quiero agrabiar a nadie con esto que quede claro pero me parecio interezante investigar temas relacionados y tambien me encontre este articulo:
http://www.petrikainulainen.net/software-development/design/the-biggest-...

No agravias a nadie :-)... y esta muy bueno el articulo al que haces referencia, de hecho comparto muchos de los puntos de vista utilizados ahí.

Martin Fowler en el libro de

Martin Fowler en el libro de "Patterns of Enterprise Application Architecture" explica super bien el nivel 4 patrones utilizados para definir la estructura de un proyecto ( y por patrones me refiero precisamente a eso, a ver muchos sistemas y ver como ciertos comportamientos / estructuras / esquemas de organizacion se parecen ). Esta parte es super interesante y ayuda mucho a entender esto de los frameworks y demas.

Los patrones son:

- Transaction script El mas sencillo, entre el usuario y la base de datos tienes los scripts que hacen que funcione (CRUD por ejemplo o validaciones pequenias) Esto lo usas para aplicaciones que son precisamente eso: catalogos, cosas sencillas y que van directo.

- Domain model Cuando la aplicacion es mas compleja y existen muchas reglas que aplicar, se puede hacer un modelo de objetos del sistema ( un modelo del dominio ) y manejar todo como objetos, El cliente tiene una cuenta y la cuenta tiene productos y los productos pertenecen a la linea y etc. etc. Este se escoge cuando las reglas son bastante mas complejas y se deja en los objetos la respondabilidad de la logica del negocio.

- Table Module En un punto intermedio entre los dos, no es una mero conjunto de scritps para persistir/validar datos, pero tampoco es una abstraccion total hacia objetos del negocio, tiene objetos que se encargan ( de manera abstracta ) de la persistencia validacion ( como los DAOs )

- ServiceLayer Cuando los sistemas son lo suficientemente grandes/complejos etc se puede obtar por tener modulos o servicios completos e independientes para interactuar con ellos y modelar la aplicacion. Este seria el patron a usar por ejemplo para sacar datos de un sistema de nomina y cruzarlo con un sistema de ventas y otro de produccion etc. etc.

Obvio deben de existir mas patrones, pero estos cuatro dan un buen ejemplo de los distintos acercamientos que se le puede dar a una aplicacion dependiendo de la complejidad de la misma. Ser'ia demasiado pesado hacer una aplicacion de servicios para un hola mundo y tener un servicio con servidor API, BD, bus de datos, cola de mensajes y todo, nomas para recibir el nombre de la persona a quien hay que saludar y todos otros servicio, servidor, api, etc. etc. para saludarlo. Cada sistema se debe de modelar de acuerdo a las necesidades que se requieran y todos deben de ser lo suficientemente bien escritos para poderles dar mantenimiento / modificarlos. No por tener transaccion script se va a hacer todo en un jsp de 10,000 lineas plagado de ifs.

El caso es que si, RoR parece que si es demasiado para un hola mundo y obvio lo es, pero si la aplicacion, es una que necesita modelar entidades, que estas tengan paginas que necesiten ser cambiadas cada semana y que la complejidad de los accesos a bd es basica y pueden ser mapeados directamente 1-1 con los objetos de negocio, entonces RoR es perfecto, en 3 semanas puedes tener todo una aplicacion lista corriendo y modificandose sin mayores problemas.

No es solo que no lo vayas a necesitar y siempre empezar por lo mas sencillo, hay veces que sabes que lo vas a necesitar y tienen herramientas que te van a ayudar a hacer el trabajo las tienes que usar.

Es por eso que no hay una herramienta / framework / lenguaje / db / tecnologia / etc. que sirva para todas las aplicaciones.

Imagen de luxspes

Cambia, todo cambia, cambia la aplicación y la herramienta...

Martin Fowler en el libro de "Patterns of Enterprise Application Architecture" explica super bien el nivel 4 patrones utilizados para definir la estructura de un proyecto ( y por patrones me refiero precisamente a eso, a ver muchos sistemas y ver como ciertos comportamientos / estructuras / esquemas de organizacion se parecen ). Esta parte es super interesante y ayuda mucho a entender esto de los frameworks y demas

Uno de mis libros favoritos

Los patrones son:

- Transaction script [...]
- Domain model [...]
- Table Module [...]
- ServiceLayer [...]

Coincido casi completamente, solo quisiera agregar que yo siento que la cosa va de lo concreto a lo abstracto mas o menos así:

(Codigo mas concreto, refleja claramente las decisiones tecnicas) TransactionScript < Table Module < Active Record < Domain Model ( Codigo mas abstracto, refleja mas claramente la lenguaje ubicuo del usuario)

En mi opinión, entre mas cercano al patrón de DomainModel escribamos el código mas fácil sera construir lo que el usuario realmente necesita, por que el código queda a un nivel de abstracción en que se parece mucho al lenguaje el el usuario usa para describir su negocio y resulta mas fácil detectar las discrepancias.

Siento que el patron de ServiceLayer pertenece a otra perspectiva diferente, y que a si no se tiene cuidado propicia que el DomainModel se vuelva anemico al tratar de darle al codigo una independencia del mecanismo de persistencia que, en mi opinion, no debiera concernirle al codigo de la aplicacion (DAOs) si no ser abstraida fuera de este mediante mecanismos de persistencia mas inteligentes la persistencia transparente (pero anemica) de JPA/Hibernate y mas en la direccion de EOF o Cayenne.

Obvio deben de existir mas patrones, pero estos cuatro dan un buen ejemplo de los distintos acercamientos que se le puede dar a una aplicacion dependiendo de la complejidad de la misma. Ser'ia demasiado pesado hacer una aplicacion de servicios para un hola mundo y tener un servicio con servidor API, BD, bus de datos, cola de mensajes y todo, nomas para recibir el nombre de la persona a quien hay que saludar y todos otros servicio, servidor, api, etc. etc. para saludarlo. Cada sistema se debe de modelar de acuerdo a las necesidades que se requieran y todos deben de ser lo suficientemente bien escritos para poderles dar mantenimiento / modificarlos. No por tener transaccion script se va a hacer todo en un jsp de 10,000 lineas plagado de ifs.

Totalmente de acuerdo. El problema siento yo, es la evolucion de un punto a otro. Muchos sistemas empiezan simples, y acaban siendo complejos. Y los libros que he encontrado, solo te muestran "fotos" de sistemas simples o "fotos" de sistemas complejos, pero como pasaron de un punto a otro, esa información se convierte "en el eslabón perdido del registro fósil".

La consecuencia de la falta de literatura y entrenamiento en evolución de sistemas hace que la gente trate de aplicar todos los patrones mas potentes y complejos desde el principio, llevando a que sistemas que podrían dar valor de forma temprana al usuario tarden meses en concretarse... o ... igualmente malo, a grandes sistemas construidos con arquitecturas simplistas que no soportan su propio peso y se vuelven inmantenibles...

Considero que el problema viene de que enseñamos el diseño de arquitecturas como algo estático, en vez de como algo que fluye y cambia en el tiempo, tenemos patrones para Transaction Script, y para Domain Model, pero los pasos de refactorizacion requeridos para pasar de uno al otro no estan ni remotamente tan claros...

El caso es que si, RoR parece que si es demasiado para un hola mundo y obvio lo es, pero si la aplicacion, es una que necesita modelar entidades, que estas tengan paginas que necesiten ser cambiadas cada semana y que la complejidad de los accesos a bd es basica y pueden ser mapeados directamente 1-1 con los objetos de negocio, entonces RoR es perfecto, en 3 semanas puedes tener todo una aplicacion lista corriendo y modificandose sin mayores problemas.

De acuerdo

No es solo que no lo vayas a necesitar y siempre empezar por lo mas sencillo, hay veces que sabes que lo vas a necesitar y tienen herramientas que te van a ayudar a hacer el trabajo las tienes que usar.

El problema es ese "sabes". La mayoría de la gente que he conocido no "lo sabe", solo "lo copia" y nunca cosecha beneficios del patrón utilizado, por que no era el que tenia que aplicar para ese caso.

Es por eso que no hay una herramienta / framework / lenguaje / db / tecnologia / etc. que sirva para todas las aplicaciones.

De acuerdo. Solo quisiera indicar que no solo no hay una herramienta / framework / lenguaje / db / tecnologia / etc. que sirva para todas las aplicaciones, si no que también, la herramienta / framework / lenguaje / db / tecnologia / etc que te sirve para una aplicación recien nacida, no es la misma que te sirve para una aplicacion madura o una anciana, durante la vida de la aplicacion, sus necesidades cambiaran, y es importante saber adaptarse a eso....

Y eso... aplicar el patrón correcto dependiendo de la edad y tamaño de tu aplicación en el tiempo...es un tema del que todavía no he encontrado un buen libro...

Igual y es algo que escapa a los libros... y que solo puede ser aprendido experimentándolo de manera directa...

Imagen de arterzatij

En mi opinion

Como todo lo es en el mundo la particularidad de opiniones se centranlizan en como cobrare mi trabajo...

Regularmente y no digo todos, si somos empleados decimos (pensamos): "bueno posiblemente en este proyecto estare mucho asi que hay que hacer que las cosa vallan faciles para el futuro", y siguiendo el relato del gato en las escuela tambien nos enseñan lo que sabe el maestro; si somos muy afortunados tendremos uno excelente que todo se le ovida y por esta razon siempre esta investigando, analizando y realizando pruebas las cuales le habriran un abanico de posibilidades a la hora de desarrollar (con esto me refiero a profesionistas consultores que imparten materias). pero si nos toca alguno que en mi particular punto de vista es un dino pues sera un zen que estubo viendo simpre que amarraban al gato y sin preguntar por que... otra cosa que no se imparte en la uni es precisamente el hecho que no te dicen como cobrar... solo te hechan de la escuela y dicen consiguete una chamba y volvemos al punto "bueno posiblemente en este proyecto estare mucho asi que hay que hacer que las cosa vallan faciles para el futuro"

En mi vida como programador he aprendido varias cosas unas como las que expresa luxspes en su blog, si el cliente quiere un cambio, papa tienes que pagar.

Esto lo aprendi en una consultoria la cual si el cliente no daba o simplemente te daba largas con datos bueno decia esto lo hare asi y asi y asi, con lo cual se cerraba el trato y cualquier cambio por no dar datos pues habia que pagar. Mas de una vez tuve un CR y me enojaba al principio pues yo decia si me hubiera desvelado y hubiera metido esto y esto ahora el cambio seria mas facil. A lo cual mi manager me dijo "Mira tu estimalo todo si te tardas un mes un mes le cobramos al cliente de que te procupas entre mas CRs tengamos tu estaras mas tiempo con nosotros" obviamente era un asociado y si no habia trabajo para mi pues adios busca otro trabajo. Y ahi es donde dije tiene razon por que desvelarme si me puede pagar despues... y no digo que hice un software mal hecho (hacerlo correctamente), si no que simplemente el cliente no expreso o no se interezo en expresar correctamente lo que deseaba (hacer lo correcto), por lo cual no pagare yo (desveladas y tiempo de familia e incluso el mio) por deslindarse de responsabilidades el cliente.

Claro esto lo hacian por que se fijan los desarrollos en supociones abiertas al cliente... pero bueno todo esto ya lo comento luxspes...

A lo que voy es que tenemos que investigar :), jejeje raro no pues en las unis (ahora dicen googlealo lo cual no digo que es malo) ya se esta dejando de hacer esto :'( lamentablemente. Otra cosa a hacer es discernir y analizar (lo malo de las persona que usan google).

No podemos ir por la vida haciendo lo que los demas hacen... claro tampoco podemos dejar de lado a quienes tienen exito haciendo ciertas cosas y que ademas son afines a nosotros por lo tanto si algo hizo el, yo tambien podria hacerlo...

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">