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

Чи повторне використання коду, як це визначає OOP, робить проекти більш продуктивними?

Або більш керований? Або простіше в обслуговуванні? Або з більшою якістю?

Напевно, всі ми згодні, що повторне використання коду - це добре, але існує кілька способів досягнення цієї мети. Питання стосується способу повторного використання коду, запропонованого OOP. Це було добре? Чи є кращі методи для досягнення повторного використання коду, ніж орієнтація на об'єкти, підкласифікація, поліморфізм тощо? Які способи краще? Чому ?

Розкажіть про свій досвід повторного використання OOP або інших парадигм.

Повторне використання коду - досить гарна ідея. Не великий .

Я маю перспективу з приблизно 30 років інженерії програмного забезпечення, яку намагаються "повторно використовувати".

Я почав досліджувати «повторне використання коду» як тему дослідження ще в 80-х, після виявлення я повторно використав дизайн однієї ОС, яку я побудував на початку 70-х років, для іншої ОС, яку створив наприкінці 70-х.

Гарна частина повторного використання коду - це можливість іноді повторно використовувати чесний богу попередній код. Але світ повний коду; як можна знайти те, що ти хочеш? Ось що я називаю Прокляттям повторного використання :

Я Дід Мороз (добре з відкритим кодом), і в мене є пакет з 1 мільярдом програмних компонентів. Ви можете мати будь-яку з них.

Успіхів у виборі.

Щоб добре вирішити проблему повторного використання:

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

Здебільшого, що було виявлено протягом багатьох років, це те, що для коду, який підлягає багаторазовому використанню, він має бути розроблений для цієї мети, або він містить занадто багато неявних припущень. Найуспішніших бібліотек повторного використання коду насправді було досить мало. Можливо, бібліотеки та фреймворки є кодом для багаторазового використання, і вони надзвичайно успішні; Java та C # досягають успіху не тому, що вони досить хороші комп'ютерні мови, а тому, що у них доступні величезні добре розроблені, реалізовані та документовані бібліотеки. Але люди не дивляться на вихідний код у бібліотеках; вони просто називають добре задокументований API (призначений для загального використання).

Те, що повторного використання коду не було зроблено (OOP також), не забезпечує накази покращення нашої здатності до кодування систем.

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

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

Для цього все ще потрібна однакова можливість специфікації для характеристики компонентів програмного забезпечення (ви все одно повинні сказати, що ви хочете!). Але тоді ви застосовуєте це "конструктивне" знання до специфікацій, щоб генерувати потрібний код.

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

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

Укладачі вже роблять це: -} І вони справді хороші в класі проблем, з якими вони вирішуються.

Моделі UML з генерацією коду - це одна спроба зробити це. Не дуже вдала спроба; майже все, що кажуть у більшості моделей UML - "у мене є дані, які виглядають так". Досить важко генерувати справжню програму, якщо функціональність не залишиться.

Я намагаюся створити практичні системи трансформації програм, інструмент під назвою DMS . Досить добре відволікався, застосовуючи програмні перетворення не стільки до абстрактних специфікацій для генерування коду, скільки до застарілого коду для його очищення. (Це та сама проблема в рефераті!). (Для побудови таких інструментів потрібно багато часу; я цим займаюся вже 15 років, а тим часом ви повинні їсти).

Але DMS володіє двома ключовими властивостями, які я описав вище: здатність обробляти довільні формальні специфікації та здатність фіксувати "знання про генерацію коду" як перетворення та застосовувати їх на вимогу. І що примітно, ми створюємо в деяких особливих випадках якийсь цікавий код із специфікацій; DMS багато в чому будується, використовуючи себе для створення своєї реалізації. Це досягло для нас принаймні частини обіцянки повторного використання знань: надзвичайно значні підвищення продуктивності праці. У мене є команда з близько 7 технічних людей; ми написали, ймовірно, 1-2 MSLOC "специфікацій" для DMS, але маємо 10MSLOC згенерованого коду.

Підсумок: повторне використання знань покоління - це виграш, а не повторне використання коду .

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

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

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

З Вікіпедії:

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

Так і ні

Повторне використання коду є загальним терміном для багатьох видів діяльності.

1. Повторне використання коду в рамках одного проекту. OO цілком підходить для цього, добре розроблений додаток буде чітко відображати відносини модельованого світу, тим самим максимально усуваючи дублікат коду. Однак ви можете стверджувати, що технології, що передували OO, могли досягти того самого, що правда, але OO багато в чому зручніше.
2. Сторонні бібліотеки Це, здається, працює однаково добре з або без ОО.
3. Багатоцільове повторне використання коду Найбільшою обіцянкою OO щодо повторного використання коду було те, що код, один раз написаний для однієї програми, може бути повторно використаний для іншого, для якого він не був спеціально розроблений. Це була вся гнів, коли поняття ОО фільтрувалося через двері вищих управлінських кабінетів, і ОО повністю не змогло цього досягти. Виявилося, що мета була важливим аспектом розробки OO (і, можливо, всього процесуального кодексу, але це лише моя теорія), а спроби змінити код закінчилися катастрофами на технічному обслуговуванні. (Загальновідомі анти-візерунки старої рамки, яку ніхто не наважується модифікувати, і її друг, дещо інший фреймворк для кожного додатка, як правило, походить звідси.)

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

