Наследует ли Facade Design Pattern
концепцию Facade
из архитектуры? Я имею в виду, что в архитектуре термин Facade
обычно обозначает лицевую сторону или экстерьер любого здания. Служит ли Facade Design Pattern
такой же цели в архитектуре программного обеспечения? Если это так, применима ли эта концепция также к "Factory Pattern" vs "Factory"
, "Bridge Pattern" vs "Bridge"
, "Proxy Pattern" vs "Proxy"
и другим шаблонам проектирования?
Шаблон проектирования фасада против фасада из архитектуры
Ответы (3)
Facade Pattern
относится к фильтрации информации или огораживанию больших реализаций/сложных деталей.
Он служит как занавес или стена над некоторыми сложными методами или архитектурой, чтобы облегчить доступ. Вот как представлен Facade Pattern
(см. ответ здесь на тему "Что такое шаблон фасада"). Вы также можете с помощью Facade
скрыть некоторые методы или функции для своих классов.
Один из лучших примеров — паттерн Repository
. Вы можете скрыть всю логику базы данных (от DTO до бизнес-объекта) за некоторыми стенами, поскольку однажды вы можете изменить базы данных (например, SQL на MySql или Oracle, SQL на EntityFramework). Он скрывает что-то, например стену, и показывает что-то, например окна.
Для остальной части вашего списка это в значительной степени применимо.
Factory
шаблон создает объекты из определенного контекста, не раскрывая реализацию экземпляра (ваш класс вызов фабрики не создает, фабрика создает)Bridge
шаблон помогает связать абстракцию с реализацией без зависимости (я хочу сохранить в нескольких базах данных , но я хочу одну точку входа для всех реализаций разных технологий)Proxy
шаблон поместите маску перед объектами, которые вы, возможно, не хотите создавать сейчас.
Так что да, почти все паттерны в той или иной степени применимы в реальной жизни.
В общем, да. Работа над шаблоном «Банда четырех» была вдохновлена Кристофером Александром.
Кристофер Александер — архитектор, который впервые изучил модели зданий и сообществ и разработал «язык моделей» для их создания.
Я считаю, что архитектурные метафоры в значительной степени совпадают с дизайном программного обеспечения. Конечно, ни одна метафора не идеальна, поэтому вы, безусловно, можете найти и несоответствия. Правительство Франции отметило,
Поиск хороших имен был одной из самых сложных частей разработки нашего каталога.
В более общем плане вы спрашиваете: «Отражают ли названия шаблонов проектирования идею их внутреннего устройства с точки зрения реальных сущностей?»
Концептуально ответ ДА. В ваших примерах
- Фасад представляет собой сценарий, в котором скрывается набор внутренних сущностей/поведений с сущностью-координатором для выполнения операций.
- Фабрика представляет собой сценарий, в котором объект-фабрика производит/производит объекты для вас.
- Мост представляет собой сценарий соединения двух похожих, но разных (не связанных) объектов.
- Адаптер представляет собой сценарий соединения двух разных объектов.
И мы также должны заметить, что это также зависит от личного вкуса и индивидуального понимания. Например, шаблон Interpreter, введенный GoF, означает, что он изображает типичный интерпретатор (или компилятор) языка программирования. Но обычно термин «интерпретатор» означает что-то вроде переводчика, поэтому люди часто могут неправильно понять, что означает этот шаблон. Из-за этого некоторые люди предполагают, что это не очень хорошее имя для этого шаблона, и лучшей альтернативой будет какое-то имя, например «Выражение».
Итак, еще одна вещь, которую мы должны усвоить из предыдущего пункта, заключается в том, что мы не должны напрямую работать с нашим собственным пониманием того, что предлагает название шаблона, потому что оно может отличаться от того, что они означают. Сначала мы должны изучить их настоящую идею. то есть, какое программное решение они предлагают.
Пример: Образец моста предполагает наличие моста. Но с точки зрения программирования это достигается за счет отделения абстракции от реализации.