Может ли шаблон декоратора быть заменен поведенческим шаблоном для решения проблемы?

Question

Я читал и видел много примеров, описывающих, почему декоратор является структурным шаблоном.И как это составляет объекты, чтобы добавить новые функциональные возможности.В то время как шаблон Visitor помогает с добавлением новых функций к объекту.И стратегия заключается в том, чтобы менять алгоритм во время выполнения.

Я до сих пор не могу понять, почему шаблон декоратора является структурным, а не поведенческим шаблоном.

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

Было бы действительно полезно взять реальный проект системы, разбитый на более мелкие проблемы ипримените все эти шаблоны проектирования.

РЕДАКТИРОВАТЬ: взял следующий сценарий использования, чтобы применить и понять различные шаблоны проектирования.Пожалуйста, поделитесь своими мыслями по этому примеру.

Голосовая интерактивная система для Музея, где дети могут спросить что угодно, получить информацию об этом и забронировать билеты на любые шоу.Например: ребенок спрашивает, что такое солнечная система, а затем детализирует вопросы о планетах.Затем закажите билеты на шоу планетария.

Здесь приведены технические примеры использования шаблонов проектирования.Пожалуйста, помогите выбрать правильные шаблоны дизайна для каждого случая: 1) Слушайте вопросы ребенка и анализируйте данные из него.2) Определите, запрашивает ли ребенок информацию или запрашивает направление или хочет забронировать билет и т. Д. 3) На основе намерений ребенка ответьте или соберите дополнительную информацию, чтобы забронировать билет или запланировать групповой тур.4) Управление разговорами и контекстными данными.5) Позвоните в API, чтобы получить ответ или закажите тур.

Хотел бы применить шаблоны проектирования, чтобы система могла следовать принципам SOLID.Требования к дизайну для каждого из приведенных выше вариантов использования: 1) Без изменения существующего кода система должна принимать новые методы ввода (касание, голос, клавиатура, мышь), следуя OCP.Также принимайте новые сенсорные сигналы, такие как реакция лица, пока дети задают вопрос.2) Система должна быть расширяемой для поддержки новых намерений пользователя.3) На некоторые вопросы есть прямые ответы, а в некоторых случаях требуются дополнительные вопросы, чтобы получить больше информации от детей (экскурсия по книге).Здесь каждый разговор делает подобные вещи (слушает ребенка, система что-то делает, отвечает ребенку с последующим наблюдением или ответом).Может ли здесь использоваться шаблон проектирования декоратора для создания объектов, таких как родительский объект (чтобы получить то, что хочет сделать ребенок) и дочерние объекты (чтобы получить дополнительные сведения для экскурсии по книге) 4) Должен иметь возможность повторно использовать один и тот же дизайн для управления любымпоток вопросов вперед и назад и управлять данными контекста.5) свободная привязка API, замена API по мере необходимости, поддержка API от разных провайдеров для бронирования туров, ответов на вопросы и т. Д. (Шаблон стратегии?).Если для участия в конкурсе участвуют несколько API, и система выбирает один API, то какой шаблон будет хорошим для использования.

Система должна быть расширяемой для поддержки новых сценариев использования, таких как «обратиться за помощью к музею».сотрудник "или" купить кофе в фуд-корт "или" подписаться на волонтерство ".

Не уверен, что этот форум поддерживает такого рода обсуждения.Но я не смог найти лучшего форума для обсуждения.

Answer 1

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

С другой стороны, шаблоны структурного проектирования связаны с тем, как классы и объекты могут быть составлены длясформировать более крупные структуры. Это гибкая структура .

interface Executable {

    void execute();

}

class DeleteUser implements Executable {

    @Override
    public void execute() {
        // delete
    }

}

class LoggingExecutable implements Executable {

    private final Executable executable;

    @Override
    public void execute() {
        // log before
        executable.execute();
        // log after
    }

}

class TransactionalExecutable implements Executable {

    private final Executable executable;

    @Override
    public void execute() {
        // open transaction
        try {
            executable.execute();
        } catch (FooException e) {
            // rollback
        } finally {
            // close transaction
        }
    }

}

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

new LoggingExecutable(
    new TransactionalExecutable(
        new DeleteUser()));

new LoggingExecutable(
    new DeleteUser());