http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

Ось початок публікації:

Ця галузь заздалегідь зайнята повторним використанням.

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

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

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

Я б також міг пустити вас у таємницю:

Повторне використання - це помилка

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

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

Я думаю, що глибоке успадкування в ООП може ввести в оману в багатьох випадках. У вас є клас, і багато тісно пов'язаних методів реалізовані в різних файлах. Як сказав Джо Армстронг про ООП:

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

Функції вищих порядків також дуже корисні , коли мова йде про код повторного використання , наприклад , mapі foldrщо є основою для компанії Google MapReduce .

Асинхронна передача повідомлень також є хорошим способом організації складного програмного забезпечення, і деякі комп'ютерні вчені заявляють, що передбачалося, що об'єкти мають зв'язок з іншими асинхронними, як у принципі Tell, не вимагайте принципу OOP. Детальніше про це див. У Об'єктно-орієнтованому програмуванні: неправильний шлях? був Джо Армстронг котирується:

Я почав цікавитися, що таке об’єктно-орієнтоване програмування, і я подумав, що Ерланг не є об'єктно-орієнтованим, це функціональна мова програмування. Потім мій керівник дисертації сказав: "Але ви помиляєтесь, Ерланг надзвичайно об'єктно орієнтований". Він сказав, що об'єктно-орієнтовані мови не є об'єктно-орієнтованими. Я можу подумати, хоча я не зовсім впевнений, вірю я цьому чи ні, але Ерланг може бути єдиною об'єктно-орієнтованою мовою, оскільки 3 принципи об'єктно-орієнтованого програмування полягають у тому, що це засноване на передачі повідомлень , що ви маєте ізоляцію між об'єктами та мають поліморфізм .

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

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

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

ООП не особливий; ви можете зробити код багаторазового використання з OOP або без нього. Чисті функції особливо багаторазові : наприклад, java.lang.math.sqrt(double)приймає число і видає число. Ніякого OOP, але, безумовно, більш багаторазового використання, ніж більшість кодів там.

З точки зору функціонального програмування OOP здебільшого стосується управління станом.

У функціональному програмуванні ви можете легко мати сотні корисних функцій для списків: http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Data-List.html .

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

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

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

Більшу частину часу створюючи абстрактний базовий клас та створюючи конкретні реалізації цього класу.

Також багато фреймворків використовують успадкування для забезпечення повторного використання коду (Delphi, Java, .Net - лише деякі, які миттєво сприймаються).

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

На моєму досвіді я мав більший успіх, використовуючи «багаторазовий» код через загальні засоби програмування (як, наприклад, шаблони C ++), ніж я використовував принципи OOP, як ієрархії спадкування.

OOP занадто відкритий для ефективного повторного використання.

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

API краще, це суворий підмножина точок OOP (або не є oop), але в реальному житті API перенасичені і вічно зростають, все ще надто багато точок зв’язку. Також хороший API може полегшити життя, це найкращий спосіб забезпечити інтерфейс для OOP.

Парадигма Datadlow забезпечує суворий інтерфейс для компонентів, вони мають порти таких типів:

• споживачі (входи) та
• виробники (виходи).

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

Мені було трохи незрозуміло, ви можете подивитися тег "dataflow" на StackOverflow або Wikipedia "програмування datafow" або Wikipedia "програмування на основі потоку" .

(Крім того, я написав систему передачі даних на C ++. Отже, OOP і DF не є ворогами, DF - це організація вищого рівня.)

У CommonLisp є багато засобів для досягнення повторного використання:

• динамічне введення тексту, яке за замовчуванням має ваш загальний код

• імперативні абстракції, тобто підпрограми

• об'єктно-орієнтована, з багаторазовим успадкуванням і багаторазовим відправленням

• синтаксис-абстракція, можливість визначати нові синтаксичні конструкції або скорочувати код пластини котла

• функціональні абстракції, закриття та функції високого порядку

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

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

У цьому сенсі повторне використання в реальному світі полягає у повторному призначенні речей. Я можу повторно використовувати ці місця тут і переставити їх, щоб утворити ... ліжко! Не дуже зручне ліжко, але я можу це зробити. Це не їх первинне використання. Я їх повторно використовую за межами своєї первинної області застосування. [...] Завтра я повернуся до Великобританії. Я не буду повторно використовувати літак. Я просто використаю його з тією метою, яка була призначена для цього, в цьому немає нічого фантазійного та захоплюючого.

- Кевлін Генні

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

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

Повторне використання коду вимагає готовності не повторювати код, розуміння способів його виконання, планування заздалегідь. Якщо вам слід уникати повторного використання коду, коли ви вирішили, що у вас є випадок, коли його просто не варто? І жодна мова не є настільки суворо OO, що вона призведе до помилки, коли вважає, що вам слід було успадкувати код іншого класу. У кращому випадку вони забезпечують середовище, що сприяє його реалізації.

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

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

OOP надає більше способів повторного використання коду. Це все.

