Об’єктно-орієнтований підхід, незважаючи на свою розповсюдженість, залишається великою загадкою, що зводить нанівець можливі переваги його використання.
Якість та знання дуже погано масштабуються. Мало хто ставиться до програмування філософськи та взагалі має відповідний світогляд.
Мало хто може похвалитися тим, що працював разом з піонерами, такими як Алан Кей. Мало хто взагалі знає хто такий Алан Кей, та що було у нього в голові, коли він формулював нову, об’єктну парадигму.
Через усе зазначене вище, більшість з розробників не розуміють, навіщо необхідні об’єкти та як із них правильно будувати рішення. Багато хто знає про SOLID принципи, але вони вторинні і не дуже допомагають.
Не пам’ятаю, чиє це твердження, але у програмуванні існує дві основні проблеми: іменування та інвалідація кешу. Цими двома проблемами просотане майже усе і майже всі інше проблеми – це похідні від них.
Проблема іменування, інакше кажучи, це проблема меж, гранулярності та розпізнавання підсистем (чи холонів). Проблема інвалідації кешу – це проблема роботи із тим, що змінюється й знаходиться на відстані, бо з локальними (ізольованими) змінами не має проблем.
Поділяй та володарюй!
Проблеми глобального стану досить відомі і тому я не буду тут про них розповідати. Загалом проблему глобального стану вирішують тим, що від нього позбуваються.
У імперативному програмуванні використовується підхід модуляризації великого цілого. За прикладом можна звернутися до коду ядра – Linux, яке пошматоване на велику кількість модулів, що створюють менші контексти та спілкуються через мінімалістичні, чітко окрестені інтерфейси. Такий підхід дозволяє з’їсти величезного слона маленькими шматочками та не вдавитися.
У чистому функціональному підході було вирішено підійти до проблеми більш радикально та відмовитися від стану взагалі.
У об’єктно-орієнтованому задумом є розділення глобального стану на велику кількість маленьких локальних станів, що ізольовані за чітко окресленими інтерфейсами, які дозволяють безпечно цима станами управляти, без того, аби управляти ними безпосередньо з боку користувача того чи іншого об’єкта.
Об’єкти як чорні ящики
Об’єкти, як і функції, успадковують принцип чорного ящика. Ми не маємо знати про те, що знаходиться всередині, про їх начинку і стан. Пізніше для цієї ідеї було сформовано окремий принцип, аби зробити на ній окремий наголос – TDA (Tell, Don’t Ask – Кажи, а не запитуй).
Якщо у Вашому коді зустічається щось назразок – user.authenticated? чи order.valid?, то це поганий код, що не відповідає ООП підходу, хоча Ви й використовуєте об’єктну семантику. Об’єктна семантика != об’єктно орієнтованований підход.
Якщо Ви говорите об’єкту що необхідно робити, Ви також порушуєте принципи об’єктно-орієнтованого підходу, хоча нічого в об’єкта не питаєте. Об’єкт має сам приймати рішення про те, як йому реагувати на якісь сигнали/повідомлення. Проте, у коді більшості проєктів ми можемо побачити, як об’єктами щось намагається керувати, що намертво зв’язує об’єкт та його менеджера і об’єкт вже не самостійний та ізольований, а його начинка вилізає назовні через роздутий інтерфейс.
Думайте про об’єкти, як про мікросервіси, що спілкуються за допомогою подій з урахуванням основної помилки, яку люди допускають у event driven архітектурах.
Об’єкти як засоби забезпечення інваріантів
Інваріант – це щось незмінне, що зберігається в цілому допоки (і завдяки чому) воно лишається самим собою. Коли інваріант порушується, щось перестає існувати і стає чимось новим. Прикладом інваріанту є твердження про те, що сума кутів трикутника дорівнює 180 градусам. Для будь-якого справжнього трикутника це твердження вірне. Якщо для якоїсь фігури сума кутів не дорівнює 180 градусам, то це точно не трикутник.
Об’єкти є засобом забезпечення значущих для бізнеса інваріантів та будуються навколо них. Коли ми говоримо про безпечні зміни стану, то говоримо про збереження інваріантів. Коли ми говоримо про правильну гранулярність (іменування), то говоримо про інкапсуляцію усіх пов’язаних інваріантів в одній одиниці обчислень (об’єкті).
Залишити відповідь