«Я не хочу, щоб гарну парадигму вважали гідною звалища»: 7 неспроможних аргументів противників ООП

Блукаючи інтернетом, можна помітити одну цікаву особливість. Усі парадигми програмування сприймаються людьми спокійно. Про процедурне програмування говорять спокійно та про модульне. Декларативне програмування — жодних бур, хвилювань чи холіварів. Функціональне — те саме. І лише навколо ООП не вщухають бурі. Одні верещать від нього в захваті, інші, навпаки, хаять.

І, чесно сказати, абсолютно незрозуміло, чому на ООП весь світ клином зійшовся.

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

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

Але сьогодні весь інтернет кишить пихатими, гіперемоційними, радикалістськими статтями з приводу ООП. Якщо один каже, що ООП — «зер гут» і взагалі всім гутам гут — то інший обов’язково мовить, що ООП необхідно терміново викинути на смітник. Третього не дано.

Я хочу саме привнести третій елемент. Спокійно, без хайпа та лайки розповісти, чому ООП — не еліксир від усіх хвороб, але так само, як і ПП, ФП чи ЛП має право на існування.

Отже, спокійна стаття про ООП робітничо-селянською мовою. У ній я спробую розглянути основні доводи противників ООП та обґрунтувати їхню неспроможність.

1 Все, що є в ООП, вже давно є в інших парадигмах

Майже всі мови програмування — тьюрінг-повні, за винятком мов розміток: HTML, XML, CSS тощо.

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

Те саме можна сказати і про парадигми. Усі відмінності мов (і парадигм) — це різні способи реалізації тих чи інших команд, крім окремих лексичних особливостей.

До речі, цю ж тезу (все, що є в N, є і в M, і в K, і в R і т.д.) можна сформулювати так: молоток вже складається із заліза та дерева, навіщо нам ще й пасатижі? Але ж так ніхто не стверджуватиме.

2 ООП змішує дані та дії над ними. Це погано

Аргумент висмоктаний із пальця. По-перше, де ООП змішує дані та функції? По-друге, твердження, що це погано, теж взято зі стелі. З бочки «справжній чоловік так не робить», а чому — та тому що гладіолус.

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

І жодних змішувань даних та операцій тут не відбувається, об’єкт — це не функція та не оператор. Це абстракція.

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

Тут треба трохи пригальмувати. Спадкування зовсім не передбачає будівництва кілометрових дерев з метою уповільнювати розробку. Спадкування придумане для того, щоб виділяти загальні властивості та методи в суперклас, причому робити це потрібно з класами, які представляють однотипні об’єкти. Помилка створюватиме, наприклад, два класи, один з яких — спадкоємець іншого, бо тут немає виділення загального коду в суперклас просто тому, що тут немає нічого спільного.

Якщо не передбачається розширювати батьківський клас третім класом, таке успадкування просто безглуздо. Якщо ви створюєте магазин спиртних напоїв, то класи Beer, Vodka і Vine можна успадкувати від класу Alcohol, але зовсім не потрібно створювати ще й клас Drinks, якщо ви не хочете продавати ще, скажімо, парагвайський чай.

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

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

4  Інкапсуляція не має сенсу

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

Але це правильно лише суто технічно.

Філософія ООП каже: правильно організований та інкапсульований клас можна розглядати як чорну скриньку.

Уявіть коробку, на одній стороні якої різноманітні кнопки, слоти для подачі даних, а на іншій — вихідний слот, який повертає інформацію. Візьмемо, наприклад, стек. Уявіть коробку, на одному боці якої є один слот для вставки даних та кнопка push поряд. На звороті — кнопка pop. Ви подаєте туди записку з числом 8 і тиснете кнопку push. Потім подаєте ще папірець і вдруге тиснете push. І так N разів, а потім тиснете pop. З шухляди вилітає папірець з числом 76 (або інше — те, яке ви подали). Потрібне ще число? Вдруге тисніть pop. І так доти, доки ящик не спорожніє. А якщо ви продовжите тиснути pop, механізм із ящика завиє: стек порожній! Саме так виглядає об’єкт.

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

Інкапсуляція — своєрідна милиця, що підтримує сотню стовпів вашої програми, поки ви конструюєте сто перший. У великих проєктах (а саме для їх створення і вигадали ООП) без цього, на жаль, ніяк.

Хоча навряд це «на жаль» тут взагалі доречно.

5 У реальному світі немає ієрархій відносин, всюди лише ієрархії включення

Та хіба? Але ж ніхто не заважає створити, наприклад, ієрархію, де всі річки світу (Конго, Сена, Темза, Амазонка, Колима тощо) — об’єкти однієї всеосяжної «Річки», якій притаманні властивості (наприклад, складається з води) та дії (наприклад, тече), а вже вона успадковуватиметься від «Водоєма», який теж складається з води, а від «Водоєма» можна успадкувати ще й «Озеро», об’єктами якого будуть окремі озера (Байкал, Каспійське море, Тітікака тощо).

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

І все-таки нас не має бентежити, що немає ні «об’єкта», ні «шкарпетки».

6  Методологія ООП спочатку помилкова

Абсолютно необґрунтований аргумент. ООП створювалося у тому, щоб моделювати своєрідний віртуальний світ, що складається з об’єктів, як і наш світ. Наприклад: людина — об’єкт із реального світу. Вона може ходити, бігати, їсти, спати, грати у футбол, дивитися футбол, але, на жаль, я тут не можу все перерахувати, та й, чесно сказати, все перераховувати було б гидко.

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

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

7 Але навіть мільйони мух не переконають нас, що гній — це смачно

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

Але подумайте, а якби на п’єдестал зійшло не ООП, а, скажімо, ЛП? Думаєте, було б усе інакше? Нічого подібного! Знайшлися б і фанати, і злісні супротивники, а на ООП дивилися б як на інструмент (до цього я, взагалі-то, і закликаю), а не як на таблетку, створену самим Богом і тому незамінну.

Чому ця стаття на захист ООП?

Всі сучасні розмови про парадигми програмування, як мені бачиться, зводяться до двох діаметральних посилів: залишимо ООП і викинемо все інше, або викинемо ООП і… ну, ви зрозуміли мене.

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

Якщо вам не подобається ООП

Кому — ООП, кому — ФП, кому — ЛП. А комусь, можливо, взагалі найбільш милий свинячий хрящик. Якщо ви не любите кішок — напевно, ви просто не вмієте їх готувати.

Читайте також: Деякі мови спотворюють розум: як програмування насправді впливає на ваш мозок

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