Чи існує мовна чи дизайнерська схема, яка дозволяє * видаляти * поведінку об'єктів чи властивості в ієрархії класів?

Відомий недолік традиційних ієрархій класів полягає в тому, що вони погані, коли йдеться про моделювання реального світу. Як приклад, намагаючись представити види тварин класами. У цьому насправді є кілька проблем, але одна, яку я ніколи не бачив, це рішення, коли підклас «втрачає» поведінку або властивість, визначені в суперкласі, як пінгвін, який не може літати (там є, мабуть, кращими прикладами, але це перший, який мені спадає на думку).

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

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

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

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

Один із способів зробити це - це завжди визначати всі ваші риси в парах з самого початку: Flying та NotFlying (що може кинути UnsupportedOperationException, якщо це не встановлено). Not-чорта не визначає жодного нового інтерфейсу, і його можна просто перевірити. Звучить як "дешеве" рішення, зокрема, якщо його використовувати з самого початку.

Як уже згадували інші, вам доведеться йти проти ЛСП.

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

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

Як правило, динамічні мови дозволяють легко висловити це, нижче наведений приклад із використанням JavaScript:

var Penguin = Object.create(Bird);
Penguin.fly = undefined;
Penguin.swim = function () { ... };

У цьому конкретному випадку Penguinактивно відтіняється Bird.flyметод, який він успадковує, записуючи на об'єкт flyвластивість зі значенням undefined.

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

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

Взагалі ідея Mixin's тут добре застосовується. Майте дуже тонкий базовий клас і змішайте в ньому всю іншу поведінку.

Приклад:

// for some value of Object.make
var Penguin = Object.make(
  /* base class: */ Bird,
  /* mixins: */ Swimmer, ...
);
var Hawk = Object.make(
  /* base class: */ Bird,
  /* mixins: */ Flyer, Carnivore, ...
);

Якщо ви цікаві, у мене є реалізаціяObject.make

Доповнення:

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

Ви не "не реалізуєте" ознаку. Ви просто фіксуєте свою ієрахію спадщини. Або ви можете виконати свій договір про суперкласи, або не повинні робити вигляд, що ви такого типу.

Саме тут сяє композиція об’єкта.

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

Ви не повинні використовувати ознаку "NotX". Це просто жахливий розмах коду. Якщо функція очікує літаючого об'єкта, вона повинна розбитися і спалити, коли ви дасте йому мамонта.

AFAIK усі мови, що базуються на спадщині, побудовані на принципі заміщення Ліскова . Видалення / відключення властивості базового класу в підкласі явно порушить LSP, тому я не думаю, що така можливість ніде не застосовується. Реальний світ справді безладний, і його неможливо точно змоделювати за допомогою математичних абстракцій.

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

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

Ви можете змішати склад і успадкування, маючи супертипи FlyingBird, FlightlessBirdякі мають правильну поведінку, введені Фабрикою, що відповідні підтипи, наприклад, Penguin : FlightlessBirdотримуються автоматично, і будь-що інше, що дійсно конкретно, отримує Фабрика як зрозуміло.

Чи не є справжньою проблемою, яка, на вашу думку, Birdмає Flyметод? Чому ні:

class Bird
{
    // features that all birds have
}

class BirdThatCanSwim : Bird
{
    public void Swim() {...};
}

class BirdThatCanFly : Bird
{
    public void Fly() {...};
}


class Penguin : BirdThatCanSwim { }
class Sparrow : BirdThatCanFly { }

Тепер очевидною проблемою є багаторазове успадкування ( Duck), тож вам справді потрібні інтерфейси:

interface IBird { }
interface IBirdThatCanSwim : IBird { public void Swim(); }
interface IBirdThatCanFly : IBird { public void Fly(); }
interface IBirdThatCanQuack : IBird { public void Quack(); }

class Duck : BirdThatCanFly, IBirdThatCanSwim, IBirdThatCanQuack
{
    public void Swim() {...};
    public void Quack() {...};
}

По-перше, так, будь-яка мова, яка дозволяє легко динамічну модифікацію об'єкта, дозволила б вам це зробити. Наприклад, у Ruby можна легко видалити метод.

Але, як сказав Петер Тьорк, це порушить LSP .

