Какие соглашения об именах используются для шаблона Decorator?

У меня были трудности с именами классов Decorator, поэтому я просто хотел бы знать, что делают другие. Всегда ли вы добавить слово Decorator? Вы включаете название интерфейса, его оформление? Получают ли они свое собственное пространство имен?

Ответ 1

Я избегаю использования имен шаблонов проектирования. Я думаю, что это относится к документации, если где угодно. Назовите класс/функцию декоратора после того, что он делает или представляет. Тот факт, что он украшает или мосты, или ссылки, или прокси-серверы или повторное представление, не имеет большого значения.

Каждый раз, когда вы называете строку, вы добавляете строковый суффикс? Звучит как hgrnNotation для меня, и это то, чего я стараюсь избегать.

Ответ 2

Возьмем пример из IO Framework Java API. Он широко использует шаблон декоратора, но имена классов не отражают этого. Например, BufferedReader может украсить FileReader. Но они названы в честь их функции - "Читатели".

Добавление декоратора к названию приведет к дальнейшим проблемам, если вы также включите другие шаблоны, включающие те же классы, что и часто. Вы можете получить класс с именем MyDecoratorStrategyComponent.

Ответ 3

Назовите это, что он делает.

У меня есть набор декораторов для интерфейса IPrinter. Они называются:

PrintDisasterRecovery - исключение обработка
PrintQueuer - делает это асинхронный вызов

Эти главы как наследуются от PrintDecorator, так что, если кто-то заглядывает под обложки, они могут видеть, что происходит.

Ответ 4

В общем случае, когда шаблон инкапсулируется в объект (по сравнению с набором объектов), тогда он становится яснее и проще включать имя шаблона в класс, в этом случае используя Decorator в качестве суффикса. Эта работа хорошо подходит для прокси-серверов, декораторов, фабрик, адаптеров и т.д., Но не работает для других шаблонов, где требуется группа объектов для реализации шаблона, такого как мост (то есть, какой объект будет подходящим образом принимать суффикс -bridge?)