Сьогодні ми обговорюємо ООП (об’єктно-орієнтоване програмування) з погляду новачків. Цей термін доволі часто зустрічається у програмі навчальних курсів, і новачки не завжди можуть зрозуміти, що саме їм потрібно знати. Давайте про все це поговоримо.
Парадигми програмування
ООП – це парадигма програмування. Парадигма – це спосіб погляду на щось, набір шаблонів мислення. Коли ми дивимося на будь-що, ми це сприймаємо через якусь призму, парадигму. Так працює людське мислення. Наприклад, ви хотіли дізнатися, чи є на вулиці місця для паркування, відповідно опинившись на вулиці, мозок вихоплює інформацію про наявність місць для паркування і ким вони зайняті. Зараз для вашого мозку вулиця — це набір місць для паркування. Або ви можете оцінювати ситуацію на вулиці з погляду погоди або ще з якихось аспектів.
Застосовуючи це до програмування, парадигма означає, що ми будемо розділяти предметну область чи те, що ми збираємося автоматизувати. Пам’ятаємо, що програмування – це про автоматизацію чогось. Для того, щоб автоматизувати, ми повинні в голові розділити завдання (декомпозувати) на якісь елементи. Ось які елементи ми отримаємо, від цього залежатиме і різниця парадигм. Просто послідовне виконання завдань, тобто, розподіл на алгоритмічну послідовність дій.
У якийсь момент програмісти подумали і зрозуміли, що одні й ті самі дії виконуються регулярно, але над різними даними, чому б не виділити це в одну процедуру. Так виникла процедурна парадигма.
Процедурна парадигма
У рамках такої парадигми програміст поділяє всі дії, що відбуваються, на процедури. Наприклад, ми викликаємо якусь одну процедуру з одними даними, потім її з іншими даними, потім викликаємо якусь ще процедуру тощо. Ми не виконуємо всі дії поспіль, а розглядаємо завдання як набір викликів процедур.
Процедурна парадигма існувала дуже довго і існує досі, є багато мов програмування, які працюють виключно у процедурній парадигмі. Наприклад, досі популярна мова С і вона також використовує процедурну парадигму. Ця мова застосовується для написання програм для не надто потужного заліза, зазвичай це вбудоване залізо: бортові комп’ютери автомобілів, літаків, а також якихось маленьких пристроїв і т.д. У цих випадках якраз часто використовується мова С, тому що це проста парадигма, яка не потребує великих ресурсів від комп’ютера.
Основна проблема в тому, що процедурна парадигма зрозуміла і зручна, коли розробник пише досить невелику програму. Але в реальному світі існують великі та складні завдання, над якими працює величезна кількість розробників. У цей момент раптово з’ясовується, що велика програма, що складається з процедур, абсолютно не підтримується.
На зорі своєї програмістської кар’єри я працював над такою програмою. У нас був файлик, куди ми скидали всі наші процедури. В результаті їх накопичилося стільки, що знайти потрібне там було неможливо, тому що неможливо нормально відсортувати та розкласти по різних файлах та каталогах. Ви маєте різні процедури, але за яким параметром їх сортувати? За буквою? Цифрою? Чисельностю? Щодо зв’язку з чимось? Коли я нарешті зайнявся рефакторингом (наведенням порядку в коді), в результаті виявилося, що там була величезна кількість процедур, які називалися, умовно «Слово 1 Слово 2», а деякі «Слово 2 Слово 1». Як так сталося? Якийсь програміст не знайшов потрібну процедуру і написав свою, таку саму, але з іншою назвою. Були деякі процедури, які нічого не викликали. При цьому за сучасними мірками це була дуже невелика програма, але на ній працювало понад 10 розробників. У результаті вийшло хтозна що.
Тому програмісти зрозуміли, що так не працює, що треба розділяти програми на якісь осмислені блоки. Так виникло об’єктно-орієнтоване програмування (ООП). Або, по-іншому, об’єктно-орієнтована парадигма.
Об’єктно-орієнтована парадигма
Вся предметна область ООП сприймається як набір об’єктів. Об’єкти – це дані, їх стан та їх поведінка. Під поведінкою розуміється те, як з об’єктом можна поводитися і за які методи його можна смикати. Таким чином, ми отримуємо набагато більш логічне розбиття програми на блоки. Тому що якщо у вас є якась предметна область, яку ви збираєтесь автоматизувати (наприклад, завод, магазин, спорт клуб тощо), там у будь-якому випадку є якісь об’єкти. Є об’єкт Заняття, є об’єкт Купівля, є об’єкт Товар, є об’єкт Чек і таке інше. Ось у всіх цих об’єктів є стан: є ціна цього чека, дата, хто купив тощо. Є поведінка об’єкта: порахуй свою суму, порахуй, коли тебе відвантажили, порахуй ще щось таке.
Відповідно, програму можна розбити на блоки набагато логічніше. Це означає, що можна написати набагато більшу програму, не втрачаючи керованості та можливості підтримувати її. Під «підтримувати» мається на увазі вносити зміни, різні виправлення та покращення.
Об’єктно-орієнтована парадигма на сьогоднішній момент є фактично ультимативною. Вона, з одного боку, досить проста та зрозуміла. Я вам розповів основне про цю парадигму за кілька хвилин. З іншого боку — вона дуже потужна, на ній можна писати величезні програми, дуже складний код.
Якщо парадигма легка для розуміння, то в ній легше знаходити помилки. А чим легше знаходити помилки, тим менше їх буде у коді. Менше помилок = надійніша програма. Тому на сьогоднішній момент об’єктно-орієнтована парадигма є золотою серединою між простотою та надійністю.
Звісно,
Ніші, для яких ООП не підходить
Як у будь-якому напрямку в ООП є свої переваги та недоліки. Наприклад, ООП не дуже підходить для роботи з потоковими даними. Тобто, коли у вас немає об’єктів у предметній області, а є потік даних. Натягнути ООП на такі завдання дуже складно. Для цього якраз чудово підходить функціональна парадигма. Тому більшість компаній, які займаються стрімінговими сервісами типу Netflix і Megogo, використовують саме функціональну парадигму для того, щоб обробляти великі потоки даних. Але переважна більшість ніш, у яких немає потоків даних, а є цілком реальні об’єкти, з якими ми взаємодіємо, використовують ООП.
ВАЖЛИВИЙ ВІДСТУП. Якщо ви та сама людина, яка зараз обирає курс з навчання програмуванню, подумайте над тим, що в цьому курсі вам збираються дати. Я розповів вам фактично все, що ви повинні знати про саму парадигму ООП. Так, ще добре знати три принципи ООП (спадкування, поліморфізм та інкапсуляція), але далі заглиблюватись не обов’язково. При цьому на багатьох курсах розділ ООП займає величезний блок чи не на місяці занять. На мою думку все ООП потрібно освоювати виключно на реальних завданнях. А теорії вам достатньо й тієї, що я дав. Далі просто берете завдання та робите його, починайте писати код. Так що добре придивляйтеся до тих курсів, які вивчаєте. Можливо, ООП звучить складно і тому багато курсів на цьому грають.
Взагалі ООП така штука, що її easy to learn, hard to master. Дуже легко зрозуміти, але важко стати реально крутим майстром. Стати майстром ООП ви зможете лише попрацювавши програмістом, розібравшись із паттернами та іншими складними речами. А ось основи ви вже здобули.
Завжди ваш Сергій Немчинський
Ставте свої запитання щодо ООП у коментарях.
Залишити відповідь