Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2017

Является ли применение шаблонов проектирования частью архитектуры приложения?

В обсуждении моей статьи "Архитектура программного обеспечения с человеческим лицом" на RSDN пользователь Eye of Hell задаёт интересный вопрос, на который я решил ответить отдельным постом:

Если предположить, что приложение достаточно большое (архитектура утилиты ping как правило тривиальна), то интересно, какие именно "шаблоны проектирования" имелись в виду относительно архитектуры. Если описанные в книге gang of four — то непонятно, какое они отношение имеют к архитектуре. Те шаблоны — это рецепты по решению небольших задач в рамках программы. Совсем небольших. Тоесть понятно что в Microsoft Word применяется шаблон проектирования "observer". Даже несколько тысячь раз применяется. Но является ли это (существенной) частью архитектуры приложения? Нельзя же сказать что "архитектуры photoshop состоит из шаблонов проектирования visitor, observer и facade". Или можно?

Пожалуй, стоит начать ответ с того, что действительно, как резонно замечено в вопросе, существует большое количество типов шаблонов проектирования. Для демонстрации этого факта обратимся к определению термина "шаблон проектирования" на Википедия:

В разработке программного обеспечения, шаблон проектирования или паттерн - повторимая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста. Обычно шаблон не является законченным образцом, который может быть прямо преобразован в код; это лишь пример решения задачи, который можно использовать в различных ситуациях. Объектно-ориентированные шаблоны показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться. «Низкоуровневые» шаблоны, учитывающие специфику конкретного языка программирования, называются идиомами. Это хорошие решения проектирования, характерные для конкретного языка или программной платформы, и потому не универсальные. На наивысшем уровне существуют архитектурные шаблоны, они охватывают собой архитектуру всей программной системы.

Английская версия статьи даёт даже больше деталей:

There are many types of design patterns including: structural design patterns, computational design patterns, algorithm strategy patterns, implementation strategy patterns and execution patterns. Structural patterns address concerns related to the high level structure of an application being developed . Computational patterns address concerns related to the identification of key computations. Algorithm strategy patterns address concerns related to high level strategies that describe how to exploit application characteristic on a computation platform. Implementation strategy patterns address concerns related to the realization of the source code to support (i) how the program itself is organized and (ii) the common data structures specific to parallel programming. Execution patterns address concerns related to the support of the execution of an application, including the strategies in executing streams of tasks and building blocks to support the synchronization between tasks.

Некоторые из перечисленных типов шаблонов можно более уверенно отнести к предмету архитектуры приложения, некоторые скорее можно назвать деталями реализации архитектуры, чем архитектурой как таковой - это только подчёркивает упомянутый в статье факт размытости понятия архитектуры и субъективности принятия решений о включении или не включении в проект приложения различных аспектов или деталей устройства системы.

Что же касается объектно-ориентированных шаблонов (aka 'Gang of Four', 'GoF'), упомянутые в вопросе, то их применение несомненно можно отнести к предмету архитектуры. Это подтверждается не только определением самих объектно-ориентированных шаблонов как шаблонов "проектирования", а не "кодирования", но и опытом применения этих шаблонов при разработке программных продуктов. Однако не стоит забывать что GoF-шаблоны - это шаблоны "мелкоузлового" проектирования, которые нельзя ставить в один ряд с "крупноузловыми" enterprise-шаблонами наподобие MVC, Client-Server или N-Tier. Если говорить на примерах архитектуры зданий, то GoF-шаблоны - это например общепринятные способы прокладки коммуникаций или планировки комнат. Автор вопроса играет словами в духе "является ли способ соединения проводов на щитке частью архитектуры многоэтажного здания" или "влияет ли положение газовой плиты на кухне квартир 3-го этажа на структуру всего дома". Думаю, любой архитектор ответит без доли сомнения, что проектирование всех этих вещей очень важно и несомненно является частью архитектуры здания. Возвращаясь к упомянутым Microsoft Word или Photoshop - как непосредственный участник процесса разработки продуктов такого уровня могу раскрыть вам небольшой секрет - в проектировании таких продуктов принимает участие не один-два, а десятки архитекторов. Из них каждый имеет свою специализацию и большинство из них занимается как раз "мелкоузловой" архитектурой, в которой применение наилучшего набора шаблонов проектирования может сыграть немалую роль. Перефразируя вопрос, можно сказать, что "архитектура Photoshop состоит из модулей A, B, C и D, организованных по enterprise-шаблону X; при проектировании модуля A были использованы GoF-шаблоны observer и facade; при проектировании модуля B был использован GoF-шаблон visitor".

