- Bridge: разный способ логирования, разные реализации сервиса (можно переключаться через профили).
- Composite: класс журнала на предприятии, в который нужно поместить список документов (абстрактный класс), все документы имеют разное наполнение, но по-своему реализуют несколько общих методов (посмотреть заверено ли, кто подписывал).
- Factory: печать чека в зависимости от способа оплаты. Или отправка сообщений (логов) в зависимости от уровня логирования на почту или в файл. Или, в зависимости от времени суток, в приложении появляется меню завтраков или основное.
- Prototype: в приложении для сотрудников ресторана используются кнопки меню. Создаем новую кнопку путем клонирования, устанавливаем название кнопки (блюда) и id блюда для связи с БД. Или формирование чеков, наполнение заказа или варианты оплаты могут меняться, но остальное наполнение будет шаблонным.
- Observer: каждый раз, когда работник/официант пробивает блюдо, на складе проверяется остаток продуктов/полуфабрикатов, необходимых для приготовления минимального количества блюд. Если продуктов не хватает, то в соответствующие отделы рассылается уведомление для закупки, добавления в стоп-лист или иных действий. Либо на кухне повара сами определяют остаток и сообщают через свое приложение о прекращении продаж, о чем сообщается другим.
- Strategy: при выборе в меню товара можно посмотреть информацию о нем. Это может быть покупной товар или продукция собственного производства. Стратегия отображения информации или стратегия продажи может различаться, но это все товар, пункт в меню.
- Command: есть товар (пункт меню), при покупке можно увеличить (+) или уменьшить (-) его количество. А м.б. будет возможность дублировать чек (+). Данные функции (increase/decrease) можно вынести как команды.