Горизонтальне повторне використання: аспекти, риси, трансплантати

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

Аспектно-орієнтоване програмування

Я розглядаю АОП як відсутній напівпомаранчевий OOP. AOP насправді не так відомий, але він зробив це до виробничого коду.

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

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

Перегляньте ці два переговори, якщо хочете зрозуміти AOP краще:

• Використання програмування, орієнтованого на аспекти, для запобігання нападам додатків 1/6
• Аспект - орієнтоване програмування: Radical Дослідження в Модульность по Грегор Кікзалес (головна людина за АОП)

Риси та трансплантати

Риси ознак - це ще одна конструкція для визначення коду для багаторазового використання, що доповнює OOP, вони схожі на mixins , але чистіші.

Замість того, щоб пояснювати їх, існує чудовий PHP RFC, який пояснює і те, і інше . Риси надходять до PHP btw, вони вже покладені на магістраль.

Підводячи підсумок

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

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

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

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

Читаючи вищезгадані пости, кілька зауважень:

• Багато хто вважає, що повторне використання коду в OOP означає спадкування. Я не згоден. Інтерфейси та контракти є основою для повторного використання коду в системах OOP. OOP - спроба сірого поля у створенні технології компонентів.
• Різниця між доменними і загальними "рамками" як предметом повторного використання вважається мені занадто абстрактною. На мій погляд на речі, компонент (стислий, мінімальний та повторно використаний договір інтерфейсу та реалізація позаду) може бути виконаний, лише якщо проблема, яку він вирішує, добре зрозуміла. Компонент, специфічний для домену, який дозволяє недоменним експертам виконувати свою роботу з меншими знаннями про домен є (повторно) корисним компонентом. Користувачі повинні розуміти інтерфейс, рідше тонкощі проблемної області.
• Рівні повторного використання часто забуваються: повторне використання ідеї, повторне використання специфікацій, повторне використання архітектури / дизайну, повторне використання інтерфейсу, повторне використання тестового випадку. Повторне використання коду не завжди сприятливе. Але це велика економія часу часто дотримуватися певної архітектури, щоб вирішити новий, подібний продукт.
• Мої моделі дизайну OOP (Гамма та ін.) В моїх очах детальніше розробляли методи тактичної реалізації, а не мали значення в контексті повторного використання коду в більшому масштабі. Вони допомагають написати додаток з елементами OOP, але я б не вважав їх вирішенням питання "повторного використання коду" поза однією програмою.
• Можливо, це не справедливо: 20 років досвіду C / C ++ / C # і 6 місяців функціонального програмування (F #). Одним з головних елементів включення повторного використання є: людям потрібно легко знайти "інтерфейс", вивчити його, зрозуміти, а потім використовувати його. Чисте функціональне програмування не полегшує мені бачити структуру, кандидатів для повторного використання або де все починається і де все закінчується. Настільки хвалений "синтаксичний цукор" часто - це сіль в моїх очах, заважаючи мені легко бачити, що відбувається. Таким чином, я б менше шансів спробувати повторно використовувати функціонал (що це - купа функцій?), Який може мати приховані побічні ефекти, яких я навіть не бачу (лінива оцінка, монади, ...). Не зрозумійте мене неправильно, функціональне програмування має дуже круті сторони, але всі проголошені сильні сторони я бачу з хорошою мірою сумнівів.
• Специфікація, дизайн, реалізація поєднані, але нелегкі для перегляду погляди на "те саме". Набагато важливішим для підвищення майбутньої продуктивності, ніж нова парадигма програмування, є закриття прогалини, збільшення (автоматизовані міркування, простежуваність) взаємної вигоди між цими поглядами. Формалізовані мови специфікацій, стандартизовані тестові позначення (наприклад, ttcn3) та мови програмування, що підтримують перевірку інтерфейсів та контрактів на предмет специфікацій без засмічення коментарів, можуть бути найневідкладнішими.

Проблема є більш тонким:

1. OOP - це чудовий метод структурування коду зі змінним станом . Інкапсулюючи стан в об'єкти, імперативний код держави стає більш зрозумілим, оскільки, наприклад, якщо фрагмент стану виражається як приватні поля класу, ви знаєте, що принаймні цей конкретний фрагмент стану можна змінювати лише методами цього клас. (І ви легко можете зламати цю вигоду, зловживаючи спадщиною, btw.) Цього зараз достатньо, але waaay краще, ніж навіть не мати цього.
2. код із змінним станом по суті важко повторно використовувати . Шлях складніше, ніж код, використовуючи незмінні структури даних.

Таким чином, OOP сам по собі непоганий від POV створення багаторазового коду , але види коду, які записуються за допомогою OOP, по суті важко використовувати .

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

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

... що призводить до останньої тонкості: повторне використання коду стосується інтерфейсу People | Code , а не лише про код. OOP справно справляється з обслуговуванням цього інтерфейсу, оскільки він добре відображає кількість людей, які думають про багато видів коду, написаних сьогодні. FP може бути кращим для повторного використання коду, але не для легкого використання виду коду, який людям потрібно писати сьогодні. Це зміниться як вид коду, який нам потрібно писати.

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