Надеюсь что ответил достаточно полно, однако читая между строк вопроса, мне кажется что на самом деле вопрос звучал так: "Чем больше приложение, тем менее детально оно проектируется, тем меньше проектных деталей включается в архитектуру, так ведь?". Отвечаю: нет, как раз наоборот. Фазы проектирования небольших программ (например упомянутой утилиты ping) может не быть вовсе, проект от этого врядли пострадает, и от того какой именно GoF-шаблон применит разработчик зависит не так уж много в проекте. Однако при проектировании продуктов, рассчитанных на долгие годы сопровождения и развития, в разработку которых вкладываются сотни человеко-лет, неудачное применение молодым разработчиком GoF-шаблона в критичном месте может сыграть злую шутку, поэтому такие решения должны приниматься как минимум группой разработчиков, а более вероятно архитекторами и техническими экспертами на этапе проектирования. Таких проектрых решений в продукте принимаются тысячи, это верно, однако это никак не умаляет их значимость для системы, а как раз наоборот, значимость согласованного и синхронного применения шаблонов даже на уровне "мелкоузлового" проектирования в больших и сложных системах существенно выше.


Categories: Architecture
Posted by Vitalii Tsybulnyk on Monday, January 17, 2011 5:09 AM
Permalink | Comments (3) | Post RSSRSS comment feed

Comments (3) -

Eye of Hell Russia

Wednesday, January 19, 2011 6:54 PM

Спасибо за развернутый ответ. Теперь могу с вами согласиться — да, оно субъективно . Лично я вижу в этом одну из основных проблемм отрасли — каждый архитектор применяет архитектурное решение "фундамент" не из индустриального справочника "типовые фундаменты", а придумывает его заного, основываясь на прочитанной пять лет назад книжке "фундаменты коттеджных домов — инструкция для дачников" .

однако читая между строк вопроса, мне кажется что на самом деле вопрос звучал так: "Чем больше приложение, тем менее детально оно проектируется, тем меньше проектных деталей включается в архитектуру, так ведь?". Отвечаю: нет, как раз наоборот. Фазы проектирования небольших программ (например упомянутой утилиты ping) может не быть вовсе, проект от этого врядли пострадает, и от того какой именно GoF-шаблон применит разработчик зависит не так уж много в проекте.

Вы мне льстите. На самом деле между строк было написано "А какие еще шаблоны кроме GoF знает автор?" На вопрос меня подвигли отсылки к литературе, где как раз и рассматривались шаблоны мелкоузлового проектирования. Теперь, ознакомившись с упоминанием "enterprise-шаблонами наподобие MVC, Client-Server или N-Tier" я вижу что автор разбирается в вопросе и к высказанному можно относиться серьезно.

BTW, подскажите старику — "мелкоузловое" и "крупноузловое" проектирование — у этих терминов для софтостроения есть английские аналоги? Очень мне эти термины понравились

Vitalii Tsybulnyk United States

Wednesday, January 19, 2011 6:57 PM

В английском обычно используются термины "high-level" и "low-level", например "At a higher level there are architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system."
Но в пререводе на русский "высокоуровневые" и "низкоуровневые" звучит как-то унизительно по отношению ко вторым, поэтому я придумал эти термины "крупноузловые" и "мелкоузловые", которые мне кажутся более точными в русскоязычном употреблении.

Eye of Hell Russia

Wednesday, January 19, 2011 6:59 PM

Мне тоже нравятся. Хорошие термины, годные. Бум внедрять Smile

Add comment




  Country flag

b i u quote
Loading