2.1 Основні концепції ООП
У основі об’єктно-орієнтованого підходу до програмування лежить парадигма ООП. Це коли усі сутності програми розглядаються як об’єкти. Об’єкти — це дані + методи/функції, які з цими даними щось роблять.
Також можна сказати, що у об’єкта є стан і поведінка. Стан об’єкта забезпечується його даними, які зберігаються у його внутрішніх змінних. Поведінка об’єкта — це сукупність усіх дій, які виконують його методи.
Об’єктів у середній програмі тисячі, у великій — мільйони. Щоб якось зменшити хаос, було вирішено організувати об’єкти у класи, а класи об’єктів у деяку ієрархію.
У кожного об’єкта є клас, за допомогою якого його породжують. З одного боку клас — це деякий шаблон об’єкта, з іншого — це самостійний об’єкт із своїми особливостями (про них нижче).
Щоб краще зрозуміти концепцію класів, ознайомтеся з наступними визначеннями:
Клас — це шаблон або схема для створення об’єктів, який визначає атрибути і методи, характерні для всіх об’єктів цього типу. Класи дозволяють організувати дані і функції, що працюють з цими даними, в єдине ціле.
Об’єкт — екземпляр класу. Кожен об’єкт має стан (визначається атрибутами) і поведінку (визначається методами).
Інкапсуляція — полягає у прихованні внутрішньої реалізації класу і наданні інтерфейсу для взаємодії з об’єктами цього класу. Це допомагає захистити дані і керувати доступом до них.
Наслідування — дозволяє одному класу (дочірньому) успадкувати атрибути і методи іншого класу (батьківського). Це сприяє повторному використанню коду і полегшенню його підтримки.
Поліморфізм — дозволяє використовувати єдиний інтерфейс для роботи з об’єктами різних класів. Це досягається за рахунок перевизначення методів у дочірніх класах, які успадковуються від батьківських.
Абстракція — полягає у виділенні спільних характеристик об’єктів і створенні класів, що представляють ці спільні характеристики. Це допомагає спростити складні системи і покращити їх зрозумілість.
Якщо ти зрозумів хоча б половину — круто. Далі ми розберемо кожен із цих пунктів детальніше.
2.2 Абстракція
Гарним прикладом абстракції у реальному житті є опис посад у компанії або організації. Назва посади — це одне, а обов’язки кожної конкретної посади — це вже зовсім інше.
Уяви, що ти проєктуєш структуру своєї майбутньої компанії. Ти можеш розподілити обов’язки секретаря: «розкидати» їх по кількох інших посадах. Можеш розбити посаду виконавчого директора на кілька незалежних посад: фінансовий директор, технічний директор, директор з маркетингу, директор з персоналу. Або, наприклад, об’єднати посади офіс-менеджера і рекрутера в одну.
З точки зору програмування, абстракція — це, скажімо так, правильний поділ програми на об’єкти. Зазвичай будь-яку велику програму можна десятками способів представити у вигляді взаємодіючих об’єктів. Абстракція дозволяє відібрати головні характеристики і опустити другорядні.
Абстракція — це як стратегія у військовій справі. Погана стратегія — і жодна геніальна тактика ситуацію вже не виправить.
2.3 Інкапсуляція
Мета інкапсуляції — покращити якість взаємодії речей завдяки їх спрощенню.
А найкращий спосіб спростити щось — приховати все складне від сторонніх очей. Наприклад, якщо тебе посадять у кабіну Боїнга, ти не відразу розберешся, як ним керувати:
З іншого боку, для пасажирів літака все виглядає простіше: купив квиток, сів у літак, злетіли і приземлились. Можна з легкістю перелетіти з континенту на континент, володіючи лише навичками «купити квиток» і «сідати на літак». Усі складнощі у вигляді підготовки літака до польоту, злету, посадки та різних нестандартних ситуацій приховані від нас. Не кажучи вже про супутникову навігацію, автопілот і диспетчерські центри в аеропортах. І це спрощує нам життя.
З точки зору програмування, інкапсуляція — це «приховування реалізації». Мені подобається таке визначення. Наш клас може містити сотні методів і реалізовувати дуже складну поведінку у різних ситуаціях. Але ми можемо приховати від сторонніх очей усі його методи (обрамити їх імена «__» з двох боків), а для взаємодії з іншими класами залишити всього парочку методів. Тоді всі інші класи нашої програми бачитимуть у цьому класі лише три методи і викликатимуть саме їх. А всі складнощі будуть приховані всередині класу, як кабіна пілотів від щасливих пасажирів.
2.4 Наслідування
У наслідування є дві сторони: сторона програмування і сторона реального життя. З точки зору програмування, наслідування — це спеціальне відношення між двома класами. Але набагато цікавіше, що ж таке наслідування з точки зору реального життя.
Якби нам знадобилося щось створити у реальному житті, у нас було б два рішення:
- створити потрібну нам річ з нуля, витративши купу часу і сил;
- створити потрібну нам річ на основі вже існуючої.
Найбільш оптимальна стратегія виглядає так: беремо існуюче гарне рішення, трохи його доопрацьовуємо, підганяємо під свої потреби і використовуємо.
Якщо ми простежимо історію виникнення людини, то виявиться, що з моменту зародження життя на планеті пройшли мільярди років. А якщо уявити, що людина виникла з мавпи (на основі мавпи), то пройшло всього пару мільйонів років. Створення з нуля — довше. Набагато довше.
У програмуванні теж є можливість створювати один клас на основі іншого. Новий клас стає нащадком (спадкоємцем) вже існуючого. Це дуже вигідно, коли є клас, який містить 80%-90% потрібних нам даних і методів. Ми просто оголошуємо підходящий клас батьком нашого нового класу, і тоді у новому класі автоматично з’являються всі дані і методи класу-батька. Правда, зручно?
2.5 Поліморфізм
Поліморфізм — це поняття з галузі програмування. Воно описує ситуацію, коли за одним інтерфейсом приховані різні реалізації. Якщо спробувати знайти його аналоги у реальному житті, то одним із таких аналогів буде процес керування автомобілем.
Якщо людина може керувати вантажівкою, її можна посадити і за кермо швидкої, і за кермо спорткара. Людина може керувати автомобілем незалежно від того, що це за автомобіль, адже всі вони мають однаковий інтерфейс керування: кермо, педалі і важіль коробки передач. Внутрішній устрій автомобілів різний, але всі вони мають однаковий інтерфейс керування.
Якщо повернутися до програмування, то поліморфізм дозволяє однаково звертатися до об’єктів різних класів (звичайно маючих спільного предка) — річ, яку важко переоцінити. Цінність його тим більша, чим більше програма.
ООП — це принципи. Внутрішні закони. Кожен із них нас в чомусь обмежує, даючи натомість великі переваги, коли програма виростає до великих розмірів. Чотири принципи ООП — це як чотири ніжки стільця. Прибери хоча б одну, і вся система стане нестійкою.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