Является ли Decorator Pattern слишком много для внедрения системы заказа кофе? - PullRequest
1 голос
/ 11 июня 2009

Обновление: Поскольку мы обычно говорим, "ситуация определит, подходит ли какой-либо шаблон проектирования для работы" ... будет ли система заказа кофе в реальной жизни решаться с использованием шаблона Decorator

Является ли шаблон Decorator слишком сложным для реализации системы заказа кофе? Книга Head First Design Patterns использует ее в качестве примера, но я думаю, я бы просто использовал 2 массива или таблицы для ее реализации:

тип кофе (для французского жаркого, домашней смеси и т. Д.)
добавка (карамель, сливки, корица и т. д.)

так что это может быть 2 массива в ценах. Php или 2 таблицы в БД и считывание в 2 массива.

Когда клиент заказывает кофе, выбор подытожит цену.

Это выглядело так, как будто использование Decorator Pattern является излишним излишним, или вы думаете, что есть веская причина использовать этот шаблон на самом деле? В качестве примера, я думаю, что это хорошо, но это также странно, если это похоже на реальную проблему, которая полностью разрешима простым способом, но вместо этого используется более сложное решение.

Ответы [ 4 ]

5 голосов
/ 11 июня 2009

Это типичная проблема с примерами для абстракций более высокого уровня. Пример должен быть достаточно простым, чтобы его можно было легко понять и продемонстрировать концепции, что также означает для многих шаблонов проектирования, что его также легче реализовать другим способом.

Тем не менее, способ, которым я обычно видел описанные декораторы, - в оконных системах. У вас есть стандартное окно, и вы хотите, чтобы окна прокручивались по горизонтали и вертикали. Вы можете разделить окно на подклассы для всех возможных вариантов, или вы можете предоставить декоратор горизонтальной полосы прокрутки и декоратор вертикальной полосы прокрутки, который выполняет задачу и имеет дополнительное преимущество, заключающееся в том, что вы можете затем декорировать другие элементы управления, даже не имея подкласса даже Больше. Это (для меня) - совершенно правильное использование для Декораторов, которое передает идеи, но было бы намного труднее предоставить пример кода для.

2 голосов
/ 11 июня 2009

Проблема в том, что нет конкретного ответа на вопрос "действительно ли это будет". Зависит от программиста. Люди, кодирующие короткие примеры, могут придумать любой шаблон, который им нравится, но только тогда, когда вы знаете остальную часть системы, вы можете определить структуру.

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

Идентифицируйте код наиболее разумным способом, используя шаблоны проектирования в качестве руководств / идей. Постарайтесь забыть их имена - просто позвольте изучению шаблонов улучшить ваше программирование. (Но посмотрите их снова перед интервью!)

0 голосов
/ 12 июня 2009

Как кто-то еще упомянул, объясненный принцип может быть в некотором роде потерян на простом примере, необходимом для книги, но в реальном мире, когда вы программируете большие более сложные системы, шаблон будет лучшим выбором для удобства обслуживания.

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

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

Вот что такое шаблон декоратора.

0 голосов
/ 11 июня 2009

Они пытаются научить концепции, а не тому, как создать систему заказа кофе. Шаблон декоратора используется в гораздо более сложных ситуациях, таких как пользовательский интерфейс.

Шаблон декоратора может использоваться в таких местах, как система ввода-вывода Java. BufferedReader - это декоратор для Reader.

Этот шаблон чрезвычайно полезен, и есть места, где он находит хорошее применение.

...