 |
Separated Interface (Выделенный интерфейс)
|
|
|
|
Special Case (Особый Случай)
Паттерн проектирования Special Case
Описание Special Case
Подкласс, содержащий особую логику для отдельных ситуаций.
Null - значение в ООП - неуклюжая вещь, так как она зарубает на корню полиморфизм. Конечно, есть возможность вызова какого-либо метода на переменной заданного типа без необходимости беспокоиться о том, принадлежит ли эта переменная конкретного класса или подкласса. В строго типизированных языках эту проверку делает компилятор. Однако, из-за того, что переменная может содержать null, существует опасность возникновения ошибки во время выполнения, при вызове метода на null - смысле.
Если переменная может принимать значения null, вам нужно постоянно заботиться о проверках на null и правильной обработке null - значений. Часто, это "правильная обработка" одинакова в большинстве случаев, и все это заканчивается совершением греха дублированием кода (дословный перевод Мартина Фаулера).
Null - значение - яркий пример таких проблем, которые возникают постоянно и внезапно. А их много. Например, во многих системах приходится работать с бесконечностью, которая имеет особые правила для, например, добавление и нарушает обычные аксиомы, справедливые для натуральных чисел. Такие случаи предполагают изменение обычного поведения типа.
Вместо того, чтобы возвращать null или какое-то дополнительное значение, поверните Special Case (Особый Случай) - объект с тем же интерфейсом, но ведущий себя иначе, чем основной.
Plugin (Плагин)
Паттерн проектирования Plugin
описание Plugin
Сочетает классы во время конфигурации, а не компиляции.
Паттерн Separated Interface (Выделенный интерфейс) часто используется, когда один код выполняется в нескольких средах и требует разной реализации отдельной логики. Большинство разработчиков добиваются этого с помощью использования шаблона фабрики. Представим, что надо генерировать первичный ключ с помощью паттерна Separated Interface (Выделенный интерфейс). Можно использовать для юнит-тестирование простой объект - счетчик, а на реальной системе - последовательность из БД. Фабричный метод скорее всего будет содержать условный переход (if), проверяющий, установлен флаг тестирования, и возвращать необходим генератор ключа.
|
|
|
Как только у вас появится еще несколько фабрик - начнется путаница. Создание новой конфигурации, например "запуск юнит-тестов на БД без контроля транзакций" или "запуск на DB2 с полной поддержкой транзакций", потребует поправок в условиях в большом количестве фабрик, пересборке и переразвертивание.
Конфигурация не должна быть разбросана по приложению, также как и требовать пересборки и переразвертивания. Паттерн Plugin решает обе эти проблемы, предоставляя централизованную динамическую конфигурацию.
Gateway (Шлюз)
Паттерн проектирования Gateway
описание Gateway
Объект, который инкапсулирует доступ к внешней системе и ресурса.
Достойное ПО редко функционирует в изоляции от внешнего мира. Даже сама строго объектно- ориентированная система часто вынуждена взаимодействовать с "не объектами", например реляционная БД, CICS транзакции или структурами XML.
При доступе к такого рода внешних ресурсов, обычно используется API. Однако, API изначально является чем-то сложным, потому что принимают во внимание структуру ресурса. Каждый, кто хочет понять какой - нибудь ресурс, должен понять его API - будь то JDBC и SQL для реляционных БД или W3C или JDOM для XML. Это делает ПО не только менее понятным, но еще это делает изменения гораздо более сложными, например, если вы собираетесь перейти со временем с SQL на XML.
|
|
|
Решением здесь является обертывание всего специального API в класс, интерфейс которого выглядит как интерфейс обычного объекта. Другие объекты обращаются к ресурсу через этот Шлюз, который транслирует эти простые вызовы в соответствующую специальный API-код
Separated Interface (Выделенный интерфейс)
Паттерн проектирования Separated Interface
Описание Separated Interface
Выделение любого интерфейса к объекту в отдельный от объекта пакет
При разработке которой системы, можно добиться улучшения ее архитектуры, уменьшая связанность между ее частями. Это можно сделать так - распределив классы по отдельным пакетам и контролировать зависимости этими пакетами. Тогда можно следовать правилам о том, как классы из одного пакета могут обращаться к классам из другого пакета. Например, то, которое запрещает классам с уровня данных обращаться к классам с уровня представления.
Тем не менее, может возникнуть необходимость реализовать методы, которые противоречат основной структуре зависимостей. В таком случае можно использовать Выделенный Интерфейс, чтобы определить какой-нибудь интерфейс в одном пакете, а реализовать в другом. Таким образом, любой клиент, которому нужна зависимость от этого интерфейса может совершенно не думать о реализации доступа. Паттерн Separated Interface (Выделенный интерфейс) предоставляет хорошую точку подключения паттерна Gateway (Шлюз)
Registry (Реестр)
Паттерн проектирования Registry
описание Registry
Хорошо известный объект, который используется другими объектами для получения общих объектов и сервисов.
Когда нужно найти какой-то объект, обычно начинают с другого объекта, связанного с целевым. Например, если нужно найти все счета для покупателя, начинают, как раз с покупателя и используют его метод получения счетов. Тем не менее, в некоторых случаях нет соответствующего объекта, с которого начать. Например, известный ID покупателя, но нет ссылки на него. Тогда нужен своего рода объект - поисковый, но тогда возникает вопрос - как вы найдете сам поисковик?
Реестр (Registry) - это глобальный объект по сути своей или, по крайней мере, так выглядит - он может работать только будучи глобальным
|
|
|