У цій частині я забуду про LSP і припускаю, що:

• Птах - клас з методом fly ()
• Пінгвін повинен успадкувати від Птаха
• Пінгвін не може літати ()
• Мені байдуже, чи це гарний дизайн, чи він відповідає реальному світу, як це є прикладом у цьому питанні.

Ти сказав :

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

Схоже, що ви хочете - це " прохання пробачення, а не дозволу Python "

Просто змусьте ваш Пінгвін кидати виняток або успадковувати клас NonFlyingBird, який викидає виняток (псевдо-код):

class Penguin extends Bird {
     function fly():void {
          throw new Exception("Hey, I'm a penguin, I can't fly !");
     }
}

До речі, що б ви не вибрали: збільшити виняток або видалити метод, врешті-решт, наступний код (припустимо, що ваша мова підтримує видалення методу):

var bird:Bird = new Penguin();
bird.fly();

викине виняток з виконання.

Як хтось вказав вище в коментарях, пінгвіни - це птахи, пінгвіни не літають, ерго не всі птахи можуть літати.

Отже, Bird.fly () не повинен існувати або дозволяти йому не працювати. Я віддаю перевагу колишньому.

Зрозуміло, що FlyingBird розширює, Bird, звичайно, буде правильним методом .fly ().

Справжня проблема прикладу fly () полягає в тому, що введення та вихід операції не визначені належним чином. Що потрібно, щоб птах летіла? А що відбувається після успішного польоту? Типи параметрів і типи повернення для функції fly () повинні мати цю інформацію. Інакше ваш дизайн залежить від випадкових побічних ефектів і все може статися. Все, що завгодно - це те, що викликає всю проблему, інтерфейс не визначений належним чином, і допускаються всі види реалізації.

Отже, замість цього:

class Bird {
public:
   virtual void fly()=0;
};

У вас повинно бути щось подібне:

   class Bird {
   public:
      virtual float fly(float x) const=0;
   };

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

Реальну поведінку може бути важко кодувати до типів, але це єдиний спосіб правильно вказати інтерфейси.

Редагувати: Я хочу уточнити один аспект. Ця функція float-> float версія fly () важлива ще й тому, що вона визначає шлях. Ця версія означає, що одна птах не може чарівно дублювати себе під час польоту. Ось чому параметр є одиночним поплавком - це положення на шляху, який проходить птах. Якщо ви хочете більш складні шляхи, то Point2d posinpath (float x); яка використовує той самий х, що і функція fly ().

Технічно ви можете зробити це в будь-якій мові на динамічній основі / качці (JavaScript, Ruby, Lua тощо), але це майже завжди дуже погана ідея. Видалення методів з класу - кошмар технічного обслуговування, схожий на використання глобальних змінних (тобто в одному модулі ви не можете сказати, що глобальний стан не було змінено в іншому місці).

Хорошими зразками описаної вами проблеми є «Декоратор» або «Стратегія», розробка архітектури компонентів. В основному, замість того, щоб видаляти зайві форми поведінки з підкласів, ви створюєте об'єкти, додаючи необхідні форми поведінки. Отже, щоб створити більшість птахів, ви б додали літаючий компонент, але не додайте цей компонент до своїх пінгвінів.

Петро згадав Принцип заміщення Ліскова, але я вважаю, що це потрібно пояснити.

Нехай q (x) - властивість, доказувальна щодо об'єктів x типу T. Тоді q (y) має бути доказовим для об'єктів y типу S, де S є підтипом T.

