Мій шлях пізнання об’єктноорієнтованого програмування

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

Від Visual Basic 6 до PHP 4

Колись давно, десь у 2004 чи 2005 році я вивчав/програмував на PHP 4 без жодного ООП і все хотів зрозуміти навіщо воно, бо до того в Pascal та Visual Basic 6 нічого подібного не використовував. Мені тоді було не зрозуміло які саме переваги надає ООП та за якими критеріями я маю організовувати певний код в класи. Усі приклади з ООП в PHP4 були базовані на розробці гостьових книг (після т.з. web2.0 та соціальних мереж забута штука) та форумів або зовсім простих магазинів, які було б простіше реалізувати у процедурному стилі.

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

Від PHP4 до Ruby 1.8 та Ruby on Rails 2.1

Одного разу мій друг запропонував мені перейти на Ruby on Rails, та продемонстрував можливості цього фреймворку на прикладі простого додатка. Я був дійсно вражений, особливо роботою в irb/rails c. Він також порадив мені книжку Agile Web Development with Ruby on Rails, написану автором фреймворку, де коротке введення в Ruby та детальний приклад розробки інтернет магазину з використанням RoR.

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

Знайомство з творчістю Алана Кея, ідеями Smalltalk та акторами у Erlang

Через деякий час після знайомства з Ruby та Ruby on Rails та знаходженням постійної роботи, замість невеличких підробітків на фрилансі, я зацікавився вивченням інших мов програмування, парадигм та власне вивчення первинних джерел, звідкіля узялося ООП.

Це звісно привело мене до постаті видатного інженера та розробника Алана Кея, котрий власне і створив термін та парадигму об’єктноорієнтованого програмування.

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP

Alan Key

Детальніше про пояснення ООП можна дізнатися з публікації на wiki.c2: Alan Kays Definition Of Object Oriented

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

JavaScript та OCaml

Коли у стандарт ECMAScript додали класи багато хто радів, а я на той час вже розумів, що це ніяк не змінює здатностей до об’єктної орієнтованості у JavaScript, адже класи – це не про об’єктну орієнтованість, а про повторне використання коду та побудову не дуже корисних ієрархій типів. Загалом, класи у JavaScript – то був синтаксичний цукор для тих, хто відмовляється зрозуміти JavaScript.

Водночас я почав знайомитися із мовою програмування OCaml, де “O” присвячено об’єктноорієнтованому розширенню до попередника – мови Caml. В OCaml класи та об’єкти існують окремо.

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

Власні експерименти та власне пояснення ООП

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

Публікації

Висновок

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

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *