Чому обєктно-орієнтоване програмування це відстій. Хабрахабр

22.07.2015

Чому об’єктно-орієнтоване програмування — це відстій

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

З зростанням популярності Erlang часто стали задавати питання «— А Erlang — об’єктно-орієнтований?». Правильна відповідь була б «— Та що ви, ні!». Але ми не могли так заявляти в повний голос, тому довелося викручуватися. Ми придумали кілька досить нетривіальних відповідей, які б представляли Erlang типу-об’єктно-орієнтованою мовою (для тих, хто найбільше тягне руку з цим питанням), але при цьому і не об’єктно-орієнтованим для тих, хто насправді в темі.

Тут мені хотілося б згадати тезисний виступ директора французького IBM на 7 конференції IEEE з логічного програмування. Він розповів про те, що IBM додало в Prolog досить багато об’єктно-орієнтованих розширень. На питання про причини цього він відповів:

«— Наші покупці хотіли об’єктно-орієнтований Prolog, тому ми зробили об’єктно-орієнтований Prolog»

Пам’ятаю, я думав «Як добре! Просто, ніяких докорів сумління, ніякого самоаналізу, ніяких сумнівів з приводу того, чи правильно так робити.»

Чому об’єктно-орієнтоване програмування — це відстій

Мої ОСОБИСТІ заперечення по темі ООП — це претензії до його основних положень. Я виділю деякі з цих положень і суть моїх претензій.

Заперечення №1. Структури даних і функції не повинні бути прив’язані один до одного

Об’єкти пов’язують функції і структури даних разом в неподільних сутності. Я думаю, що це фундаментальна помилка, тому що функції і структури даних — поняття, що належать до абсолютно різним категоріям. Чому це так?

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

Структури даних просто існують. Вони не виконують ніяких дій. Вони виключно декларативними. «Розуміння» структури даних в рази простіше «розуміння» функції.

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

Опції зазвичай «розуміються» як частини обчислювальної системи, що передають дані зі структури даних типу T1 в структуру даних типу T2.

Оскільки функції і структури даних — це зовсім різні види тварин, то рішення утримувати їх в одній «клітці» фундаментально невірне.

Заперечення №2. Все повинно бути об’єктом

Розглянемо «час». В об’єктно-орієнтованій мові програмування «час» має бути об’єктом. Але в необъектно-орієнтованій мові «час» — це екземпляр типу даних. Для прикладу, в Erlang є багато різних видів «часу», кожен з яких може бути строго і однозначно визначений. Наприклад, з допомогою таких визначень типів:

Зауважте, що ці визначення не належать ні одного конкретного об’єкту. Вони общеиспользуемы без будь-яких обмежень, тому такі структури даних, представлющие «час» можуть бути використані будь-якою функцією.

Крім того, у них немає ніяких пов’язаних методів.

Заперечення №3. В об’єктно-орієнтованих мовах визначення типів розміщуються повсюдно

В об’єктно-орієнтованих мовах програмування визначення типів даних належать об’єктам. Тому я не можу знайти всі визначення типів даних в одному місці. У Erlang або в C я можу визначити всі мої типи даних в одному-єдиному включається файлі або в словнику даних. В об’єктно-орієнтованих мовах програмування я цього зробити не можу — визначення типів даних розміщуються повсюдно.

Я наведу приклад. Припустимо, я хочу визначити глобально видимий тип даних.

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

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

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

Заперечення №4. У об’єктів є прихований стан.

Стан — це наріжний камінь всіх проблем. Зокрема — необхідно уникати функцій з сайд-ефектами.

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

Що можуть запропонувати мови програмування для роботи з цим станом з реального світу?

  • Об’єктно-орієнтовані мови програмування скажуть « Треба сховати стан від програміста». Стану ховаються, доступ до них можна отримати тільки за допомогою спеціальних функцій;
  • Звичайні мови програмування (C, Pascal) скажуть, що видимість змінних стану повинна регулюватися правилами областей видимості мови;
  • Декларативні мови скажуть, що стану немає.

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

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

Чому ООП так популярно?

  • Причина 1 — всі думають, що його легко вивчити;
  • Причина 2 — всі думають, що з його допомогою можна підвищити ступінь повторного використання коду;
  • Причина 3 — хайп навколо ООП;
  • Причина 4 — воно створює Нову Індустрію Програмування.

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

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

Від перекладача.

Оригінал: Joe Armstrong, взято звідси .

Гучний певних археологічно-програмістських колах текст, написаний Joe Armstrong, автором Erlang. Дату написання тексту достовірно встановити не вдалося, але, судячи за непрямими даними, це було на початку 90х.

Короткий опис статті: об’єктно орієнтоване програмування Коли я перший раз почув про об’єктно-орієнтованому програмуванні — відразу поставився до неї скептично. Чесно кажучи, навіть не знаю, чому. Просто воно здалося мені якимось неправильним. Але… переклад, Erlang, ООП, joe armstrong

Джерело: Чому об’єктно-орієнтоване програмування — це відстій / Хабрахабр

Також ви можете прочитати