Таким чином, якщо Птах (об’єкт x типу T) може літати (q (x)), то Пінгвін (об'єкт y типу S) може літати (q (y)), за визначенням. Але це явно не так. Є й інші істоти, які можуть літати, але не належать до типу Птах.

Як ви з цим справляєтеся, залежить від мови. Якщо мова підтримує багатократне успадкування, то вам слід використовувати абстрактний клас для істот, які можуть літати; якщо мова віддає перевагу інтерфейсам, то це рішення (а реалізація мухомора повинна бути інкапсульована, а не успадкована); або, якщо мова підтримує Duck Typing (не каламбур), ви можете просто реалізувати метод fly на тих класах, які можуть і викликати його, якщо він є.

Але кожна властивість суперкласу має стосуватися всіх його підкласів.

[У відповідь на редагування]

Застосування "риси" CanFly до Bird - не краще. Все ще пропонується зателефонувати за тим, що всі птахи можуть літати.

Рис у визначених вами термінах - це саме те, що мав на увазі Лісков, коли вона сказала "власність".

Почну з згадування (як і всі) Принципу заміни Ліскова, який пояснює, чому ви не повинні цього робити. Однак питання, що вам слід зробити, - це один із дизайну. У деяких випадках може не бути важливим те, що Пінгвін насправді не може літати. Можливо, ви можете змусити Penguin кидати InsufficWingsException, коли його попросять літати, якщо ви зрозуміли в документації Bird :: fly (), що це може кинути це для птахів, які не можуть літати. У вас є тест, щоб перевірити, чи дійсно він може літати, хоча це роздуває інтерфейс.

Альтернативою є реструктуризація класів. Давайте створимо клас "FlyingCreature" (або краще інтерфейс, якщо ви маєте справу з мовою, яка це дозволяє). "Bird" не успадковується від FlyingCreature, але ви можете створити "FlyingBird", що це робить. Жайворонок, гриф та орел успадковують від FlyingBird. Пінгвін ні. Він просто успадковується від Птаха.

Це трохи складніше, ніж наївна структура, але вона має перевагу в точності. Ви зауважите, що всі очікувані класи є там (Птах), і користувач зазвичай може ігнорувати «винайдені» (FlyingCreature), якщо не важливо, може ваша істота літати чи ні.

Типовий спосіб вирішення такої ситуації - кинути щось на зразок UnsupportedOperationException(Java) відповіді. NotImplementedException(C #).

Багато хороших відповідей з багатьма коментарями, але вони не всі згодні, і я можу вибрати лише одну, тому я підсумую тут усі погляди, з якими я згоден.

0) Не припускайте "статичного набору тексту" (я це робив, коли просив, тому що я роблю Java майже виключно). В основному проблема дуже залежить від типу мови, якою ви користуєтесь.

1) Ієрархію типів слід відокремлювати від ієрархії повторного використання коду в дизайні та в голові, навіть якщо вони переважно перетинаються. Зазвичай використовуйте класи для повторного використання та інтерфейси для типів.

2) Причина, чому зазвичай Bird IS-A Fly, полягає в тому, що більшість птахів може літати, тому це практично з точки зору повторного використання коду, але сказати, що Bird IS-A Fly насправді помиляється, оскільки існує хоча б один виняток (Пінгвін).

3) І в статичній, і в динамічній мовах ви можете просто кинути виняток. Але це слід використовувати лише в тому випадку, якщо це прямо заявлено в "договорі" класу / інтерфейсу, що декларує функціональність, інакше це "порушення договору". Це також означає, що тепер ви повинні бути готові виловлювати виняток скрізь, тому ви пишете більше коду на сайті виклику, і це некрасивий код.

4) У деяких динамічних мовах фактично можливо "видалити / приховати" функціональність суперкласу. Якщо перевірка наявності функціональності - це те, як ви перевіряєте "IS-A" на цій мові, то це адекватне та розумне рішення. Якщо, з іншого боку, операція "IS-A" - це щось інше, що все ще говорить, що ваш об'єкт "повинен" реалізувати відсутню функціональність, то ваш код виклику повинен припускати, що функціонал присутній, і викликати його і збивати, так це види суми до викиду виключення.

5) Краща альтернатива - насправді відокремити рису мухи від ознаки Птаха. Тож літаюча птах повинна явно розширювати / застосовувати як Птах, так і Літати / Летять. Це, мабуть, найчистіша конструкція, оскільки не потрібно нічого "знімати". Єдиним недоліком є ​​те, що майже кожному птаху доводиться реалізовувати і Bird, і Fly, тому ви пишете більше коду. Шляхом цього є створення посередницького класу FlyingBird, який реалізує і Bird і Fly, і являє собою загальний випадок, але ця обробка може мати обмежене використання без багатократного успадкування.

