Достаточно:
1) периодически чистить локальный «кэш» 1С на компьютере где проводится обновление
2) при сбое динамического обновления очистить в базе SQL таблицу Config_save (новая-непримененная структура конфигурации)
3) если п.2 не помог, проверить наличие свежих записей в таблице Config содержащие в имени файла *Commit* и удалить эти строки.
4) если п.3 не помог, подменить Config на Config предыдущей структуры, взятый из бэкапа.
Итого если без «динамического обновления» жизнь скучна, всегда имейте предыдущую версию таблицы Config.
«WS-соединение» требует полноценную лицензию, но используется пул соединений (см. документацию по настройке файла default.vrd).
По умолчанию это до 100 соединений и таймаут неиспользования 20 секунд.
Естественно пул эффективен когда множество подключений идут под одним или небольшим множеством пользователей 1С. Также настройка пула используется для ограничения максимального потребления лицензий веб-сервисом, иначе небольшой DDoS заблокирует доступ к базе других пользователей.
Запасные доложили перед самым вылетом, и тогда же установили текущее рабочее, т.к боялись повреждений механизмов при посадке. Забыли провести стерилизацию бурильной установки, т.к техники не сообщили о вмешательстве, выяснилось только когда аппарат уже улетел.
По крайней мере такая «желтушная» инфа в декабрьском номере «наука в фокусе» и других нагугливаемых новостях.
сейчас получается что:
а) была заранее (на земле) предусмотрена защита от пустот и слишком мягкого грунта. Боковые упоры. Пять лет проходили испытания на земных породах, чтобы обработать все возможные мусорные и плавящие эффекты.
б) отдельно, упонимается боязнь выделения капелек воды и контакта со сверлом, вода — «медового» вяжущего эффекта не дает.
Собственно со вторым пунктом и связаны мои комментарии, возможно это перестраховка (и задержка вызвана доп. анализами на «влажность породы») т.к сверло «грязное».
Особенность устройства дрели такова, что ей крайне противопоказаны любые жидкости.
Если частички прилипнут к внутренним поверхностям дрели, то она, как научный прибор, будет потеряна...
Возможно и несвязано, но буквально сегодня прочитал («наука в фокусе» за декабрь 2012), что сверло было установлено еще на земле, за 6 месяцев до полета, т.к опасались что посадка будет «жесткой» и установить его удаленно не получится. При этом была нарушена стирильность установки и соприкосновение с водой нежелательно т.к возможно «оживление» земных микробов.
Чтобы не возникало ощущения противоречия между великолепной и фундаментальной работой Г. Буча и паттернами «Банды четырех» добавлю, что паттерны рекомендованы Бучем к ознакомлению после главы 4. Которая посвящена принципам классификации/категоризации.
Большая работа была проведена в области каталогизации программного обеспечения, в частности, в области классификации идиом, механизмов и принципов. С этой точки зрения большой интерес представляют работы Гамма и др. (Gamma et al.) [E 1995],
Г. Буч
Реализация автомобиля инженерами Автоваза почему то отличается от реализации автомобиля инженерами BMW.
Поймите не каждая система из 10 миллионов логических вентилей автоматически станет процессором. Но без знания базовых элементов вы тем более не сможете спроектировать процессор.
Если у вас есть уникальные идеи по архитектуре ПО, то оформите их по аналогии в описанием паттернов. Назначение, Имя, Техника, Примеры (можно Open Source).
Это будет более конструктивно.
как же не учитывать формулировку разделения абстракции и реализации?
Оставьте формулировку оригинального GoF. Вы не первый у кого она вызывает вопросы, но люди не пытаются отрицать, а пытаются понять что имелось в виду.
К тому же не забываем 3-е бандитов были практиками С++, а один ученым и практиком Smalltalk. Прочитайте про шаблон Мulticast, в течении нескольких лет 3-е видели шаблон, а программист на Smalltalk в упор не понимал о чем речь. По «мосту» эти четверо хотя бы понимали друг друга.
Даю подсказку посмотрите на структурные схемы Моста, Стратегии, Состояния. Удалите все названия классов и попробуйте найти отличия. GoF нас дрессируют объясняя очень важные вещи простым языком наметафор, «рефлексов».
Метод DrawRectangle() находится на функциональном уровне, а DrawLine() на уровне платформенных реализаций
Вы пишите «финансовый калькулятор для расчета рисков» который работает во множестве браузеров/платформ, которому лишь нужно пару фигурных стрелочек, да прямоугольников для подсветки важный чисел.
Вы серьезно думаете что клиент вам заплатит за год который вы потратите на построение универсальной графической модели?
«Мост» это не самоцель — это начальный шаг, пожалуйста развивайте модель, GoF вас к этому и подталкивает неужели не понятно он говорит «запутались в связях своей модели, давайте разорвем иерархии минимизируем зависимость и начнем все сначала».
Формулировка «моста» на которой остановились А. Шаллоуей, Дж. Тротт в своей книге
Классы производные от абстрактного класса, должны использовать множество классов реализации этой абстракции. Не вызывая при этом лавинообразного увеличения кол-ва классов в системе
Речь идет о книге А. Шаллоуей, Дж. Тротт — Шаблоны проектирования.
Каким образом нотация БедныйХудожник.Нарисуй(МиллионАлыхРоз) решает проблему того, что реальное рисование выполняется c сторонних программам?..
Художник (компонент) предоставляет другому компоненту API (набор графических примитивов), для реализации которых он полагается на сторонние программы. Отношение Фигура — Кисть в исходной постановке скрыто в Художнике. Акцент идет на вариантах реализации кисти.
Итоговая формулировка А. Шаллоуей, Дж. Тротт позиционирует «мост» как прием управления мультиплексией связей.
Давайте боротся нее с формулировкой GoF (абстракция, реализация), а просто найдем «зерно», отражающее суть приема.
Обвинять мультиплексор в том, что он помешал реализовать супер-процессор убийцу Intel как то не очевидно. При проектировании думать надо о процессоре, а не логическом вентиле.
Есть однако и правило о нарушении правил: прежде чем нарушать правило, необходимо его как следует выучить.
Робин Вильямс
В реальном мире однако, мы вначале обнаруживаем частный случай и лишь затем открываем общую абстракцию.
Бертран Мейер
Создание сложных, хорошо проработанных моделей предметных областей возможно, и они стоят затраченного на них труда, но прогресс не идет плавно и последовательно, переход к действительно глубокой по смыслу модели — это огромный качественный скачок, который требует радикального изменения архитектуры. Не пытайтесь искуственно вызвать такой скачок, большую часть работы занимают мелкие фрагментированные изменения приближающие вас к пониманию предметной области.
Качественный скачок требует полномасштабного перепроектирования и смелости.
Эрик Эванс
Удача — это основа проектирования.
Бранч Рики
Все модели неверны, но некоторые из них полезны.
Джордж Бокс
Программы на самом деле не существует. Совершенно нормально планировать работу так, будто вы строите объект недвижимости, — просто не удивляйтесь, когда кто-либо потребует его передвинуть.
Чед Лавиль
Да, это прием управления эффектом мультиплексии структурных элементов.
Но не ограничивается этим и содержит ряд инвариантов (ограничений) которые показывают границы структуры компонента.
— «независимость иерархий» лишь логическое понятие, достигаемое:
а) откладыванием связывания до момента выполнения.
б) однонаправленной ассоциацией. ThreadSheduler знает о Вариантах реализации, обратная зависимость нежелательна.
в) ThreadSheduler_Implementation всей функциональностью подчинен только потребностям ThreadSheduler. Т.е явное отношение «Ведущий — ведомый».
г) ThreadSheduler не самодостаточен без ThreadSheduler_Implementation. Т.е все время пока существует ThreadSheduler ссылка на ThreadSheduler_Implementation должна быть не Null.
д) ThreadSheduler_Implementation используется только ThreadSheduler. Отношение Public use Private. Здесь можно сравнить с «жемчужиной». Все сторонние компоненты видят только «раковину» т.е ThreadSheduler, внутри которого кристаллизуется «жемчужина» ThreadSheduler_Implementation. По мере возрастания «ценности жемчужины» она впосле может отправится в самостоятельное плавание.
При соблюдении всех инвариантов «мост» приобретает четкие границы, и явно отражает структуру единого компонента, а не масштабируется до любых горизонтальных стрелочек.
Про адаптеры:
В приведенном примере UnixPTS, WindowsPTS и.д. естественно не наследуются и никак не зависят от ThreadSheduler_Implementation. Просто имена немного неудачные, сами по себе это отдельные самодостаточные «компоненты», которые лишь используются для платформенно-зависимой реализации.
Т.е по факту у нас будет некие ThreadSheduler_UnixPTSImplementation реализующие нужды ThreadSheduler (это первично), в своей внутренней реализации использующие соответствующие платформенные примитивы. Т.е адартер вторичен и скрыт во внутренней логике.
Связь ThreadSheduler -> ThreadSheduler_UnixPTSImplementation будет «Мостом»
Связь ThreadSheduler_UnixPTSImplementation -> UnixPTS будет адаптером.
В этом разница между шалонами Стратегия и Состояние, в первом мы акцентируемся на алгоритме обработки (контекст и данные передаются как входные) во втором на полном состоянии объекта.
«вы сами определяется интерфейс для будущих реализаций»
об этом и идет речь когда выясняем кто-кому подчинен.
«реализация != алгоритм?»
В ООП да, под реализацией объекта понимается сочетание Данные + Алгоритмы обработки. Алгоритм по по себе не имеет состояния кроме тех данных, что он получил как входные.
— все методы EntityStorage подчинены потребностям EntityRepository
— EntityStorage используется только EntityRepository
— Любой Entity требует для полноценного функционирования EntityStorage
— EntityStorage ничего не знает о EntityRepository, например передача Entity в методы EntityStorage приводит к переходу от однонаправленной зависимости к двунаправленной, что здорово ограничивает возможности «независимого» развития.
В вашем случае достаточно высокоуровневая конструкция и реальным шаблоном является Хранилище(Repository) из практик DDD.
Посмотрите позиционирование GoF по мнению Ричарда Хелми в начале статьи.
С GoF шаблон Repository пересекается лишь на уровне базового принципа «инкапсуляция точек вариации» т.е в данном случае вариация в способе сохранения в Storage.
При всей простоте принципа «вариация» он фундаментален и масштабируем до уровня высокоуровневой архитектуры.
В этом единство шаблонов GoF, когда разработчик слышит «хочу менять алгоритмы» он говорит «Стратегия», слышит «хочу менять реализацию» говорит «мост», слышит «хочу менять внутренне состояние объекта» говорит «состояние», но фокус в том, что получившаяся структурная диаграмма и базовый принцип неотличимы. Различаются мотивации. Такая вот педагогический прием ориентация на «рефлекс» разработчика, «триггер» который щелкает при ключевых словах/метафорах. Даже если вся базовые принципы сведены к двум перечисленным в начале статьи.
Проблема в том, что вы говорите о тех принципах которые лежат в основе Domain-driven design. Интуитивно или осознанно, не знаю. Тем не менее мне бы хотелось подчеркнуть к исходному паттерну «Мост» из GOF это не имеет никакого отношения. Этот паттерн не архитектурный и тем более не наделен высшим смыслом с точки зрения моделирования предметной области.
Модель — это дистиллированнное знание (только существенные аспекты действительности).
Техники GOF построены на двух базовых принципах:
— найдите точки изменений и инкапсулируйте их.
— композиция объектов предпочтительнее наследования.
Следствие первое: найдите границы системы, т.к рассуждения о «семантике» и абсолютной истинности модели это бесконечный филосовский спор.
Давайте еще раз взглянем на паттерн «Мост», читаем GOF:
— это шаблон структуры уровня компонента
— это шаблон времени проектирования
— это шаблон заменяющий наследование
— это контекст для применения других шаблонов
Следствие второе: речь идет об одном компоненте, т.е мы разбиваем одни компонент (единую концепцию) на две иерархии. Следствие третье: и оно очень удачно подмечено у Алан Шаллоуей, Джеймс Р. Тротт. Структура иерархии «Реализации» подчинена потребностям базовой иерархии «Абстракция». Говоря по другому в «Реализации» инкапсулированы возможные точки изменения базовой концепции. Следование третье: переход к разделению иерархий начинается если здесь и сейчас (в момент проектирования модели) вы столкнулись с лавиноообразным ростом кол-ва классов подлежащих разработке при использовании наследования.
Ибо т.к это один компонент, то возможно любое сочетание Абстракция — Реализация. Вспомним альтернативное название шаблона «Описание — тело».
Математический критерий прост, более 2-х абстракций и более 4-х вариантов реализации.
Мост позволяет заменить композиционный взрыв линейным ростом числа классов подлежащих разработке. Следствие четвертое: Обеспечение связи любая Абстракция — любая Реализация возлагается на Абстрактную фабрику, Фабричный метод, контейнер зависимостей и т.д. В общем «конфигурирование» откладывается до момента выполнения. Следствие пятое: GOF не определяет «семантику», а лишь технику реализации, возможность «выстрелить себе в ногу» остается за проектировщиком.
Учитывая все вышеперечисленное считаю главной проблемой данного шаблона не очень верную метафору. Вместо строительной, лучше подходит схемотехника, а именно элемент Мультиплексор. Аналоги Телефонный коммутатор, Общая шина и т.п.
Следствие неудачной метаформы то, что любую горизонтальную стрелочку между двумя прямоугольниками именуют «Мостом», и вы правы в 99% случаев это обычная композиция.
Пример:
Car — Engine — это не мост, а обычная композиция, правильный пример отражающий особенности реализации единого компонента (см следствие второе) Автомобиль [Легковой, Грузовой, Автобус] -> [Бумажный прототип, Компьютерный прототип, Физический прототип, Серийная модель].
Ответ на ваш вопрос "… ну объясните мне чем реализация рисования линии отличается от реализации рисования прямоугольника. Ничем. А почем же тогда одно находится в абстракции, а другое в реализации?".
Авторам не нужна реализация прямоугольника, это всего провести 4 линии, но рисование даже такого примитива как линия оказывается завязано на платформенные особенности, которые они успешно инкапсулировали.
И на этом стоп, вот это граница системы.
В дальнейшем при возникновении потребностей, например в Эллипсе, потребуется пересмотреть модель возможно действительно выделить универсальную графическую библиотеку, но это будет совсем другая история, другая модель в которой исходный компонент рассыпался на действительно независимые сущности, а это уже не Мост, см. следствие второе…
Спор о «семантике», абсолютной верности модели не имеет к шаблону никакого отношения.
Советую вам забыть все прочитанное на хабре про паттерн «мост» за последнюю неделю и прочитать:
1) GOF — особенно разделы 'мотивация' и 'известные применения' для данного шаблона
2) затем обязательно Алан Шаллоуей, Джеймс Р. Тротт Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию. Главу посвященную именно шаблону «мост».
Приведу для затравки лишь одну цитату из второй книги посвященную именно данному патерну " Хм, ерунда какая-то!.. Я понимаю каждое слово в этом предложении (о формулировке GOF), но не имею ни малейшего представления, что оно может означать." (с)
Чуть выше в этом посте я уже приводил основную суть данного шаблона и критерии применимости здесь лишь добавлю, что удачной метафорой для «моста» является не строительная, а схемотехническая т.н элемент Мультиплексор (или например Общая шина).
2) При кол-ве классов (Варианты абстракции + Варианты реализации) < 6 паттерн «Мост» не дает никаких преимуществ по сравнению с обычным наследованием. Причем подразумевается, что кол-во вариантов абстракций > 1.
Например в приведенной в посте схеме достаточно всего трех классов (1 абстракция + 2 наследника (или реализации интерфейса). И даже если у вас будет еще 10 вариантов ТV все они будут реализацией одной абстракции.
Для демонстрации «моста» нужно приводить реальный пример с соотношением (3:3, 3:4 и выше).
Собственно задача управления кол-вом классов (сложностью модели) и является мотивом к разделению иерархий.
1) периодически чистить локальный «кэш» 1С на компьютере где проводится обновление
2) при сбое динамического обновления очистить в базе SQL таблицу Config_save (новая-непримененная структура конфигурации)
3) если п.2 не помог, проверить наличие свежих записей в таблице Config содержащие в имени файла *Commit* и удалить эти строки.
4) если п.3 не помог, подменить Config на Config предыдущей структуры, взятый из бэкапа.
Итого если без «динамического обновления» жизнь скучна, всегда имейте предыдущую версию таблицы Config.
По умолчанию это до 100 соединений и таймаут неиспользования 20 секунд.
Естественно пул эффективен когда множество подключений идут под одним или небольшим множеством пользователей 1С. Также настройка пула используется для ограничения максимального потребления лицензий веб-сервисом, иначе небольшой DDoS заблокирует доступ к базе других пользователей.
По крайней мере такая «желтушная» инфа в декабрьском номере «наука в фокусе» и других нагугливаемых новостях.
а) была заранее (на земле) предусмотрена защита от пустот и слишком мягкого грунта. Боковые упоры. Пять лет проходили испытания на земных породах, чтобы обработать все возможные мусорные и плавящие эффекты.
б) отдельно, упонимается боязнь выделения капелек воды и контакта со сверлом, вода — «медового» вяжущего эффекта не дает.
Собственно со вторым пунктом и связаны мои комментарии, возможно это перестраховка (и задержка вызвана доп. анализами на «влажность породы») т.к сверло «грязное».
news.rambler.ru/15484602/
Так, что очень похоже, что это не особенность «дрели», а перестраховка.
Возможно и несвязано, но буквально сегодня прочитал («наука в фокусе» за декабрь 2012), что сверло было установлено еще на земле, за 6 месяцев до полета, т.к опасались что посадка будет «жесткой» и установить его удаленно не получится. При этом была нарушена стирильность установки и соприкосновение с водой нежелательно т.к возможно «оживление» земных микробов.
Чтобы не возникало ощущения противоречия между великолепной и фундаментальной работой Г. Буча и паттернами «Банды четырех» добавлю, что паттерны рекомендованы Бучем к ознакомлению после главы 4. Которая посвящена принципам классификации/категоризации.
Большая работа была проведена в области каталогизации программного обеспечения, в частности, в области классификации идиом, механизмов и принципов. С этой точки зрения большой интерес представляют работы Гамма и др. (Gamma et al.) [E 1995],
Г. Буч
Реализация автомобиля инженерами Автоваза почему то отличается от реализации автомобиля инженерами BMW.
Поймите не каждая система из 10 миллионов логических вентилей автоматически станет процессором. Но без знания базовых элементов вы тем более не сможете спроектировать процессор.
Если у вас есть уникальные идеи по архитектуре ПО, то оформите их по аналогии в описанием паттернов. Назначение, Имя, Техника, Примеры (можно Open Source).
Это будет более конструктивно.
Оставьте формулировку оригинального GoF. Вы не первый у кого она вызывает вопросы, но люди не пытаются отрицать, а пытаются понять что имелось в виду.
К тому же не забываем 3-е бандитов были практиками С++, а один ученым и практиком Smalltalk. Прочитайте про шаблон Мulticast, в течении нескольких лет 3-е видели шаблон, а программист на Smalltalk в упор не понимал о чем речь. По «мосту» эти четверо хотя бы понимали друг друга.
Даю подсказку посмотрите на структурные схемы Моста, Стратегии, Состояния. Удалите все названия классов и попробуйте найти отличия. GoF нас дрессируют объясняя очень важные вещи простым языком наметафор, «рефлексов».
Метод DrawRectangle() находится на функциональном уровне, а DrawLine() на уровне платформенных реализаций
Вы пишите «финансовый калькулятор для расчета рисков» который работает во множестве браузеров/платформ, которому лишь нужно пару фигурных стрелочек, да прямоугольников для подсветки важный чисел.
Вы серьезно думаете что клиент вам заплатит за год который вы потратите на построение универсальной графической модели?
«Мост» это не самоцель — это начальный шаг, пожалуйста развивайте модель, GoF вас к этому и подталкивает неужели не понятно он говорит «запутались в связях своей модели, давайте разорвем иерархии минимизируем зависимость и начнем все сначала».
Классы производные от абстрактного класса, должны использовать множество классов реализации этой абстракции. Не вызывая при этом лавинообразного увеличения кол-ва классов в системе
Каким образом нотация БедныйХудожник.Нарисуй(МиллионАлыхРоз) решает проблему того, что реальное рисование выполняется c сторонних программам?..
Художник (компонент) предоставляет другому компоненту API (набор графических примитивов), для реализации которых он полагается на сторонние программы. Отношение Фигура — Кисть в исходной постановке скрыто в Художнике. Акцент идет на вариантах реализации кисти.
Итоговая формулировка А. Шаллоуей, Дж. Тротт позиционирует «мост» как прием управления мультиплексией связей.
Давайте боротся нее с формулировкой GoF (абстракция, реализация), а просто найдем «зерно», отражающее суть приема.
Обвинять мультиплексор в том, что он помешал реализовать супер-процессор убийцу Intel как то не очевидно. При проектировании думать надо о процессоре, а не логическом вентиле.
Есть однако и правило о нарушении правил: прежде чем нарушать правило, необходимо его как следует выучить.
Робин Вильямс
В реальном мире однако, мы вначале обнаруживаем частный случай и лишь затем открываем общую абстракцию.
Бертран Мейер
Создание сложных, хорошо проработанных моделей предметных областей возможно, и они стоят затраченного на них труда, но прогресс не идет плавно и последовательно, переход к действительно глубокой по смыслу модели — это огромный качественный скачок, который требует радикального изменения архитектуры. Не пытайтесь искуственно вызвать такой скачок, большую часть работы занимают мелкие фрагментированные изменения приближающие вас к пониманию предметной области.
Качественный скачок требует полномасштабного перепроектирования и смелости.
Эрик Эванс
Удача — это основа проектирования.
Бранч Рики
Все модели неверны, но некоторые из них полезны.
Джордж Бокс
Программы на самом деле не существует. Совершенно нормально планировать работу так, будто вы строите объект недвижимости, — просто не удивляйтесь, когда кто-либо потребует его передвинуть.
Чед Лавиль
Да, это прием управления эффектом мультиплексии структурных элементов.
Но не ограничивается этим и содержит ряд инвариантов (ограничений) которые показывают границы структуры компонента.
— «независимость иерархий» лишь логическое понятие, достигаемое:
а) откладыванием связывания до момента выполнения.
б) однонаправленной ассоциацией. ThreadSheduler знает о Вариантах реализации, обратная зависимость нежелательна.
в) ThreadSheduler_Implementation всей функциональностью подчинен только потребностям ThreadSheduler. Т.е явное отношение «Ведущий — ведомый».
г) ThreadSheduler не самодостаточен без ThreadSheduler_Implementation. Т.е все время пока существует ThreadSheduler ссылка на ThreadSheduler_Implementation должна быть не Null.
д) ThreadSheduler_Implementation используется только ThreadSheduler. Отношение Public use Private. Здесь можно сравнить с «жемчужиной». Все сторонние компоненты видят только «раковину» т.е ThreadSheduler, внутри которого кристаллизуется «жемчужина» ThreadSheduler_Implementation. По мере возрастания «ценности жемчужины» она впосле может отправится в самостоятельное плавание.
При соблюдении всех инвариантов «мост» приобретает четкие границы, и явно отражает структуру единого компонента, а не масштабируется до любых горизонтальных стрелочек.
Про адаптеры:
В приведенном примере UnixPTS, WindowsPTS и.д. естественно не наследуются и никак не зависят от ThreadSheduler_Implementation. Просто имена немного неудачные, сами по себе это отдельные самодостаточные «компоненты», которые лишь используются для платформенно-зависимой реализации.
Т.е по факту у нас будет некие ThreadSheduler_UnixPTSImplementation реализующие нужды ThreadSheduler (это первично), в своей внутренней реализации использующие соответствующие платформенные примитивы. Т.е адартер вторичен и скрыт во внутренней логике.
Связь ThreadSheduler -> ThreadSheduler_UnixPTSImplementation будет «Мостом»
Связь ThreadSheduler_UnixPTSImplementation -> UnixPTS будет адаптером.
об этом и идет речь когда выясняем кто-кому подчинен.
«реализация != алгоритм?»
В ООП да, под реализацией объекта понимается сочетание Данные + Алгоритмы обработки. Алгоритм по по себе не имеет состояния кроме тех данных, что он получил как входные.
— все методы EntityStorage подчинены потребностям EntityRepository
— EntityStorage используется только EntityRepository
— Любой Entity требует для полноценного функционирования EntityStorage
— EntityStorage ничего не знает о EntityRepository, например передача Entity в методы EntityStorage приводит к переходу от однонаправленной зависимости к двунаправленной, что здорово ограничивает возможности «независимого» развития.
В вашем случае достаточно высокоуровневая конструкция и реальным шаблоном является Хранилище(Repository) из практик DDD.
Посмотрите позиционирование GoF по мнению Ричарда Хелми в начале статьи.
С GoF шаблон Repository пересекается лишь на уровне базового принципа «инкапсуляция точек вариации» т.е в данном случае вариация в способе сохранения в Storage.
При всей простоте принципа «вариация» он фундаментален и масштабируем до уровня высокоуровневой архитектуры.
В этом единство шаблонов GoF, когда разработчик слышит «хочу менять алгоритмы» он говорит «Стратегия», слышит «хочу менять реализацию» говорит «мост», слышит «хочу менять внутренне состояние объекта» говорит «состояние», но фокус в том, что получившаяся структурная диаграмма и базовый принцип неотличимы. Различаются мотивации. Такая вот педагогический прием ориентация на «рефлекс» разработчика, «триггер» который щелкает при ключевых словах/метафорах. Даже если вся базовые принципы сведены к двум перечисленным в начале статьи.
Удачи в поисках.
Техники GOF построены на двух базовых принципах:
— найдите точки изменений и инкапсулируйте их.
— композиция объектов предпочтительнее наследования.
Следствие первое: найдите границы системы, т.к рассуждения о «семантике» и абсолютной истинности модели это бесконечный филосовский спор.
Давайте еще раз взглянем на паттерн «Мост», читаем GOF:
— это шаблон структуры уровня компонента
— это шаблон времени проектирования
— это шаблон заменяющий наследование
— это контекст для применения других шаблонов
Следствие второе: речь идет об одном компоненте, т.е мы разбиваем одни компонент (единую концепцию) на две иерархии.
Следствие третье: и оно очень удачно подмечено у Алан Шаллоуей, Джеймс Р. Тротт. Структура иерархии «Реализации» подчинена потребностям базовой иерархии «Абстракция». Говоря по другому в «Реализации» инкапсулированы возможные точки изменения базовой концепции.
Следование третье: переход к разделению иерархий начинается если здесь и сейчас (в момент проектирования модели) вы столкнулись с лавиноообразным ростом кол-ва классов подлежащих разработке при использовании наследования.
Ибо т.к это один компонент, то возможно любое сочетание Абстракция — Реализация. Вспомним альтернативное название шаблона «Описание — тело».
Математический критерий прост, более 2-х абстракций и более 4-х вариантов реализации.
Мост позволяет заменить композиционный взрыв линейным ростом числа классов подлежащих разработке.
Следствие четвертое: Обеспечение связи любая Абстракция — любая Реализация возлагается на Абстрактную фабрику, Фабричный метод, контейнер зависимостей и т.д. В общем «конфигурирование» откладывается до момента выполнения.
Следствие пятое: GOF не определяет «семантику», а лишь технику реализации, возможность «выстрелить себе в ногу» остается за проектировщиком.
Учитывая все вышеперечисленное считаю главной проблемой данного шаблона не очень верную метафору. Вместо строительной, лучше подходит схемотехника, а именно элемент Мультиплексор. Аналоги Телефонный коммутатор, Общая шина и т.п.
Следствие неудачной метаформы то, что любую горизонтальную стрелочку между двумя прямоугольниками именуют «Мостом», и вы правы в 99% случаев это обычная композиция.
Пример:
Car — Engine — это не мост, а обычная композиция, правильный пример отражающий особенности реализации единого компонента (см следствие второе) Автомобиль [Легковой, Грузовой, Автобус] -> [Бумажный прототип, Компьютерный прототип, Физический прототип, Серийная модель].
Ответ на ваш вопрос "… ну объясните мне чем реализация рисования линии отличается от реализации рисования прямоугольника. Ничем. А почем же тогда одно находится в абстракции, а другое в реализации?".
Авторам не нужна реализация прямоугольника, это всего провести 4 линии, но рисование даже такого примитива как линия оказывается завязано на платформенные особенности, которые они успешно инкапсулировали.
И на этом стоп, вот это граница системы.
В дальнейшем при возникновении потребностей, например в Эллипсе, потребуется пересмотреть модель возможно действительно выделить универсальную графическую библиотеку, но это будет совсем другая история, другая модель в которой исходный компонент рассыпался на действительно независимые сущности, а это уже не Мост, см. следствие второе…
Спор о «семантике», абсолютной верности модели не имеет к шаблону никакого отношения.
1) GOF — особенно разделы 'мотивация' и 'известные применения' для данного шаблона
2) затем обязательно Алан Шаллоуей, Джеймс Р. Тротт Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию. Главу посвященную именно шаблону «мост».
Приведу для затравки лишь одну цитату из второй книги посвященную именно данному патерну
" Хм, ерунда какая-то!.. Я понимаю каждое слово в этом предложении (о формулировке GOF), но не имею ни малейшего представления, что оно может означать." (с)
Чуть выше в этом посте я уже приводил основную суть данного шаблона и критерии применимости здесь лишь добавлю, что удачной метафорой для «моста» является не строительная, а схемотехническая т.н элемент Мультиплексор (или например Общая шина).
Например в приведенной в посте схеме достаточно всего трех классов (1 абстракция + 2 наследника (или реализации интерфейса). И даже если у вас будет еще 10 вариантов ТV все они будут реализацией одной абстракции.
Для демонстрации «моста» нужно приводить реальный пример с соотношением (3:3, 3:4 и выше).
Собственно задача управления кол-вом классов (сложностью модели) и является мотивом к разделению иерархий.