Я віддаю перевагу функціям OOP при розробці ігор з Unity. Зазвичай я створюю базовий клас (в основному абстрагований) і використовую успадкування об'єктів, щоб ділити однакові функціональні можливості з різними іншими об'єктами.

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

Я використовую абстрактний базовий клас, що - щось на зразок WeaponBaseі створення спеціальних класів зброї , як Shotgun, AssaultRifle, Machinegunщо - щось подібне. Є так багато переваг, і один з образів, який мені дуже подобається - це поліморфізм. Я можу розцінювати об'єкт, створений підкласами, як би базовим класом, щоб логіка могла бути різко зменшена і зробити її більш багаторазовою. Якщо мені потрібно отримати доступ до полів або методів підкласу, я повертаюсь до підкласу.

Я не хочу , щоб визначити однакові поля, як правило, використовується різних класах, як AudioSource/ Rigidbody/ Animatorі багато полів членів я визначив , як fireRate, damage, range, spreadі так далі. Також у деяких випадках деякі методи можуть бути перезаписані. Тому я використовую віртуальні методи в такому випадку, так що в основному я можу викликати цей метод, використовуючи метод із батьківського класу, але якщо логіка повинна бути різною у дочірнього, я їх вручну змінив.

Отже, чи варто відмовлятися від усіх цих речей як поганих практик? Чи варто використовувати замість цього інтерфейси?

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

Віддайте перевагу спадщині над складом у вашій логіці рівня додатків - від конструкцій інтерфейсу до служб. Наприклад,

Widget->Button->SpinnerButton або

ConnectionManager->TCPConnectionManagerпроти ->UDPConnectionManager.

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

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

Ви вже отримали кілька приємних відповідей, але величезний слон у кімнаті у вашому запитанні такий:

чути від когось, що слід уникати використання успадкування, а нам слід використовувати інтерфейси

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