6) Ще одна альтернатива, яка не потребує багаторазового успадкування - використовувати склад замість спадкування. Кожен аспект тварини моделюється незалежним класом, а конкретна Птах - це композиція з Птаха, а можливо, з Fly або Swim, ... Ви отримуєте повне повторне використання коду, але вам потрібно зробити один або кілька додаткових кроків, щоб отримати функція Flying, коли у вас є посилання на конкретного Птаха. Крім того, природні мови "об'єкт IS-A Fly" та "об'єкт AS-A (cast) Fly" більше не працюватимуть, тому вам доведеться вигадувати власний синтаксис (деякі динамічні мови можуть обходити це). Це може зробити ваш код більш громіздким.

7) Визначте свою рису Fly таким чином, щоб вона мала чіткий вихід для чогось, що не може літати. Fly.getNumberOfWings () може повернути 0. Якщо Fly.fly (напрямок, currentPotinion) повинен повернути нову позицію після польоту, тоді Penguin.fly () може просто повернути поточнуПозицію, не змінюючи її. Можливо, ви отримаєте код, який технічно працює, але є деякі застереження. По-перше, якийсь код може не мати очевидної поведінки "нічого не робити". Крім того, якщо хтось телефонує x.fly (), він очікує, що він щось зробить , навіть якщо коментар каже, що fly () не може робити нічого . Нарешті, пінгвін IS-A Flying все-таки повернеться правдою, що може заплутати програміста.

8) Робіть як 5), але використовуйте склад, щоб обійти справи, які потребували б багаторазового успадкування. Це варіант, який я вважаю за краще для статичної мови, оскільки 6) здається більш громіздким (і, ймовірно, потребує більше пам’яті, оскільки у нас більше об’єктів). Динамічна мова може зробити 6) менш громіздкою, але я сумніваюся, вона стане менш громіздкою, ніж 5).

Визначте поведінку за замовчуванням (позначте її як віртуальну) у базовому класі та замініть її як необхідну. Таким чином кожна птах може «літати».

Навіть пінгвіни літають, ковзаючи по льоду на нульовій висоті!

Поведінка польоту може бути відмінена за необхідності.

Ще одна можливість - мати Fly Interface. Не всі птахи реалізують цей інтерфейс.

class eagle : bird, IFly
class penguin : bird

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

Я думаю, що шаблон, який ви шукаєте, - це добрий старий поліморфізм. Хоча ви, можливо, зможете вилучити інтерфейс із класу на деяких мовах, це, мабуть, не є хорошою ідеєю з причин, поданих Петером Тьореком. У будь-якій мові ОО, однак, ви можете змінити метод змінити його поведінку, і це не робить нічого. Щоб запозичити свій приклад, ви можете надати метод Penguin :: fly (), який виконує будь-що з наступного:

• нічого
• кидає виняток
• називає метод Penguin :: swim ()
• стверджує, що пінгвін під водою (вони начебто "літають" через воду)

Властивості можна трохи простіше додати та видалити, якщо ви плануєте заздалегідь. Ви можете зберігати властивості у масиві карт / словник / асоціативний елемент замість використання змінних екземплярів. Ви можете використовувати заводський зразок для створення стандартних екземплярів таких структур, тому Bird, що надходить від BirdFactory, завжди запускатиметься з однаковим набором властивостей. Ключове значення кодування Key-Value від Objective-C є хорошим прикладом такого роду речей.

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

Використовуючи ваш приклад Пінгвінів, одним із способів реабілітації було б відокремлення льотної здатності від класу Птахів. Оскільки не всі птахи можуть літати, у тому числі метод fly () у Bird був недоречним і призводив безпосередньо до тієї проблеми, про яку ви ставите. Отже, перемістіть метод fly () (і, можливо, takeoff () та land ()) до класу або інтерфейсу Aviator (залежно від мови). Це дозволяє створити клас FlyingBird, який успадковується як від Bird, так і від Aviator (або успадковується від Bird та реалізує Aviator). Пінгвін може продовжувати успадковувати безпосередньо від Птаха, але не від Авіатора, тим самим уникаючи проблеми. Така домовленість може також полегшити створення класів для інших літаючих речей: FlyingFish, FlyingMammal, FlyingMachine, AnnoyingInsect тощо.