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

Наприклад:

var duckBehaviors = new Duckbehavior();
duckBehaviors.quackBehavior = new Quack();
duckBehaviors.flyBehavior = new FlyWithWings();
Duck mallardDuck = new Duck(DuckTypes.MallardDuck, duckBehaviors)

Оскільки клас Дак містить усі форми поведінки (реферат), створюється новий клас MallardDuck(який розширюється Duck), здається, не потрібно.

Довідка: Шаблон першого дизайну голови, глава 1.

Звичайно, але ми називаємо цей склад і делегацію . Модель стратегії та введення залежностей можуть здатися структурно подібними, але їхні наміри відрізняються.

Шаблон стратегії дозволяє змінювати поведінку під час виконання одного інтерфейсу. Я міг сказати качки крижаниці літати і спостерігати, як вона літає крилами. Потім поміняйте його на качку пілота реактивного літака і спостерігайте, як він літає з авіакомпаніями Delta. Це під час роботи програми - це стратегічний зразок.

Ін'єкція залежності - це техніка, щоб уникнути жорстких залежностей від кодування, щоб вони могли змінюватися незалежно, не вимагаючи, щоб клієнти були змінені, коли вони змінюються. Клієнти просто висловлюють свої потреби, не знаючи, як вони будуть задоволені. Таким чином, спосіб їх зустрічі вирішується в іншому місці (як правило, в основному). Для використання цієї методики вам не потрібно дві качки. Просто щось, що використовує качку, не знаючи і не піклуючись, яка качка. Щось, що не будує качку і не шукає її, але абсолютно радий використовувати будь-яку качку, яку ви їй вручите.

Якщо я маю конкретний клас качок, я можу його реалізувати, це поведінка мух. Я міг би навіть переконати, що він переводить поведінку з крила на крило на літо з дельтою на основі змінної стану. Ця змінна може бути булевою, int, або може бути a, FlyBehaviorяка має flyметод, який виконує будь-який стиль польоту, без того, щоб я мав тестувати це з if. Тепер я можу змінювати стилі польоту, не змінюючи типів качок. Тепер крижанки можуть стати пілотами. Це склад та делегування . Качка складається з FlyBehavior і вона може делегувати їй запити на політ. Ви можете замінити всі способи поведінки качки одразу таким чином або потримати щось за кожну поведінку чи будь-яку комбінацію між ними.

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

Однак багато хто вважає, що спадщина повинна бути чітко розроблена з самого початку. І що, якщо цього не було, ви повинні позначити свої класи як опломбовані / остаточні, щоб заборонити спадкування. Якщо ви дотримуєтесь цієї точки зору, то спадкування дійсно не має переваги перед складом та делегуванням. Тому що тоді або в будь-якому випадку вам доведеться або розробити розширення з самого початку, або бути готовим зірвати речі пізніше.

Зривання речей - насправді популярний варіант. Просто пам’ятайте, що є випадки, коли це проблема. Якщо ви самостійно розгорнули бібліотеки або модулі коду, які не збираєтесь оновлювати наступним випуском, ви можете закінчитися з версіями класів, які нічого не знають про те, що ви зараз маєте.

Незважаючи на те, що згодом готові зірвати речі, ви можете позбавити вас від надмірного проектування, але є щось дуже потужне в тому, щоб мати можливість спроектувати щось, що використовує качку, не знаючи, що качка насправді буде робити при використанні. Те, що не знати, це потужний матеріал. Це дозволяє вам на деякий час перестати думати про качок і продумати решту свого коду.

"Чи можемо ми" і "чи повинні ми" - це різні питання. Улюблений склад над успадкуванням не говорить ніколи не використовуйте спадщину. Ще є випадки, коли успадкування має найбільше значення. Я покажу тобі свій улюблений приклад :

public class LoginFailure : System.ApplicationException {}

Спадкування дозволяє створювати винятки з більш конкретними, описовими іменами лише в одному рядку.

Спробуйте зробити це з композицією, і ви отримаєте безлад. Також немає ризику виникнення проблеми спадкового йо-йо, оскільки тут немає даних або методів для повторного використання та заохочення ланцюга спадкування. Все це додає - це гарне ім’я. Ніколи не варто недооцінювати цінність доброго імені.

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

Від багатьох речей залежить, який з них є кращим. Попереднє мистецтво в застосуванні, досвід роботи в команді, очікувані майбутні події, особисті переваги та те, наскільки важко буде новачкові обійти його, назвати декілька.

Оскільки ви все частіше переживаєте і боретеся з чужими творіннями, ви, швидше за все, зробите більший акцент на останньому спогляданні.

Спадщина - це все-таки дійсний і сильний інструмент моделювання, який не завжди є найбільш гнучким, але він пропонує чіткі вказівки для нових людей, які можуть бути вдячні за чітке відображення проблемної області.

Спадщина не так важлива, як колись думалося. Це все ще важливо , і видалити його було б поганою помилкою.

Крайній приклад - Objective-C, де все є підкласом NSObject (компілятор насправді не дозволяє вам оголосити клас, який не має базового класу, тому все що не вбудовано в компілятор, повинно бути підкласом чогось вбудований у компілятор). У NSObject є багато корисних речей, які вам не доведеться пропускати.

Ще один цікавий приклад - UIView, базовий клас "view" в UIKit для розробки iOS. Це клас, який, з одного боку, трохи схожий на абстрактний клас, декларуючи функціональність, яку підкласи повинні заповнювати, але він також корисний і сам по собі. У ньому є підкласи, що постачаються UIKit, які часто використовуються як є. Є композиція розробником, який встановлює підгляди у вигляді. І часто існують визначені розробниками підкласи, які часто використовують склад. Не існує жодного суворого єдиного правила або навіть правил, ви використовуєте все, що найкраще відповідає вашим вимогам.

[Я загрожу нахабною відповіддю на титульне запитання.]

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

Так ... за винятком самого шаблону стратегії використовується спадкування. Шаблон стратегії працює на успадкування інтерфейсу. Заміна спадкування композицією + стратегією переміщує спадщину на інше місце. Тим не менш, таку заміну часто варто робити, оскільки вона дозволяє роздирати ієрархії .

Ні. Якщо качка-крижанка вимагає інших параметрів для екземпляра, ніж якийсь інший тип качки, це було б кошмаром, щоб змінити. Також ви повинні мати можливість придушити качку? Це більше качка-крижанка або качка мандарина або будь-який інший тип качок у вас є.

Також я можу захотіти певної логіки навколо типів, щоб ієрархія типу могла бути кращою.

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

Знову ж таки, це дійсно залежить від вашого випадку використання. Якщо у вас просто качка і качка-крижанка, ієрархія класів - набагато простіше рішення.

Але ось приклад, коли ви хочете використовувати шаблон стратегії: Якщо у вас є класи клієнтів, і ви хочете передати платіжну стратегію (інтерфейс), яка може бути стратегією виставлення рахунків за годину або звичайною стратегією виставлення рахунків, ви можете передати її в конструкторі. Таким чином, вам не потрібно складати два різні класи клієнтів, і вам не потрібна ієрархія. У вас просто один клас клієнтів.