На мій досвід, найважливіші та корисні поняття в ООП - це "низька зв'язок" і "висока згуртованість" (класи / об'єкти знають якомога менше один про одного, і кожен підрозділ відповідає за якомога менше речей).

Низька муфта

Це означає, що будь-яка «пачка речей» у вашому коді повинна якомога менше залежати від оточення. Це стосується класів (дизайн класу), але також об'єктів (фактична реалізація), "файлів" взагалі (тобто, кількість #includes на один .cppфайл, кількість importодного .javaфайлу тощо).

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

Спадщина збільшує зв'язок, очевидно; зміна базового класу змінює всі підкласи.

Інтерфейси зменшують зв'язок: визначаючи чіткий, заснований на методах договір, ви можете вільно змінити що-небудь про обидві сторони інтерфейсу, доки ви не зміните договір. (Зауважте, що "інтерфейс" є загальним поняттям, interfaceабстрактні класи Java або C ++ - це лише деталі реалізації).

Висока згуртованість

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

У цьому прикладі ви переконаєтесь, що ваш клас, що представляє "вогнепальну поведінку", знає якомога менше людського про основний клас зброї. Оптимально, взагалі нічого. Це, наприклад, означатиме, що ви можете надати "Поведінка вогню" будь-якому об'єкту у вашому світі (башти, вулкани, NPC ...) лише одним пальцем. Якщо ви в якийсь момент хочете змінити, як зброя представлена ​​в інвентарі, тоді ви можете це зробити просто - про це взагалі знає лише ваш інвентарний клас.

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

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

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

Що ж тепер робити

Досі немає жорстких і швидких правил, все це лише вказівки. Загалом, як згадував у своїй відповіді користувач TKK, про спадкування багато навчають у школі та книгах; це модні речі про OOP. Інтерфейси, ймовірно, є більш нудними для навчання, а також (якщо пройти повз банальних прикладів) трохи складніше, відкриваючи поле введення залежності, що не так чітко, як успадкування.

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

Думка про те, що слід уникати спадкування, просто неправильна.

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

Я мушу сказати, що мені подобаються ваші заняття зі зброї, і це було б так само. Але я до цього часу не зробив гри ...

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

Проблема полягає в тому, що успадкування призводить до з’єднання - ваші об'єкти повинні знати більше один про одного. Ось чому правило: "Завжди підтримуйте склад над спадщиною". Це не означає, що НІКОЛИ не використовуйте спадщину, це означає, що використовуйте її там, де це цілком доречно, але якщо ви коли-небудь сидите там, думаючи, "я можу це зробити обома способами, і вони обидва мають сенс", просто переходьте до композиції.

Спадщина також може бути обмежувальним. У вас є "Зброя", яка може бути AssultRifle - приголомшливо. Що станеться, коли у вас двоствольна рушниця і хочете дозволити стволам стріляти самостійно - трохи важче, але виконати, у вас просто клас з одноствольним та двоствольним стволом, але ви не можете просто встановити 2 одиночні бочки. на одній рушниці, може? Чи можете ви модифікувати 3 бочки або вам потрібен новий клас для цього?

А як щодо AssultRifle з гранатометом під ним - хм, трохи жорсткіше. Чи можете ви замінити GranadeLauncher ліхтариком для нічного полювання?

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

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

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

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

Інтерфейси - це першокласні громадяни будь-якої мови ООП.Класи є вторинними деталями реалізації. Уми нових програмістів сильно викривлені вчителями та книгами, які вводять класи та успадкування перед інтерфейсами.

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

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

Спадщина проти складу - це питання - проти - є питання. Інтерфейси - це ще один (третій) спосіб, відповідний для деяких ситуацій.

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

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

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

Скажімо, у вас є асортименти, представлені класами, і вони мають функції, представлені функціями. Наприклад, у птаха були б Talk (), Fly () та Poop (). Клас Дак успадкував би від класу Bird, реалізуючи всі функції.

Клас Фокс, очевидно, не вміє літати. Отже, якщо ви визначите пращура, щоб він мав усі риси, то ви не могли б вивести нащадка належним чином.

Якщо, однак, ви розділите функції на групи, представляючи кожну групу викликів за допомогою інтерфейсу, скажімо, IFly, що містить Takeoff (), FlapWings () та Land (), тоді ви могли б для класу Fox реалізувати функції з ITalk та IPoop але не IFly. Потім ви б визначили змінні та параметри, щоб прийняти об'єкти, що реалізують певний інтерфейс, і тоді код, який працює з ними, знав би, що він може викликати ... і завжди може запитувати інші інтерфейси, якщо йому потрібно перевірити, чи є також інші функції реалізований для поточного об'єкта.

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

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

Наприклад, скажімо, у вас є TalkingAI на одній гілці дерева спадкування, а VolumetricCloud на іншій окремій гілці, і ви хочете розмовляти хмару. Це важко з глибоким деревом спадкування. За допомогою компонента сутності ви просто створите об'єкт, у якого є компоненти TalkingAI та Cloud, і ви готові йти.

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

В якості побічної записки я вважаю таке питання:

Зазвичай я створюю базовий клас (в основному абстрагований) і використовую успадкування об'єктів, щоб ділити однакові функціональні можливості з різними іншими об'єктами.

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

Ви можете використовувати інтерфейси, якщо хочете, скажімо, мати в ньому List<IWeapon>різні види зброї. Таким чином, ви можете успадкувати як інтерфейс IWeapon, так і підклас MonoBehaviour для всієї зброї, а також уникати будь-яких проблем з відсутністю багаторазового успадкування.

Ви, здається, не розумієте, що таке інтерфейс. Мені знадобилося близько 10+ років, як я думав про ОО і задав питанням справді розумних людей, чи змогла я мати ах-ха момент з інтерфейсами. Сподіваюся, це допомагає.

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

Ця ж аналогія може бути використана між людиною (тілом і душею), що взаємодіє зі світом. Тіло - це інтерфейс між розумом і світом. Усі взаємодіють зі світом однаково, єдиною унікальністю є те, як ми взаємодіємо зі світом, саме так ми використовуємо наш МІНД, щоб вирішити, як ми інтерфейсуємо / взаємодіємо у світі.

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

Отже, щоб розум викликав функцію відкритих рук, він повинен реалізувати інтерфейс nerv_command_system з тим, що має власний API з інструкціями, як реалізувати всі необхідні вимоги перед викликом відкритої руки.