Чи контекстне успадкування, як показано на прикладі качки Head First Pattern Patterns, не має значення для структури стратегії?


10

У шаблонах дизайну Head First Design викладається стратегічна схема , використовуючи приклад Duck, коли різним підкласам Duck може бути призначена певна поведінка під час виконання. З мого розуміння, ціль стратегічної схеми полягає у зміні поведінки одного об'єкта під час виконання, але вони використовують спадкування Дака для зміни поведінки різних типів Качки.

Стратегія

Доречність?

Чи контекстне успадкування Дака не має відношення до структури стратегії чи змінюється тип Дак, а також змінюється їх поведінка є вагомим приводом для використання стратегії? Чи є ситуації, коли потрібно змінювати обидва, є вагомою причиною для використання стратегії? Чому вони включають це як приклад структури стратегії?

Простіший приклад

Чи можу я далі спростити цей приклад, просто маючи клас Дак (немає похідних класів)? Тоді при реалізації одного об’єкта качки йому можуть бути призначені різні форми поведінки, виходячи з певних обставин, які не залежать від його власного типу об'єкта. Наприклад: FlyBehavior змінюється залежно від погоди або зміни QuackBehavior залежно від часу доби або того, як голодна качка. Я усвідомлюю, що це вирішило б іншу проблему, ніж та, яку викладено в книзі, але те, що я шукаю, - це відповідний зразок стратегії, на який потрібно відмовитися.

Чи міг би мій приклад входити і до стратегії?

Редагувати:

Мені вдалося знайти 2 простіші приклади шаблону стратегій, які суворіше дотримуються лише стратегічних моделей без успадкування контексту: Hunter.java та solver.py .

Відповіді:


7

Так, я думаю, ви на правильному шляху. Клас, що використовує шаблон стратегії, не повинен бути підкласом. Шаблон стратегії є альтернативою успадкування для повторного використання коду. Це повертається до ще більш широкого порівняння спадщини та складу.

З шаблонів дизайну: Елементи багаторазового використання OOP, для якого ви використовуєте стратегію

  • Уникайте вибуху підкласів (через поєднання поведінки)
  • Якщо вам потрібно змінити поведінку під час виконання

Якщо ви використовували успадкування для реалізації поведінки Quack і Fly, то ви отримали б усі ці підкласи представляти всі комбінації поведінки.

  • FlyableQuackableDuck
  • FlyableSqeakableDuck
  • FlyableMuteDuck
  • NoFlyQuackableDuck
  • NoFlySqueakableDuck
  • NoFlyMuteDuck

Наявність такої кількості підкласів ускладнює підтримання, тому стратегія надає перевагу цьому випадку. Вам просто потрібні два властивості, які інкапсулюють Fbility та Quackability, і ви можете їх змішувати та співставляти, не створюючи нових класів.

Ви також вже згадували перевагу часу виконання, якщо погода змінила властивість качки, Fly може бути замінена об'єктом NoFly через умови.

Це узгоджується з порадами щодо сприяння складу над спадщиною, коли це можливо.


1

Чи можу я далі спростити цей приклад, просто маючи клас Дак (немає похідних класів)? Тоді при реалізації одного об’єкта качки йому можуть бути призначені різні форми поведінки, виходячи з певних обставин, які не залежать від його власного типу об'єкта.

Звичайно. Для натхнення погляньте в головний об'єктно-орієнтований аналіз та дизайн . Є "Гітари Ріка", що показують вибух (музичних) підкласів інструменту . Щоб виправити це, все, що відрізняється поведінкою, міститься в класі "специфікація", дотримуючись принципу інкапсуляції того, що змінюється .

Анотація заводу - Контекстна побудова

Ось викрійка . До речі, зверніть увагу, що вона використовує саму стратегію.

Орієнтація на концепцію, а не на реалізацію ... У вас може бути "WeatherFactory", який будує об'єкти специфікації на основі сонячних чи дощових умов тощо.

Ви можете мати "фабрики фабрик", щоб зайнятися побудовою цих "фабрик NoFlyInFogQuackableMallard". І справді, саме про це йде абстрактний заводський візерунок. Тож, можливо, DuckFactory робити загальні типи качок, тоді WeatherFactory, щоб надати їй характерну для качки характерну туманну погодну поведінку.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.