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

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

— А якщо замовник проєкту надав дуже точну його специфікацію?

— Тоді поглянь на ситуацію у часі. Успіх продукту призведе до того, що замовник захоче випустити його нову версію, а потім ще й ще. І, звісно, потрібно буде лише додати «невеликі зміни» до продукту, який вже існує. Тому розробка продукту – це послідовність змін. Лише масштаб часу різний. Кожна нова версія може виходити раз на тиждень, раз на місяць чи раз на півроку.

—І який висновок можна зробити з цього?

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

— І як це зробити?

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

Тепер ми будемо об'єднувати об'єкти (крапки) в групи. Крапки потрібно об'єднати в групу, якщо зв'язки між ними набагато інтенсивніші, ніж з іншими крапками. Якщо більшість стрілочок від крапки йде до крапок її групи, тоді розбиття на групи відбулося правильно. Крапки всередині однієї групи ми називатимемо сильно пов'язаними, а точки з різних груп – слабко пов'язаними.

Це називається «принцип слабкої зв'язності». Програма розбивається на кілька частин, часто шарів, логіка яких сильно зав'язана на їхньому внутрішньому влаштуванні і дуже слабко на інших шарах/частинах. Зазвичай взаємодія шарів дуже регламентована. Один шар може звертатися до іншого та використовувати лише невелику частину його класів.

— Той самий принцип «поділу на відділи» лише у більшому масштабі?

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

— Обрано успішно. А що буде, якщо обрано не успішно?

— Тоді «запас змін» швидко вичерпається і доведеться переробляти всю систему. Таке доводиться робити час від часу. Не можна передбачити, що буде в майбутньому, але можна звести кількість таких переробок до мінімуму.

— Добре. Користь такого поділу я зрозумів, а ООП тут до чого?

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

— А приховування внутрішньої структури цих частин і жорсткі обмеження на взаємодію з іншими частинами – це Інкапсуляція, так?

— Саме так. Інкапсуляція + Абстракція - це наріжні камені ООП. Гарна програма повинна дотримуватися цих двох принципів. Надалі ми розглянемо решту принципів і зрозуміємо, які переваги вони дають.

— Дуже цікаво. Чекаю з нетерпінням.