design-patterns - ejemplos - patrones de diseño java
Más allá de los patrones de diseño? (2)
Intente comenzar en http://c2.com/cgi/wiki?NatureOfOrder o http://c2.com/cgi/wiki?HowNatureOfOrderAppliesToSoftware
Durante los últimos 10 años aproximadamente, ha habido algunos artículos y documentos que hacen referencia al trabajo más reciente de Christopher Alexander, "La naturaleza del orden", y cómo se puede aplicar al software.
Desafortunadamente, los únicos trabajos que puedo encontrar son de James Coplien y Richard Gabriel; no hay nada más allá de eso, al menos de mis intentos de encontrar tales cosas a través de google.
¿Este tipo de discusión está sucediendo en algún lado?
MSN
@Georgia
Mi pregunta no es sobre patrones de diseño o lenguajes de patrones; se trata de tratar de ver si se puede aplicar más trabajo de Christopher Alexander al software (lo que probablemente pueda hacer, ya que tiene menos restricciones físicas que la arquitectura y la construcción).
Los patrones de diseño y los lenguajes de patrones parecen haber adoptado la estructura de los patrones de diseño de Alexander, pero no muchos capturan la esencia. La esencia es algo más allá de resolver un problema en un contexto particular.
Es difícil de explicar sin utilizar algunas de las obras posteriores de Alexander como punto de referencia.
Editar: No, retiro eso.
Por ejemplo, hay un patrón de diseño arquitectónico que se llama Alcoves. El patrón tiene un contexto que no solo está enraizado en las circunstancias de la situación, sino que también tiene sus raíces en los fundamentos sobre el propósito de los edificios: que son estructuras en las que se debe vivir y se debe promover la vida en ellas. En el caso del patrón Alcove, el contexto es que desea un área que permita que varias personas estén en la misma área haciendo cosas diferentes, porque es importante que los miembros de la familia estén físicamente juntos y también que puedan hacer cosas que tienden a distraer a otros miembros de la familia.
La mayoría de los patrones de diseño de software describen un problema en un contexto, pero no hacen una declaración más profunda sobre por qué el problema es importante o por qué el problema es algo fundamental para el software. Hace que sea muy fácil aplicar patrones de diseño inapropiados o despreocupados, que es exactamente lo opuesto a la intención de los patrones de diseño para comenzar.
MSN
Su pregunta trae a la mente algunos de los comentarios hechos por Eric Evans en su libro "Domain-Driven Design". Señala que los patrones de diseño en el desarrollo de software a menudo se han descrito como soluciones estrictamente técnicas para problemas técnicos. Pero a veces hay una oportunidad de aplicar un patrón que no solo da estructura a la implementación del software, sino que también es significativo en el modelo comercial.
Por ejemplo, considere el uso del patrón de ESTRATEGIA simplemente como un detalle de implementación, versus el caso donde realmente tiene sentido que los programadores y la empresa hablen sobre cómo se seleccionan y utilizan las ESTRATEGIAS, es decir, dónde forma parte del LENGUAJE UBIQUITO de la sistema:
Cuando usamos el patrón de diseño técnico en la capa de dominio, tenemos que agregar una motivación adicional, otra capa de significado. Cuando la ESTRATEGIA corresponde a una estrategia o política comercial real, el patrón se convierte en algo más que una técnica de implementación útil (aunque eso también es valioso en la medida de lo posible). [Capítulo 12]
Evans argumenta que alinear el modelo de software con el modelo profundo del dominio comercial es un objetivo difícil de alcanzar, pero que proporciona una gran cantidad de valor. Si tiene razón, entonces tal vez la "declaración más profunda" que un patrón de diseño de software necesita hacer es: ¿cómo encaja el patrón en el contexto del problema más amplio, más allá del alcance técnico estrecho del propio sistema de software?