КИЇВСЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ
ІМЕНІ ТАРАСА ШЕВЧЕНКА
Факультет комп’ютерних наук та кібернетики
Реферат
з дисципліни «Формальні методи розробки програмних систем»
на тему «Які особливості у розробку програм вносять об’єктно-орієнтовані методи?»
Виконав
студент групи ІНФ-1
Роговий Антон Вадимович
Київ – 2022
Зміст
Вступ 3
Історія створення та розвитку 3
Основні принципи ООП 7
Наслідування 7
Інкапсуляція 8
Метод 8
Поліморфізм 9
Абстракція 9
Принципи SOLID для об’єктно-орієнтованого дизайну 10
Принцип єдиного обов’язку (SRP) 10
Принцип відкритості та закритості (OSP) 10
Принцип підстановки Лісков (LSP) 11
Принцип розділення інтерфейсу (ISP) 11
Принцип інверсії залежностей 13
Вплив об’єктно-орієнтованого підходу 13
Тестування об’єктно-орієнтованого коду 13
Шаблони проектування GoF 14
Закон Деметри 15
Висновок 16
Використані джерела 17
Вступ
Об’єктно-орієнтована парадигма є домінуючою серед сучасних мов програмування. Незважаючи на те, що більшість мов програмування високого рівня об’єднують в собі декілька парадигм, саме об’єктно-орієнтована парадигма об’єднує всі найпопулярніші мови програмування. У даній роботі буде розглянуто особливості, які у розробку програм вносять об’єктно-орієнтовані методи.
Історія створення та розвитку
Парадигма об’єктно-орієнтованого програмування виникла в середині 20 століття на основі процедурної парадигми. Мови процедурного програмування містили функції (процедури) та прості структури даних. Проблемою була часткова чи повна відсутність формального зв’язку між даними та функціями.
Першою мовою в якій використовувались принципи об’єктного підходу була Simula. Мова розроблялася у 1960 році у Норвезькому Обчислювальному Центрі в Осло, Норвегія. Версія мови Simula 67 мала об'єкти, класи, підкласи, віртуальні методи, копрограми, симуляцію дискретних подій, та автоматичне прибирання пам'яті. З точки зору синтаксису, мова програмування Симула є розширенням Алгола 60.
На рисунку 1 наведено приклад простої програми мовою Simula. На прикладі зображено абстрактний клас Glyph (знак), що містить віртуальний метод print, реалізація якого повинна буде виводити знак на пристрій виводу. В якості реалізацій наведено класи Char (символ) та Line (строка). Можна звернути увагу, що означення класу Line є рекурсивним, тобто містить у собі посилання на об’єкти батьківського класу.
Ідея ООП була розвинута Аланом Кеєм та Деном Інгаллосом у мові Smalltalk. Мова Smalltalk стала першою широко використованою об’єктно-орієнтованою мовою програмування. Розробка на Smalltalk має два глобальні паравила [3]:
Все є об’єктом
Об’єкти реагують лише на повідомлення
Рисунок 1. Приклад ООП на мові Simula 67
Рисунок 2. Приклад OOПна мові Smalltalk
Вище наведено приклад об’єктно-орієнтований код на мові Smalltalk (рис. 2). Маючи певний абстрактний клас Kitchen Object, реалізовано два під-класи Dishwasher та Baker. На цьому прикладі можна побачити використання поліморфізму (властивість name) та явне використання статичного контексту класу (classVariableNames: ‘’). У наступних розділах реферату будуть детальніше розглянути ці особливості об’єктно-орієнтованого програмування.
Не можна не згадати про мову, що найбільше вплинула на розвиток більшості сучасних мов програмування та і зараз залишається однією з найбільш використовуваних мов. Мова C++ була розроблена під впливом C та SmallTalk Б’ярном Страуструпом в AT&T Bell Laboratories. Першою версією назви була «Сі з класами», що досить точно описує основну ідею створення C++. Компілятори мови C++ повинні підтримувати всі засоби мови C настільки, щоб програма написана на C могла б бути успішно скомпільована, або використана як модуль мови С++. Особливістю ООП у мові С++ є підтримка узагальненого програмування через шаблони, що дозволяє писати об’єктно-орієнтований код використовуючи об’єкти класів, яких ще не має у програмі.
Рисунок 3. Приклад ООП на мові С++
На основі синтаксису на об’єктно-орієнтованої семантики були створені мови C# та Java. Мови JavaScript та Python мають менш строгі обмеження на вибір програмістом парадигми для написання коду, але все ж містять засоби для написання об’єктно-орієнтованого коду.
Основні принципи ООП
Об’єктно-орієнтована розробка може відрізнятися в залежності від мови програмування, але існує кістяк понять, що формують парадигму об’єктно орієнтованого програмування.
Наслідування
Концепція наслідування була вперше описана у мові Simula [2]. Наслідування вважається однією з унікальних концепцій, що вперше з’явилася саме при об’єктно-орієнтованому підході.
Наслідування – механізм, що дозволяє організовувати об’єкти в програмі в якості чіткої ієрархії. Об’єкти можуть ділити спільні властивості та методи і дозволяє дочірнім класам мати всі ознаки батьківських і розширяти та переозначувати їх. Також наслідування допомагає будувати кодову базу на принципі послідовного уточнення властивостей сутностей предметної області використовуючи абстрактні класи та віртуальні методи [4].
Об’єкт
Вперше концепція об’єкту була застосована в мові Simula [2]. Об’єктом прийнято вважати все, що має стан, поведінку та ідентичність. Об’єкт – це сутність певного класу [4].
Клас
Поняття класу, також вперше означено у Simula, є ключовим поняттям об’єктно-орієнтованого програмування. Клас – це інкапсуляція сукупності даних та операцій над ними. Під час розробки, клас надає програмісту інтерфейс взаємодії з певними об’єктами, що будуть створені в рамках цього класу під час виконання програми.
Інкапсуляція
Одним із найбільш контроверсійних принципів ООП є інкапсуляція. До сих пір, у кругах програмістів ідуть дебати про те, чи все ж таки є інкапсуляція. Існує декілька версій:
За першою версією, інкапсуляція – це процес об’єднання даних та операцій над цими даними у рамках однієї неподільної сутності. Такий концепт використовувався у мові Simula;
За друга версією, інкапсуляція – це форма приховування деталей стану об’єкта за строго означеним публічним інтерфейсом. Таким чином інкапсуляція вже була властива багатьом мовам процедурного програмування, наприклад, мові С;
За третьою версією, поняття інкапсуляція об’єднує поняття наведені вище.
Підсумовуючи, інкапсуляція для розробника – це інструмент створення інтерфейсів для об’єктів програми, обмежуючи зміну стану цих об’єктів певним набором «санкціонованих» змін – методів.
Метод
Концепт процедури як певного набору інструкцій для повторного використання існував досить довгий час. Але концепт методу як набору інструкцій, що асоційовані з певним об’єктом, що є операндом цього набору інструкцій вперше був означений у Simula та розвинений у SmallTalk.
З точки зору розробника публічний метод класу – це «легальний» спосіб змінити внутрішній стан об’єкту певного класу. Це дозволяє використовувати код написаний іншим розробником без ризику порушити логіку поведінки сутності.
Поліморфізм
Концепт поліморфізму, так чи інакше, використовувався у мовах програмування до об’єктно-орієнтованих. Загалом, це можливість використовувати певний інтерфейс абстрагуючись від його реалізації [4].
Виділяють три типи поліморфізму:
Спеціалізований поліморфізм — коли функції з однаковою назвою реалізовують різну логіку для різних типів вхідних параметрів. Підтримується в багатьох мовах програмування через перевантаження функцій.
Параметричний поліморфізм — коли код написаний без указування конкретного типу параметрів. В ООП це називається узагальнене програмування. Це основний тип поліморфізму в функційному програмуванні.
Поліморфізм підтипів — коли під одним ім'ям може використовуватись декілька типів похідних від одного базового. Основний тип поліморфізму в ООП.
Принцип абстракції – це спосіб організації коду (об’єктно-орієнтованого, в нашому випадку), побудова ієрархії об’єктів на принципі уточнення певних ознак сутностей предметної області. Класи мають максимально просто описувати об’єкти реального світу та розділяти рівні відповідальності за певні риси/ознаки між своїми нащадками.
Принципи SOLID для об’єктно-орієнтованого дизайну
Принципи SOLID – це набір базових принципів для розробки програм об’єктно-орієнтованими мовами програмування, сформульованих теоретиком програмування Робертом Мартіном. Основна тема цих принципів – надати розробникам обмеження, що допоможуть писати підтримуваний об’єктно-орієнтований код. Принципи SOLID не є обов’язковими для виконання і не є обмеженнями на рівні мови, платформи чи засобів програмування, а є рекомендаціями, що зараз є широко визнаними в індустрії.
Принцип єдиного обов’язку (SRP)
Роберт Мартін стверджував – «Повинна бути лише одна причина, щоб змінити клас». За принципом єдиного обов’язку класи повинні бути максимально спрощені до виконання однієї функції предметної області. Наприклад, якщо взяти клас Рахунок, то очевидно, що це контейнерний клас, що має певний стан – поля та строки рахунку. Його методами можуть бути різного роду геттери чи сеттери, але ніяк не вивантаження рахунку з бази даних, веб-сервісу, файлу, тощо. Для таких цілей необхідно розробити окремі класи-лоадери і, можливо, винести логіку для окремих джерел даних у реалізації батьківського абстрактного класу [6].
Такий підхід до розбиття функціоналу певних сутностей предметної області дозволяє зробити класи максимально простими і регрес-незалежними.
Принцип відкритості та закритості (OSP)
За принципом відкритості та закритості програмні сутності (модулі чи класи) повинні бути відкритими до розширення та закритими до змін. Під розширенням, зазвичай мається на увазі наслідування.
За принципом OSP програміст, що пише модуль повинен надавати можливість програмісту, що модуль буде використовувати, розширювати функціонал без необхідності змінювати код класів. Наприклад, маючи клас JwtValidator, що містить метод Validate(JWTToken token), для зміни критеріїв валідності токену нам потрібно буде змінити метод Validate, що є помилкою. Кращим рішенням буде додати у клас валідатора колекцію правил (делегатів), які будуть примінятися у методі Validate. Таким чином, для розширення функціоналу валідації необхідно буде лише доповнити колекцію і за потреби розширити клас правила.
Принцип підстановки Лісков (LSP)
Принцип був запропонований Барбарою Лісков у 1987 році на конференції у доповіді «Абстракція даних та ієрархія» [6]. За принципом підстановки Лісков, функції (або методи), що використовують об’єкти базового класу, повинні мати можливість працювати з об’єктами класів-нащадків не знаючи про це.
Наприклад, маючи ієрархію Квадрат є Прямокутник. Математично, ця ієрархія є вірною, оскільки квадрат є частковим випадком прямокутника. Але як, в такому випадку повинен працювати сеттер довжини чи ширини на квадраті? У випадку, коли код очікує одну поведінку, а отримує іншу в залежності від класу-нащадку, це може призвести до дуже неочевидних помилок у програмі.
Принцип розділення інтерфейсу (ISP)
Далі будемо узагальнено вважати абстрактний клас та інтерфейс інтерфейсом. Принцип розділення інтерфейсу полягає у обмеженні функціоналу інтерфейсів. Інтерфейси повинні мати мінімальну кількість методів для реалізації і ці методи повинні бути вузько орієнтованими.
Наприклад, маючи абстрактний клас з великою кількістю методів, які треба означити. Більшість з цих методів можуть бути не потрібні розробнику, а залишати якісь заглушки є поганим вирішенням проблеми. З точки зору розробника абстрактного класу, інтерфейс потрібно було розділити на частини в залежності від їх призначення. Наприклад, окремий інтерфейс для читання та окремий інтерфейс для читання та запису.
Рисунок 4. Приклад реалізації абстрактного класу з великою кількістю методів
Рисунок 5. Використання принципу інверсії залежностей
Принцип інверсії залежностей
Принцип інверсії залежностей полягає у заміні залежності від реалізації на залежність від певної абстракції (інтерфейсу). Таким чином код буде посилатися лише на певний абстрактний функціонал, конкретизуватися який буде на рівні виклику.
Наприклад, необхідно реалізувати клас Reader, що вичитує дані з джерела (рис. 5). Джерелом може бути файлова система, база даних, мережа, тощо. За принципом інверсії залежностей, достатньо використати абстрактний клас чи інтерфейс і вже на рівні виклику використовувати реалізацію, що читає дані з певного ресурсу. Таким чином, розробку реалізацій можна вести паралельно.
Вплив об’єктно-орієнтованого підходу
Об’єктно-орієнтоване програмування призвело до змін у програмній інженерії. Об’єктно-орієнтовані мови зумовлюють розвиток нових концепцій та класичних підходів на різних етапах розробки програм. У цьому розділі буде наведено деякі додаткові концепції, що виникли під впливом ООП.
Тестування об’єктно-орієнтованого коду
Вище наведені принципи об’єктно-орієнтованого програмування вносять зміни у процес тестування програмного забезпечення. Окрім використання модульних тестів, широкого використання набуває тестування на основі макетів (mock-testing).
У модульному тестуванні, макети об’єктів можуть моделювати поведінку складних реальних класів там, де складно або проблематично використовувати повноцінну реалізацію. Наприклад, макети можуть застосовуватися у наступних ситуаціях:
Емуляція недетермінованих процесів
Емуляція помилок
Емуляція джерела даних
Макети об’єктів широко розповсюджені у технологіях розробки та проектування на основі тестів. На стадії планування, означивши основні абстракції, можна писати код тестів (і реалізацій) без необхідності повної імплементації.
Зараз існує багато бібліотек, що допомагають автоматично згенерувати об’єкт макету. Такі засоби доступні у всіх мовах об’єктно-орієнтованого програмування.
Рисунок 6. Ініціалізація сутності об’єкту макета
На прикладі (рис. 6), можна побачити типовий спосіб тестування алгоритму, що використовує інтерфейс без реалізації. Достатньо задати певний стан і вихід основних методів.
Шаблони проектування GoF
Розвиток об’єктно-орієнтованого програмування призвів до виникнення класичних підходів до організації коду та архітектури програми – шаблони проектування. Колектив авторів також відомий як «Банда чотирьох» (англ. Gang of Four; GoF) створила одну з найбільш впливових книг на тему шаблонів проектування «Шаблони проектування: Елементи повторно використовуваного об'єктно-орієнтованого програмного забезпечення». Автори книги: Еріх Гамма, Річард Хелм, Ральф Джонсон, Джон Вліссідес, запропонували та описали 23 типових шаблонів, які стали класичними і широко використовуваними у програмній інженерії [8].
Шаблони наведені у книзі використовують основні механіки об’єктно-орієнтованого програмування для розв’язання певної архітектурної задачі. Хоча зловживання використанням шаблонів програмування піддається критиці, зокрема через суттєве ускладнення написаного коду, коли шаблон не підходить для вирішення задачі, вони залишаються орієнтиром для багатьох розробників на об’єктно-орієнтованих мовах.
Закон Деметри
Закон Деметри — правило дизайну при розробці програмного забезпечення, зокрема об'єктно-орієнтованих програм [9]. Узагальнено, Закон Деметри є окремим випадком слабкої зв'язності. Правило було винайдено у Північносхідному Університеті (Бостон, Массачусетс, США) наприкінці 1987 та може бути сформульоване одним з таких способів:
Кожен модуль має володіти обмеженим знанням про інші модулі: тільки про модулі, які мають «близьке» відношення до даного модуля.
Кожен модуль має розмовляти тільки зі своїми друзями, не розмовляти з незнайомцями.
Звертатись тільки до безпосередніх друзів.
Висновок
Під час написання реферату було розглянуто основні концепції об’єктно-орієнтованого програмування та особливості, які вносить такий підхід у розробку програмного забезпечення. Було розглянута історія розвитку ООП і те, як та чи інша властивість розвивалася у призмі різних мов програмування.
Сьогодні ООП є провідною парадигмою при розробці програмного забезпечення, оскільки такий підхід максимально приближений до реального світу. На відміну від функційного програмування, що використовує багато математичних концепцій, об’єктно-орієнтоване програмування для освоєння людиною без підготовки. Через це, об’єктно-орієнтовані мови по типу Java є основними мовами для Enterprise-розробки, оскільки підготовка спеціалістів для таких мов є значно дешевшою.
В той же час, розробка шаблонів та принципів ООП дозволяє уніфікувати підхід до розробки, тим саме роблячи об’єктно-орієнтовану розробку майже безальтернативною у випадку систем з великою кодовою базою і великою кількістю розробників з усього світу.
Використані джерела
Об'єктно-орієнтоване програмування [Електронний ресурс] – Режим доступу до ресурсу: https://uk.wikipedia.org/wiki/%D0%9E%D0%B1%27%D1%94%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D1%96%D1%94%D0%BD%D1%82%D0%BE%D0%B2%D0%B0%D0%BD%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F.
Simula [Електронний ресурс] – Режим доступу до ресурсу: https://uk.wikipedia.org/wiki/Simula.
Hendrix B. Object Oriented Programing in Smalltalk / Bryce Hendrix
Armstrong D. The Quarks of Object-Oriented Development / Deborah Armstrong. // Communications of the ACM. – 2006. – С. 123–128.
Tchepak D. An introduction to the SOLID principles of OO design [Електронний ресурс] / David Tchepak. – 2013. – Режим доступу до ресурсу: https://davesquared.net/2009/01/introduction-to-solid-principles-of-oo.html.
Barbara L. Keynote address - data abstraction and hierarchy / Liskov Barbara. // ACM SIGPLAN Notices. – 1987.
Макет об'єкта [Електронний ресурс] – Режим доступу до ресурсу: https://uk.wikipedia.org/wiki/%D0%9C%D0%B0%D0%BA%D0%B5%D1%82_%D0%BE%D0%B1%27%D1%94%D0%BA%D1%82%D0%B0.
Elements of Reusable Object-Oriented Software [Електронний ресурс] – Режим доступу до ресурсу: http://www.uml.org.cn/c++/pdf/DesignPatterns.pdf.
Lieberherr K. Law of Demeter: Principle of Least Knowledge [Електронний ресурс] / Karl Lieberherr – Режим доступу до ресурсу: http://www.ccs.neu.edu/home/lieber/LoD.html.