My<cod/>.net
За пределами шаблонов проектирования?
За последние 10 лет или около того было небольшое количество статей и статей, ссылающихся на новую работу Кристофера Александера "The Nature of Order" и как ее можно применить к программному обеспечению.
К сожалению, единственные работы, которые я могу найти, принадлежат Джеймсу Коплиену и Ричарду Гэбриэлу; кроме этого нет ничего, по крайней мере, из моих попыток найти такие вещи через google.
Происходит ли где-нибудь подобное обсуждение?
MSN
@Georgia
Мой вопрос не о шаблонах дизайна или языках шаблонов; речь идет о попытке увидеть, можно ли применить больше работы Кристофера Александра к программному обеспечению (что, вероятно, возможно, поскольку у него еще меньше физических ограничений, чем у архитектуры и строительства).
Шаблоны дизайна и языки шаблонов, похоже, охватили структуру шаблонов дизайна Александра, но не многие из них отражают суть. Суть заключается в том, что нечто выходит за рамки решения проблемы в конкретном контексте.
Это трудно объяснить, не используя некоторые из более поздних работ Александра в качестве ориентира.
Edit: Нет, я беру свои слова обратно.
Например, есть архитектурный шаблон дизайна, который называется альковами. Эта модель имеет контекст, который не только коренится в обстоятельствах ситуации, но и коренится в основах назначения зданий: что они являются структурами, в которых можно жить, и должны способствовать проживанию в них. В случае с моделью алькова контекст заключается в том, что вы хотите, чтобы область, которая позволяет нескольким людям находиться в одной и той же области, занимаясь разными вещами, потому что для членов семьи важно физически быть вместе, а также иметь возможность делать вещи, которые, как правило, отвлекают других членов семьи.
Большинство шаблонов проектирования программного обеспечения описывают проблему в контексте, но они не делают более глубокого заявления о том, почему проблема важна или почему проблема является чем-то фундаментальным для программного обеспечения. Это делает его очень легко применять шаблоны проектирования неуместно или беспечно, что является полной противоположностью намерению шаблонов проектирования, чтобы начать С.
MSN
Ваш вопрос напоминает некоторые комментарии, сделанные Эриком Эвансом в его книге "Domain-Driven Design". Он указывает, что шаблоны проектирования при разработке программного обеспечения часто описываются как строго технические решения технических проблем. Но иногда появляется возможность применить шаблон, который не только придает структуру программной реализации, но и имеет смысл в бизнес-модели.
Например, рассмотрите использование шаблона STRATEGY как просто деталь реализации, по сравнению с тем случаем, когда программистам и бизнесу действительно имеет смысл говорить о том, как выбираются и используются STRATEGIES, т. е. когда он является частью вездесущего языка системы:
Когда мы используем шаблон технического проектирования в доменном слое, мы должны добавить дополнительную мотивацию, еще один слой смысла. Когда STRATEGY соответствует реальной бизнес-стратегии или политике, шаблон становится больше, чем просто полезным методом реализации (хотя это тоже ценно, насколько это возможно). [Глава 12]
Эванс утверждает, что согласование модели программного обеспечения с глубинной моделью бизнес-области-это трудная цель для достижения, но та, которая обеспечивает огромную ценность. Если он прав, то, возможно, "deeper statement", что шаблон проектирования программного обеспечения должен сделать: как шаблон вписывается в более широкий контекст проблемы, за пределами узкой технической области самой программной системы.
Попробуйте начать с http://c2.com/cgi/wiki?NatureOfOrder или http://c2.com/cgi/wiki?HowNatureOfOrderAppliesToSoftware