Всім привіт.
Тиждень статей на хабрі присвячений ОВП. Остання стаття викликала в мене купу емоцій та, на жаль, дуже поганих емоцій. Мені дуже не сподобалася стаття. Чому? Тому що в ній передаються якісь негативні емоції щодо використання ОВП. Емоції викликані лише тим, що людина не до кінця розуміє всю силу ОВП і хоче переконати всіх у тому, що ОВП є зло. Найсумніше, що люди починають прислухатися і кидатися жахливими доказами, які не мають нічого спільного з дійсністю. Я думаю що студентам такі статті протипоказані більше, ніж GoF, яких я б давав якомога раніше. :)
Почнемо.
Що таке ОВП. ООП - це і ГО програмування та проектування. Одне без іншого безглуздо трохи більш ніж повністю. Створено ОВП для проектування/програмування програмних продуктів. Чи не для моделювання процесів. Не для проектування протоколів, саме для програмних продуктів, їх реалізації. Для спрощення системи, яка реалізовуватиме протокол чи бізнес-процес чи щось ще.
Коли ви починаєте використовувати ООП, перше, що ви повинні зробити - це почати використовувати об'єктне мислення. Я вже колись казав, що це найбільша проблема ОВП, навчитися мислити об'єктно дуже складно. І дуже важливо вчитися це робити якомога раніше (GoF з аналогіями типу міст, конструктор, фасад дуже в цьому допоможуть). Використовуючи об'єктне мислення, ви легко зможете проектувати складні системи Використовуючи об'єктне мислення, ви легко можете вирішити будь-яке завдання (дуже важливо, що будь-яке завдання проектування/програмування, якщо її в принципі можна вирішити абсолютно будь-яку) оперуючи об'єктами та взаємодією між ними. Тобто. ООП без об'єктного мислення не дозволить вам почати використовувати всю силу та міць ООП.
Ходімо далі. Отже, нам важливо мислити об'єктно для того, щоб знайти потрібні нам абстракції об'єктів для вирішення наших завдань. Якщо аналогії та абстракції обрані вдало, то ми бачимо дуже чітку картину, яка дозволяє нам швидко розібратися в тому, що відбувається в системі. І ось тут ми починаємо згадувати про наслідування та поліморфізм. Ці два інструменти необхідні для зручного масштабування системи без дублювання коду. Але сила цих механізмів залежить від того, наскільки вдалі абстракції та аналогії ви обрали. Якщо ваше об'єктне мислення не дозволяє вам сформувати зручну декомпозицію об'єктів, то успадкування та поліморфізм вам не допоможуть. Тобто. успадкування та поліморфізм це ніщо інше як інструменти, які дозволяють вирішити проблему масштабування системи.
Які ж ці інструменти працюють? Та простіше пареної ріпи, бо це все ґрунтується на звичних нам речах. Люблю прості приклади з життя:
1. Спадкування. Є пекар. Є піч електрична та газова. Ваше завдання змоделювати процес приготування їжі пекарем у кожній печі. Вирішуючи завдання в лоб, у нас буде багато дублювання коду через те, що процес передачі їжі в піч і сама робота з печами ідентичні для обох печей. Але якщо ми включаємо об'єктне мислення, і згадуємо про інструмент успадкування, то отримуємо приблизно наступне (діаграму ліньки малювати, соррі):
Є піч (абстрактна піч). Вона має поведінку - включити, вимкнути, збільшити чи зменшити температуру, покласти чогось, дістати чогось і стан - температура в печі, включена чи вимкнена. Це відмінний приклад абстрактного об'єкта в якому дотримані принципи інкапсуляції (при реалізації я їх обов'язково дотримуватимуся). І є пекар, конкретний такий пекар Іван. Він уміє працювати з абстрактною піччю. Тобто. дивитися температуру, включати вимикати і т.д. ви зрозуміли. Сила успадкування в тому, що нам не доведеться переписувати нашого Івана для кожної з печей, чи то електро, чи газова піч. Я думаю всім ясно чому? Виходить, що інструмент застосований правильно.
2. Поліморфізм. Адже печі по-різному працюють. Газова споживає газ, електропіч - електрику. Використовуючи поліморфізм, ми легко змінюємо поведінку в спадкоємцях абстрактної печі.
3. Інкапсуляція. Основна фішка інкапсуляції полягає в тому, що я не повинен знати, що відбувається всередині моєї печі. Допустимо, я викликаю не метод включити піч, а змінюю її властивість включена на значення true. Що станеться у цей момент? Якщо принцип інкапсуляції недотриманий, то буду змушений печі сказати починай споживати пальне, т.к. я тебе увімкнув. Тобто. пекар знає, що піч споживає пальне, знає, як піч працює. Або, наприклад, ми не можемо встановити температуру печі нижче або вище за певний рівень. Якщо не дотримуватися принципу інкапсуляції, то ми повинні будемо говорити печі перевір-ка поточну температуру, чи піде така? Тобто. пекар знову дуже багато знає про печі. Геттери та сеттери це засоби мови, які допоможуть нам легко реалізувати відстеження змін стану. Всі. Якщо гетери та сеттери порожні, значить так треба на моєму рівні абстракції. Геттери та сеттери - не можуть заважати реалізації інкапсуляції, криво реалізувати інкапсуляцію може проектувальник/програміст.
У цьому прикладі рівень абстракції вибрано добре. Всі займаються своїми справами, всі три кити ООП працюють на славу. Але варто мені вибрати погані абстракції, як починається справжній жах. І навіть є стандарти чеклісти, які допоможуть зрозуміти, чи добре ви вибрали абстракції і чи вірна ваша декомпозиція в тому напрямку ви йдете (SOLID).
Ще почали додавати абстракцію як ще один стовп ООП. Я думаю, що це швидше вірно, але дуже пахне КЕПом.
Висловлювання про типізацію мене теж зачепили. Справа в тому, що жодних проблем у тому, з ким ви зараз працюєте зі спадкоємців немає. Якщо на поточному рівні абстракції вам важливо використовувати піч, то вам не важливо яка вона. Ви отримуєте пекти? Ви вирішуєте свої завдання? То те й воно… Чому ви вважаєте, що це динамічна типізація мені не зрозуміло. Ви хотіли пекти? Беріть. Вам потрібна електрична? Ну, вибачте, газова вам уже не підійде.
Інші приклади, які були наведені в статті, що зачепила мене, лише приклади огидно обраної абстракції та аналогії в рамках поставленого завдання. Крапка.
Окремо для DTO. DTO – це патерн. Він дозволяє створити об'єкт, який передасть інформацію іншому шару, іншій системі, коротше кудись щось передасть. Чому вона не може бути розглянута мною як об'єкт для мене взагалі загадка. Де суперечність? Чи є контейнером тільки? Ну і що?? Це ж об'єкт у рамках розглянутої мною об'єктної моделі на заданому рівні абстракції, де DTO – об'єкт та частина декомпозиції.
Про мови також незрозуміло чого говорити. Я можу проектувати програмне забезпечення, використовуючи об'єктний підхід незалежно від мови. Але якщо мова не реалізує основні інструменти для роботи з об'єктами, мені буде дуже складно або неможливо реалізувати спроектовану мною систему.
Ще кажуть, що деякі речі не можна уявити у вигляді об'єктів та їх взаємодії. Я впевнений, що це не так. Просто необхідно вибрати рівень абстракції правильно. Будь то реалізація протоколу, шару доступу до БД, підключення плагінів, менеджера завдань, бізнес-процесу, системи проектування бізнес-процесів, тобто. все, що завгодно можна уявити як об'єкти та їх взаємодію. Все можна реалізувати як об'єкти та взаємодію між ними. Добре це чи погано найчастіше залежить лише від вашого вміння мислити об'єктно.
Резюмуючи. Якщо ви не розумієте силу ОВП, то, швидше за все, вам треба розвивати об'єктне мислення.
P.S. У коментах до минулої статті я явно багато перегинав ціпок при зверненні до деяких людей. Перепрошую.
Чому об'єктно-орієнтованому програмуванню віддається перевага у більшості проектів? ООП пропонує ефективний спосіб боротьби з їхньою складністю. Замість розглядати програму як послідовність виконуваних інструкцій, вона представляє її як групу об'єктів з певними властивостями і робить з ними певні дії. Це призводить до створення більш ясних, надійніших і додатків, що легко супроводжуються.
Основні принципи сформувалися тому, що в існуючих підходах були виявлені обмеження. Серед них – необмежений доступ до даних та велика кількість зв'язків, які накладають обмеження на внесення змін. Їх усвідомлення та причини важливі для того, щоб зрозуміти, що таке ОВП у програмуванні та які його переваги.
Процедурні мови
C, Pascal, FORTRAN та подібні мови є процедурними. Тобто кожен їхній оператор наказує комп'ютеру щось зробити: отримати дані, скласти числа, розділити на шість, відобразити результат. Додаток процедурною мовою є список інструкцій. Якщо він невеликий, жодного іншого організаційного принципу (часто званого парадигмою) не потрібно. Програміст створює список інструкцій і комп'ютер виконує їх.
Поділ на функції
Коли програми стають більшими, список виходить громіздким. Мало хто може зрозуміти більше кількох сотень інструкцій, доки вони не будуть згруповані. З цієї причини функція стала способом зробити програми більш зрозумілими для своїх творців. У деяких мовах та ж концепція може бути назва підпрограми або процедури.
Програма розділена на функції, кожна з яких має чітко визначену мету та інтерфейс.
Ідея поділу на процедури може бути розширена їх групуванням у більший об'єкт, який називають модулем, але принцип аналогічний: групування компонентів, які виконують списки інструкцій.
Поділ на функції та модулі - один із наріжних каменів структурного програмування, яке протягом кількох десятиліть до появи ОВП було довжелезною парадигмою.
Проблеми структурного програмування
Оскільки програми ставали дедалі більшими, структурне програмування почало відчувати труднощі. Проекти ставали надто складними. Графіки зрушувалися. Задіялося більше програмістів. Складність зростала. Витрати злітали, графік зрушувався далі, і наставав крах.
Аналіз причин цих невдач засвідчив недоліки процедурної парадигми. Незалежно від того, наскільки добре реалізований структурований підхід до програмування, великі програми стають надмірно складними.
Які причини цих проблем, пов'язаних із процедурними мовами? По-перше, функції мають необмежений доступом до глобальних даних. По-друге, не пов'язані між собою процедури та значення погано моделюють реальний світ.
Якщо розглядати ці проблеми у контексті програми обліку запасів, одним із найважливіших глобальних елементів даних є сукупність облікових одиниць. Різні функції можуть звертатися до них для введення нового значення, його відображення, зміни тощо.
Необмежений доступ
У програмі, написаній, наприклад, C, є два види даних. Локальні приховані всередині функції та іншими процедурами не використовуються.
Коли дві і більше функцій повинні отримати доступ до тих самих даних, останні мають бути глобальними. Такими, наприклад, є відомості про предмети, що враховуються. Глобальні дані можуть бути доступні будь-якій процедурі.
У великій програмі є багато функцій та багато глобальних елементів. Проблема процедурної парадигми полягає в тому, що це призводить до ще більшої кількості потенційних зв'язків між ними.
Така велика кількість з'єднань викликає кілька труднощів. По-перше, це ускладнює розуміння структури програми. По-друге, ускладнює внесення змін. Зміна в глобальному елементі даних може вимагати коригування всіх функцій, які мають доступ до нього.
Наприклад, у програмі обліку хтось вирішить, що код предмета, що враховується, повинен складатися не з 5 цифр, а з 12. Це вимагатиме змінити з short на long. Тепер пов'язані з кодом функції мають бути змінені для роботи з новим форматом.
Коли елементи змінюються у великій програмі, важко сказати, які процедури мають доступ до них. Але навіть якщо це з'ясувати, їхня зміна може призвести до неправильної роботи з іншими глобальними даними. Все пов'язано з рештою, тому зміна в одному місці відгукнеться в іншому.
Моделювання реального світу
Другий і найважливішою проблемою процедурної парадигми і те, що її розташування окремих даних, і функцій погано моделює речі у світі. Тут ми маємо справу з такими об'єктами, як люди та автомобілі. Вони не схожі ні на дані, ні на функції. Складні реальні об'єкти мають атрибути і поведінку.
Атрибути
Прикладами атрибутів (іноді званих характеристиками) для людей є колір очей та назва посади, для автомобілів – потужність та кількість дверей. Як виявилося, атрибути у реальному світі еквівалентні даним у програмі. Вони мають конкретні значення, такі як синій (колір очей) або чотири (кількість дверей).
Поведінка
Поведінка - те, що об'єкти реального світу роблять у відповідь якийсь вплив. Якщо попросити начальство про підвищення зарплати, відповідь буде так чи ні. Якщо натиснути на гальмо, автомобіль зупиниться. Вимова та зупинка є прикладами поведінки. Поведінка подібна до процедури: її викликають, щоб зробити щось, і вона робить це. Таким чином, дані та функції власними силами не моделюють об'єкти реального світу ефективно.
Рішення проблеми
Об'єкт в ООП представляється як сукупність даних, і функцій. Тільки процедури, які називаються функціями-членами C++, дозволяють отримати його значення. Дані приховані та захищені від зміни. Значення та функції інкапсульовані в одне ціле. Інкапсуляція та сховування - основні терміни в описі ГО-мов.
Якщо потрібно змінити дані, відомо, які функції взаємодіють з ними. Ніякі інші процедури не можуть отримати доступ до них. Це спрощує написання, налагодження та підтримку програми.
Додаток зазвичай складається з декількох об'єктів, які взаємодіють один з одним, викликаючи функції-члени.
Сьогодні найбільш широко використовуване програмування) - C++ (плюс-плюс). У Java відсутні деякі функції, такі як покажчики, шаблони та множинне спадкування, що робить його менш потужним та універсальним, ніж C++. C# ще досяг популярності C++.
Слід зазначити, що так звані функції-члени C++ називаються методами в деяких інших ГО-мовах, таких як Smalltalk. Елементи даних називають атрибутами. Виклик методу об'єкта є посилкою повідомлення.
Аналогія
Можна уявити об'єкти відділами компанії. У більшості організацій співробітники не працюють один день із кадрами, наступного нараховуючи зарплату, а потім тиждень займаючись роздрібною торгівлею. Кожен відділ має свій персонал з чітко покладеними на нього обов'язками. Є й власні дані: показники заробітної плати, продажів, облік співробітників тощо. Люди в відділах працюють зі своєю інформацією. Поділ компанії, таким чином, полегшує контроль за її діяльністю та підтримує цілісність даних. Бухгалтерія відповідає за Якщо необхідно знати загальну суму заробітної плати, що виплачується у південній філії у липні, не потрібно копатися в архіві. Достатньо направити записку відповідальній особі, почекати, поки ця людина отримає доступ до даних та надішле відповідь із необхідною інформацією. Це гарантує відповідність регламенту та відсутність стороннього втручання. Так само об'єкт в ООП забезпечує організацію докладання.
Слід пам'ятати, що орієнтація на об'єкти не стосується подробиць роботи програми. Більшість інструкцій C++ відповідає операторам процедурних мов, таких як С. Справді, функції-члени C++ дуже схожі на функції в С. Тільки ширший контекст дозволить встановити, чи є інструкція процедурною або об'єктно-орієнтованою.
Об'єкт в ООП: визначення
При розгляді завдання програмування на ГО-мові замість питань щодо її поділу на окремі функції виникає проблема поділу на об'єкти. ООП-мислення набагато полегшує розробку додатків. Це відбувається внаслідок схожості програмних та реальних об'єктів.
Які речі стають об'єктами в ОВП? Нижче наведені типові категорії.
Фізичний об'єкт в ОВП - це:
- транспорт у моделях руху потоку;
- електричні елементи у програмах схемотехніки;
- країни у моделі економіки;
- літак у системі управління повітряним рухом.
Елементи середовища комп'ютера користувача:
- меню;
- вікна;
- графіка (лінія, прямокутник, коло);
- клавіатура, миша, принтер, дискові накопичувачі.
- працівники;
- студенти;
- клієнти;
- Продавці.
- книга обліку;
- особиста справа;
- словник;
- таблиця широт та довгота населених пунктів.
Зв'язок об'єктів реального світу та ОВП став результатом поєднання функцій та даних: вони зробили переворот у програмуванні. Такої близької відповідності у процедурних мовах немає.
Клас
Об'єкти в ОВП – це члени класів. Що це означає? Мови програмування мають інтегровані типи даних. Тип int, тобто ціле число, зумовлений C++. Можна оголошувати скільки завгодно змінних int.
Аналогічно визначається безліч об'єктів одного класу. Він визначає функції та дані, що включаються до його об'єктів, не створюючи їх, так само як int не створює змінні.
Клас у ОВП - це опис низки схожих об'єктів. Принц, Стінг та Мадонна є співаками. Немає жодної людини з таким ім'ям, але люди можуть так називатися, якщо вони мають відповідні характеристики. Об'єкт ООП – це екземпляр класу.
успадкування
У житті класи поділені на підкласи. Наприклад, тварини діляться на земноводних, ссавців, птахів, комах тощо.
Принцип такого роду поділу полягає в тому, що кожен підклас має загальні характеристики із класом, від якого походить. Всі автомобілі мають колеса та двигун. Це визначальні характеристики транспортних засобів. На додаток до загальних характеристик кожен підклас має свої особливості. У автобусів багато місць, а вантажівки мають простір для перевезення важких вантажів.
Аналогічно базовий клас може стати батьком кількох похідних підкласів, які можуть бути визначені так, що вони розділятимуть його характеристики з додаванням власних. Спадкування подібне до функції, що спрощує процедурну програму. Якщо кілька частин коду роблять майже те саме, можна вилучити загальні елементи та помістити їх в одну процедуру. Три ділянки програми можуть викликати функцію, щоб виконати спільні дії, але вони можуть виконувати свої власні операції. Подібно до цього базовий клас містить дані, загальні для групи похідних. Подібно до функцій успадкування скорочує ГО-програму і прояснює взаємозв'язок її елементів.
Повторне використання
Після того, як клас створений та налагоджений, він може бути переданий іншим програмістам для повторного використання у власних додатках. Це схоже на бібліотеку функцій, яка може входити до різних програм.
У ОВП успадкування є розширенням ідеї багаторазового використання. З існуючого класу, не змінюючи його, можна створити новий з додаванням інших функцій. Легкість повторного використання існуючого ПЗ – важлива перевага ООП. Вважається, що це забезпечує зростання доходності від початкових інвестицій.
Створення нових типів даних
Об'єкти зручні для створення нових типів даних. Припустимо, у програмі використовуються двовимірні значення (наприклад, координати або широта та довгота), і є бажання висловити дії з ними арифметичними операціями:
position1 = position + origin,
де і origin – пари незалежних чисельних величин. Створення класу, що включає ці два значення, і оголошення змінних його об'єктами створює новий тип даних.
Поліморфізм, перевантаження
Оператори = (рівно) і + (плюс), що використовуються у позиційній арифметиці вище, не діють так само, як із вбудованими типами, такими як int. Об'єкти position та ін не визначені, а задані програмним шляхом. Як ці оператори знають, як з ними поводитися? Відповідь у тому, що їм можна задати нові моделі поведінки. Ці операції будуть функціями-членами класу Position.
Використання операторів чи процедур залежно від цього, з чим вони працюють, називається поліморфізмом. Коли існуючий оператор, такий як + або = отримує можливість працювати з новим типом даних, кажуть, що він перевантажений. Перевантаження ООП - це вид поліморфізму. Вона є його важливою рисою.
Книга про ОВП «Об'єктно-орієнтоване програмування для чайників» дозволить усім охочим ознайомитися з цією темою докладніше.
Основні принципи та етапи об'єктно-орієнтованого
програмування
У теорії програмування ООП визначається як технологія створення складного програмного забезпечення, яка заснована на поданні програми у вигляді сукупності об'єктів, кожен з яких є екземпляром певного типу (класу), а класи утворюють ієрархію з
успадкуванням властивостей.
Взаємодія програмних об'єктів у такій системі здійснюється шляхом передачі повідомлень.
П р і м е ч а н ня.Таке уявлення програми вперше було використане в мові імітаційного моделювання складних систем Simula, що з'явилося ще у 60-х роках.
Природний для мов моделювання спосіб представлення програми отримав розвиток в іншій спеціалізованій мові моделювання - мові Smalltalk (70-ті роки), а потім був
Сторінка 2 з 51 |
Основні засади ООП |
використаний у нових версіях універсальних мов програмування, таких як Pascal, C++,
Основна перевага ОВП- скорочення кількості міжмодульних викликів та зменшення обсягів інформації, що передається між модулями,
в порівнянні з модульним програмуванням. Це досягається за рахунок більш повної локалізації даних та інтегрування їх з підпрограмами обробки,
що дозволяє вести практично незалежну розробку окремих частин
(об'єктів) програми.
Окрім цього, об'єктний підхід пропонує нові технологічні засоби розробки, такі як успадкування, поліморфізм, композиція, наповнення,
що дозволяють конструювати складні об'єкти з більш простих. В результаті суттєво збільшується показник повторного використання кодів,
з'являється можливість створення бібліотек об'єктів для різних застосувань і розробникам надаються додаткові можливості створення систем підвищеної складності.
Основний недолік ООП - деяке зниження швидкодії з допомогою складнішої організації програмної системи.
В основу ООП покладено наступні приклади: абстрагування,
обмеження доступу, модульність, ієрархічність, типізація, паралелізм,
стійкість.
Розглянемо, що є кожний принцип.
А б с т р а г і р о в а н і- процес виділення абстракцій у предметній галузі завдання. Абстракція - сукупність істотних характеристик деякого об'єкта, які відрізняють його від інших видів об'єктів і,
таким чином, чітко визначають особливості даного об'єкта з погляду подальшого розгляду та аналізу. Відповідно до визначення застосовувана абстракція реального предмета істотно залежить від розв'язуваного завдання: в одному випадку нас цікавитиме форма предмета, в іншому вага, в
третьому - матеріали, з яких його зроблено, у четвертому - закон руху
Сторінка 3 з 51 |
Основні засади ООП |
предмета і т.д. Сучасний рівень абстракції передбачає об'єднання всіх властивостей абстракції (як щодо стану аналізованого об'єкта,
так і визначають його поведінку) в єдину програмну одиницю
абстрактний тип (клас).
Обмеження доступу- приховування окремих елементів реалізації абстракції, які не зачіпають суттєвих характеристик її як цілого.
Необхідність обмеження доступу передбачає розмежування двох частин описі абстракції:
інтерфейс - сукупність доступних ззовні елементів реалізації абстракції (основні характеристики стану та поведінки);
реалізація - сукупність недоступних ззовні елементів реалізації абстракції (внутрішня організація абстракції та механізми її поведінки).
Обмеження доступу до ООП дозволяє розробнику:
∙ виконувати конструювання системи поетапно, не відволікаючись на особливості реалізації абстракцій, що використовуються;
∙ легко модифікувати реалізацію окремих об'єктів, що у правильно організованій системі потребує зміни інших об'єктів.
Поєднання об'єднання всіх властивостей предмета (що становлять його стану та поведінки) в єдину абстракцію та обмеження доступу до реалізації цих властивостей отримало назву інкапсуляції.
М о д у л н о с т- принцип розробки програмної системи,
що передбачає реалізацію її у вигляді окремих частин (модулів). При виконанні декомпозиції системи на модулі бажано об'єднувати логічно пов'язані частини, наскільки можна забезпечуючи скорочення кількості зовнішніх зв'язків між модулями. Принцип успадкований від
Сторінка 4 з 51 |
Основні засади ООП |
модульного програмування, слідування йому спрощує проектування та
налагодження програми.
Ієрархія - ранжована або впорядкована система абстракцій.
Принцип ієрархічності передбачає використання ієрархій розробки програмних систем.
В ООП використовуються два види ієрархії.
Ієрархія «ціле/частина»- Вказує, що деякі абстракції включені
у розглянуту абстракцію як її частини, наприклад, лампа складається з цоколя, нитки розжарювання та колби. Цей варіант ієрархії використовується в процесі розбиття системи на різних етапах проектування (логічно - при декомпозиції предметної області на об'єкти, фізично - при декомпозиції системи на модулі і при виділенні окремих процесів у мультипроцесній системі).
Ієрархія «загальне/приватне»- показує, що деяка абстракція є окремим випадком іншої абстракції, наприклад, «обідній стіл -
конкретний вид столу», а «столи – конкретний вид меблів». Використовується при
розробка структури класів, коли складні класи будуються на базі більш простих шляхом додавання до них нових характеристик і, можливо, уточнення існуючих.
Один із найважливіших механізмів ОВП - успадкування властивостей в ієрархії загальне/приватне. Спадкування - таке співвідношення між абстракціями, коли одна з них використовує структурну або функціональну частину іншої або кількох інших абстракцій (відповідно просте та множинне)
успадкування).
Т і п і з ац і я - обмеження, що накладається на властивості об'єктів і
що перешкоджає взаємозамінності абстракцій різних типів (або сильно звужує можливість такої заміни). У мовах з жорсткою типізацією кожного програмного об'єкта (змінної, підпрограми, параметра тощо. буд.)
оголошується тип, який визначає безліч операцій над
Сторінка 5 з 51 |
Основні засади ООП |
відповідним програмним об'єктом. Розглянуті далі мови програмування на основі Паскаля використовують сувору, а на основі С -
середній ступінь типізації.
Використання принципу типізації забезпечує:
∙ раннє виявлення помилок, пов'язаних з неприпустимими операціями над програмними об'єктами (помилки виявляються на етапі компіляції програми під час перевірки допустимості виконання цієї операції над програмним об'єктом);
∙ спрощення документування;
∙ можливість генерації ефективнішого коду.
Тип може зв'язуватися з програмним об'єктом статично (тип об'єкта визначено на етапі компіляції - раннє зв'язування)та динамічно (тип об'єкта визначається лише під час виконання програми - пізніше зв'язування).Реалізація пізнього зв'язування у мові програмування дозволяє створювати змінні - покажчики на об'єкти, що належать різним класам (поліморфні об'єкти),що суттєво розширює можливості мови.
П а р а л е л і з м- властивість кількох абстракцій одночасно перебувати у активному стані, тобто. виконувати деякі операції.
Існує ціла низка завдань, вирішення яких вимагає одночасного виконання деяких послідовностей дій. До таких завдань,
наприклад, відносяться завдання автоматичного керування кількома процесами.
Реальний паралелізм досягається при реалізації завдань такого типу на багатопроцесорних системах, коли є можливість виконання кожного процесу окремим процесором. Системи з одним процесором імітують паралелізм за рахунок поділу часу процесора між завданнями керування різними процесами. Залежно від типу використовуваної операційної системи (одноабо мультипрограмної)
Сторінка 6 з 51 |
Основні засади ООП |
поділ часу може виконуватися або системою, що розробляється (як в
MS DOS), або використовуваної ОС (як і системах Windows).
У т о й ч і в о с т ь- властивість абстракції існувати в часі незалежно від процесу, що породив даний програмний об'єкт, та/або у просторі, переміщаючись з адресного простору, в якому він був створений.
Розрізняють:
∙ тимчасові об'єкти, що зберігають проміжні результати деяких дій, наприклад обчислень;
∙ локальні об'єкти, що існують усередині підпрограм, час життя яких обчислюється від виклику підпрограми до її завершення;
∙ глобальні об'єкти, існуючі поки програма завантажена на згадку;
∙ об'єкти, що зберігаються, дані яких зберігаються у файлах зовнішньої пам'яті між сеансами роботи програми.
Всі зазначені вище принципи тією чи іншою мірою реалізовані у різних версіях об'єктно-орієнтованих мов.
Об'єктно-орієнтовані мови програмування. Мова вважається об'єктно-орієнтованим,якщо в ньому реалізовані перші чотири із розглянутих семи принципів.
Особливе місце посідають об'єктні моделі Delphi та C++Builder. Ці моделі узагальнюють досвід ООП для MS DOS і включають деякі нові засоби,
що забезпечують ефективне створення складніших систем. На основі цих моделей створено візуальні середовища для розробки програм Windows.
Складність програмування під Windows вдалося суттєво
знизити за рахунок створення спеціальних бібліотек об'єктів, які «заховали» багато елементів техніки програмування.
Сторінка 7 з 51 |
Основні засади ООП |
Етапи розробки програмних систем із використанням ООП.
Процес розробки програмного забезпечення з використанням ОВП включає чотири етапи: аналіз, проектування, еволюція, модифікація.
Розглянемо ці етапи.
А н а ліз . Мета аналізу – максимально повний опис завдання. На цьому етапі виконується аналіз предметної галузі завдання, об'єктна декомпозиція системи, що розробляється, і визначаються найважливіші особливості поведінки об'єктів (опис абстракцій). За результатами аналізу розробляється структурна схема програмного продукту, де показуються основні об'єкти та повідомлення, що передаються між ними, а також виконується опис абстракцій.
Проектування. Розрізняють:
логічне проектування,при якому прийняті рішення практично не залежать від умов експлуатації (операційної системи та обладнання);
фізичне проектування,у якому доводиться брати до уваги зазначені чинники.
Логічне проектуванняполягає у розробці структури класів:
визначаються поля зберігання складових стану об'єктів і алгоритми методів, реалізують аспекти поведінки об'єктів. При цьому використовуються розглянуті вище прийоми розробки класів (спадкування,
композиція, наповнення, поліморфізм тощо). Результатом є ієрархія або діаграма класів, що відображають взаємозв'язок класів, та опис класів.
Фізичне проектуваннявключає об'єднання описів класів у модулі, вибір схеми їх підключення (статична або динамічна компоновка), визначення способів взаємодії з обладнанням,
операційною системою та/або іншим програмним забезпеченням (наприклад,
базами даних, мережевими програмами), забезпечення синхронізації процесів для систем паралельної обробки тощо.
Сторінка 8 з 51 |
Основні засади ООП |
Е в о л ю ц і я с іс теми.Це процес поетапної реалізації та
підключення класів до проекту Процес починається зі створення основної програми чи проекту майбутнього програмного продукту. Потім реалізуються та підключаються класи, так щоб створити грубий, але, по можливості,
працюючий прототип майбутньої системи. Він тестується та налагоджується.
Наприклад, таким прототипом може служити система, що включає реалізацію основного інтерфейсу програмного продукту (передача повідомлень у відсутню поки що частина системи не виконується). В результаті ми отримуємо працездатний прототип продукту, який може бути показаний, наприклад, замовнику для уточнення вимог. Потім до системи підключається наступна група класів, наприклад пов'язана з реалізацією певного пункту меню.
Отриманий варіант також тестується і налагоджується, і так далі до реалізації всіх можливостей системи.
Використання поетапної реалізації значно полегшує тестування і налагодження програмного продукту.
Модифікація. Це процес додавання нових функціональних можливостей чи зміна існуючих властивостей системи. Як правило,
зміни зачіпають реалізацію класу, залишаючи без зміни його інтерфейс, що з використанні ОВП зазвичай обходиться без особливих неприємностей, оскільки процес змін зачіпає локальну область.
Зміна інтерфейсу - також не дуже складна задача, але її рішення може спричинити необхідність узгодження процесів взаємодії об'єктів, що вимагатиме змін в інших класах програми. Однак скорочення кількості параметрів в інтерфейсній частині в порівнянні з модульним програмуванням суттєво полегшує цей процес.
Простота модифікації дозволяє порівняно легко адаптувати програмні системи до умов експлуатації, що змінюється, що збільшує час життя систем, на розробку яких витрачаються величезні тимчасові і матеріальні ресурси.
Сторінка 9 з 51 |
Основні засади ООП |
Особливістю ООП і те, що об'єкт чи група об'єктів можуть розроблятися окремо, отже, їх проектування може бути різних етапах. Наприклад, інтерфейсні класи вже реалізовані, а структура класів предметної області лише уточнюється.
Зазвичай проектування починається, коли якийсь фрагмент предметної області досить повно описано у процесі аналізу.
Розгляд основних прийомів об'єктного підходу розпочнемо з об'єктної декомпозиції.
Об'єктна декомпозиція
Як уже згадувалося вище, при використанні технології ООП рішення подається у вигляді результату взаємодії окремих функціональних елементівдеякої системи, що імітує процеси,
які у предметної області поставленої задачи.
У такій системі кожен функціональний елемент, отримавши деякий вхідний вплив (зване повідомленням) у процесі вирішення задачі
виконує заздалегідь певні дії (наприклад, може змінити власний стан, виконати деякі обчислення, намалювати вікно чи графік та своєю чергою впливати інші елементи). Процесом розв'язання задачі керує послідовність повідомлень.Передаючи повідомлення від елемента до елемента, система виконує необхідні дії.
Функціональні елементи системи, параметри та поведінка якої визначаються умовою задачі, що мають самостійну поведінку
(тобто «вміють» виконувати деякі дії, що залежать від отриманих повідомлень та стану елемента), отримали назву об'єктів.
Процес представлення предметної області завдання у вигляді сукупності об'єктів, що обмінюються повідомленнями, називається об'єктною декомпозицією.
Сторінка 10 з 51 |
Основні засади ООП |
Для того щоб зрозуміти, про які об'єкти та повідомлення йдеться при виконанні об'єктної декомпозиції в кожному конкретному випадку, слід згадати, що спочатку об'єктний підхід був запропонований для розробки імітаційних моделей поведінки складних систем. Набір об'єктів таких систем зазвичай визначається при аналізі процесів, що моделюються.
приклад. Об'єктна декомпозиція (імітаційна модель
бензоколонки). Нехай нас цікавить залежність довжини черги до бензоколонки від кількості заправних місць, параметрів обслуговування кожного заправного місця та інтенсивності надходження заявок на заправку паливом (розглядаємо паливо одного типу).
Завдання такого виду зазвичай вирішуються з використанням імітаційних моделей. Модель програмно імітує реальний процес із заданими параметрами, паралельно фіксуючи його характеристики. Багаторазово повторюючи процес імітації з різними значеннями параметрів обслуговування чи надходження заявок, дослідник отримує конкретні значення характеристик, якими будуються графіки аналізованих залежностей.
Процес роботи бензоколонки з трьома заправними місцями можна подати у вигляді діаграми.
У міру вдосконалення обчислювальної техніки комп'ютери стали використовуватися для вирішення більш складних завдань. Виявилося, що вирішення складних завдань важлива як підвищена обчислювальна потужність комп'ютерів, а й ефективність написання складних програм. Об'єктно-орієнтоване програмування(ООП) виник саме як ефективний спосіб подолання труднощів, що виникають при створенні складних програм.
Найбільш значущою частиною ООП є особливий підхід до вирішення складних завдань програмування, що називається об'єктно-орієнтованим аналізом, А об'єктно-орієнтовані мови програмування – просто зручні інструменти для реалізації цього підходу.
Історія
Засновники ООП – видатні норвезькі вчені Крістен Нігаард (Cristen Nygaard) та Оле-Йохан Даль (Ole-Johan Dahl). Працюючи над моделюванням судноводіння, Нігаард зрозумів, що існуючі програмні засоби є малоефективними у створенні таких складних програм, і тоді Нігаард почав розробляти концепції нового програмування, що дозволяє подолати бар'єри складності, і яке згодом було названо. об'єктно-орієнтованим(Сам термін був придуманий Аланом Кеєм, автором мови Java). Разом з Оле-Йоханом Далем Нігаард розробив основні положення ОВП та практичні механізми їх реалізації, які потім були втілені у першому ООЯ Сімула (Simula). Заслуги цих учених були гідно оцінені світовим науковим співтовариством, і в 2001 Нігаард і Даль стали лауреатами премії імені Алана Тьюринга - своєрідного аналога Нобелівської премії в галузі computer science.
Мова Сімула користувалася популярністю в академічних колах, проте з ряду причин не завоювала популярності серед розробників комерційного програмного забезпечення. Проте основні ідеї та можливості ОВП були дуже привабливими для програмістів. Згодом були створені інші ООЯ: SmallTalk (1980), C++ (1985), Eiffel (1986), Object Pascal (1986) та Delphi (1995), Oberon-2 (1991), Java (1991), Visual Basic (1991) та багато інших. Деякі з цих мов стали промисловими стандартами у програмуванні.
Особливості ООП
Основна ідея ООП полягає в тому, що слід створювати програмні структури, поведінка та взаємодія яких імітує поведінку та взаємодію об'єктів реального світу (тобто у програмі хіба що створюються віртуальні аналоги реальних сутностей). Об'єктно-орієнтовані мови програмування повинні надавати засоби для зручного та швидкого втілення цього підходу.
У повсякденному житті люди використовують (нехай навіть неусвідомлено) різні прийоми "економії мислення", що дозволяють осмислювати та виражати складні явища у простих поняттях. Типовими прийомами "економії мислення" є:
· Абстрагування (відкидання несуттєвих деталей);
· Узагальнення (виділення загальних істотних ознак у різних явищ або предметів);
· Класифікація (усвідомлення зв'язку між явищами та ступенем їх схожості).
Ці прості прийоми допомагають людині впоратися зі складністю явищ, що розглядаються. І об'єктно-орієнтовані мови програмування також мають надавати такі засоби для “боротьби зі складністю” програм. Для реалізації об'єктно-орієнтованого підходу до мов програмування вводяться нові поняття:
· Об'єкти - спеціальні програмні структури, що поєднують дані та алгоритми їх обробки;
· Інкапсуляція - приховування подробиць функціонування об'єктів;
· Спадкування - "скорочений" спосіб створення нових класів;
· Поліморфізм - можливість застосування кількох реалізацій однієї функції.
Об'єкти та класи
Об'єкти - особливі програмні одиниці, що складаються з даних та алгоритмів для обробки саме цих даних. Дані, що входять до складу об'єкта, називаються полями(Атрибутами, властивостями, членами). Алгоритми, що входять до складу об'єкта, називаються методами(Сервісами, операціями, функціями-членами). На жаль, єдиної усталеної термінології в ОВП немає, і в різних мовах використовуються різні терміни для позначення тих самих понять.
Класи- Це об'єктні типи даних. Подібно до того, як цілі числа належать якомусь цілісному типу (наприклад, integer або byte), об'єкти також належать якомусь об'єктному типу - класу. Усі об'єкти одного класу мають однаковий набір полів та однаковий набір методів.
У деяких мовах (C++, Java) об'єкти називаються екземплярами класу(instances).
Корисність використання класів та об'єктів полягає в тому, що перевірка логічної (смислової) відповідності між даними та функціями для обробки даних стає тривіальним завданням і може бути в основному перекладена на компілятор (комп'ютер) – тепер він сам може визначити неправильне використання даних.
Інкапсуляція
Інкапсуляція (дослівно - "приховування") - контрольоване приховування інформації про внутрішню структуру класу. У класі можуть бути поля та методи, які використовуються об'єктами виключно для забезпечення своєї роботи (наприклад, буфер у динамічній пам'яті, файл з робочими даними, методи для роботи з цим файлом тощо). Змінювати такі поля чи викликати методи ззовні об'єкта небезпечно - це може порушити його стан. Для забезпечення безпеки об'єктів подібні поля та методи можна приховати- Заборонити звернення до них ззовні.
З позицій “боротьби зі складністю” інкапсуляція дозволяє перекласти частину контролю над правильністю роботи з об'єктами компілятор (комп'ютер).
Різні ООЯ пропонують різні можливості інкапсуляції полів і методів (від повної відсутності і до автоматичного приховування всіх полів). У промислових ООЯ, таких як C++, Java, Delphi, Eiffel і т.д., передбачені три рівні інкапсуляції полів і методів:
· public - на звернення до публічним полямта методів об'єктів немає жодних обмежень;
· protected - пряме звернення до захищеним полямі методів можливо лише з методів даного класу та методів дочірніх класів;
· private - пряме звернення до приватним полямі методам можливо винятково із методів даного класу.
успадкування
успадкування- створення нових класів шляхом дописування лише відмінностей від вже існуючих класів, опускаючи описи елементів, що збігаються. При наслідуванні новий клас називається класом-нащадком(похідним, дочірнім, підкласом), а вихідний клас називається класом-предком(Базовим, батьківським, суперкласом).
Спадкування скорочує розмір програми за рахунок виключення повторних описів. Усі поля та методи, оголошені в класі-предку, автоматично переносяться у клас-нащадок, і їх прийнято називати успадкованими(вносяться).
За потреби будь-який батьківський метод можна перевизначити- тобто. призначити виконання іншого алгоритму у разі виклику однойменного методу класу-нащадка.
Деякі ОЯ підтримують множинне спадкування, при якому похідний клас успадковує всі властивості та методи одночасно від кількох класів. На жаль, множинне спадкування таїть у собі чимало логічних конфліктних ситуацій, яке підтримка ускладнює мову програмування, і особливо - компілятор. З цієї причини у багатьох ООЯ множинне спадкування просто заборонене, але його можна зімітувати.
Сукупність всіх класів-предків та класів-нащадків називається ієрархією класів.
Спадкування класів - центральне поняття ООП, у ньому прямо чи опосередковано базуються й інші поняття і механізми. Абсолютній більшості механізмів ОВП, щоб виявити свої переваги, потрібна побудова ієрархій класів.
Поліморфізм
Поліморфізм(Дослівно - "різноманітність форм") - можливість використовувати одне ім'я для декількох методів (або функцій), що мають подібне призначення. Інша інтерпретація – один метод (функція) може мати кілька варіантів реалізації; такий метод (функція) називається поліморфним. Подібно до інших механізмів ОВП, поліморфізм є засобом спрощення розробки складних програм. Фактично поліморфізм відокремлює поняття, щотреба зробити, від того, якце треба робити.
Якщо провести аналогію із реальним життям, то поліморфізм відповідає узагальненим діям. Наприклад, дієслово "музикувати" означає "грати на музичному інструменті". Але на різних музичних інструментах грають по-різному. Термін один, а варіантів дії – багато. Значить, "музикувати" - поліморфна дія. В ООП дії "музикувати" відповідав би поліморфний метод, що має свої реалізації для кожного класу музичних інструментів
В ООП є два види поліморфних методів перевантаженіі віртуальні.
Перевантажені методипризначені для виконання із даними різних типів. Вони мають однакові імена, але різні списки аргументів та/або тип значення, що повертається.
Віртуальні методи призначені для виконання однакових за змістом операційв об'єктах споріднених, але збігаються класів. Віртуальні методи мають однакові імена та прототипи. Їхня головна особливість - вони завжди точно відповідають реальному класу об'єкта.
Типовий приклад перевантажених функцій – функція SQR у Паскалі. Вона обчислює квадрат числа, причому для цілих аргументів результат буде також цілим, а для речових – речовим.
Переваги віртуальних методів виявляються лише за використанні ієрархії класів. Типова схема використання віртуальних методів така:
· У класі-предку ієрархії оголошується поліморфний спосіб, який визначає деяке корисне вплив. При цьому він або використовує віртуальний метод, або сам є віртуальним.
· У класах-нащадках відповідний віртуальний метод перевизначається – для кожного класу-нащадка ця корисна дія виконується по-своєму.
· При виклику для об'єкта, що належить класу-нащадку, поліморфного методу насправді використовується віртуальний метод класу-нащадка (а не класу-предка).
Яскравий приклад подібного використання віртуальних методів – система графічного віконного інтерфейсу Delphi або Visual Basic: кожен видимий елемент графічного інтерфейсу – кнопка, повзунок, вікно тощо. - має бути нащадком класу TControl. У класі TControl вводяться загальні поліморфні методи малювання елементів графічного інтерфейсу, а його нащадок може намалювати себе на екрані власним способом.
Об'єктно-орієнтоване програмування явно не згадується у Стандарті 2004 року, хоча в Обов'язковому мінімумі змісту освіти з інформатики для учнів профільних закладів (Рівень Б) така тема була: Об'єктно-орієнтоване програмування: об'єкт, властивості об'єкта, операції над об'єктом. Там же згадувалась і об'єктно-орієнтована технологія програмування.
Проте ОВП непросто увійшло практику викладання інформатики (програмування) багатьох шкіл, а й є на сторінках шкільних підручників ( УгріновичН.Д. Інформатика та інформаційні технології. Підручник для 10-11-х класів, 2005. М: БІНОМ. Лабораторія знань). Крім того, у пропедевтичному курсі інформатики для початкової школи (робочі зошити авторського колективу під керівництвом О.Горячова. 1–4-і класи) також запроваджуються поняття об'єктаі його властивостей.
Технологія (парадигма) ООП вимагає не так освоєння сучасної техніки програмування, скільки вміння розробляти об'єктну модель розв'язуваної задачі. Для цього потрібно добре знати базові принципи ООП та програмування взагалі, проте знання якогось ООЯ не є обов'язковим – про це неодноразово писали основоположники та теоретики ООП. Так, Граді Буч у своїй книзі “Об'єктно-орієнтоване проектування та аналіз” висловлює таку максиму: “Писати програми в об'єктно-орієнтованому стилі можна у будь-якій (не об'єктно-орієнтованій) мові програмування”. Для побудови алгоритму технології ООП потрібно сформувати список об'єктів, із якими працює алгоритм, продумати властивості кожного об'єкта і реалізувати алгоритм як взаємодія описаних об'єктів.
Як уже було сказано у статті, такий підхід спрощує вирішення складних завдань, але в рамках школи (з урахуванням обмеженої кількості годин) важко придумати змістовні навчальні завдання, які б не надумано вимагали використання технології ОВП у повній мірі.
Фактично ж ОВП у школі розглядається лише як невід'ємна частина візуального та компонентного програмування в сучасних професійних системах програмування, а як об'єкти використовуються готові об'єктні бібліотеки різного рівня – це і бібліотеки для побудови графічного інтерфейсу Windows-додатків та багатоцільові універсальні бібліотеки типів даних (наприклад , STL С++). Для примітивного використання цих бібліотек достатньо знати та вміти застосовувати декілька найпростіших правил синтаксису мови програмування. Проте такі “знання” аж ніяк не наближають учнів ні до професійного оволодіння мовою програмування, ні навіть розуміння ОВП. Але, певне, нічого страшного в цьому немає. Шкільна інформатика і в профільній школі не має на меті підготовку професійних програмістів. Викладання ООП - це спеціальна тема, навіть на відповідних спеціальностях вишів її часто не вивчають у достатньому обсязі.
Не заперечуючи повністю пропозицію деяких викладачів інформатики поставити об'єктно-орієнтований підхід на чільне місце вивчення програмування, в тому числі в школі, зазначимо, що ОВП неможливе без таких базових понять, як програма, виконавець, змінна, умова, цикл і т.д. Концепція ООП також включає класичне процедурне програмування (див. “ Підпрограми”), як механіка Ейнштейна - механіку Ньютона: досить уявити процедурну програму як єдиний об'єкт з опущеним для простоти ім'ям. Тому насамперед завдання курсу програмування у школі – навчити базовим речам. І лише за можливості роботи з сучасними візуальними середовищами програмування (Delphi, Visual Basic, Visual C++
і т.п.) ознайомити з поняттям об'єктів та їх використанням в основному за допомогою методики навчання програмування "за зразком".
Загальна інформація
ООП - це стиль програмування, що у 80 роках 20 століття. На відміну від процедурних мов, де дані та інструкції щодо їх обробки існують окремо, в об'єктно-орієнтованому програмуванні ця інформація поєднується в єдину сутність.
Основні засади ООП
успадкування
Другий принцип ОВП – успадкування – це можливість одного класу використовувати методи іншого без повторення їхньої фактичної реалізації. Спадкування дозволяє позбутися надмірності вихідного коду.
Поліморфізм
Ще один принцип ОВП – поліморфізм. Його використання означає, що для маніпуляції з об'єктами різного ступеня складності можна створити один інтерфейс, який по-різному реагуватиме на події та одночасно правильно реалізовувати поставлені завдання.
Мови ООП
Принципи ООП використовуються у таких найбільш популярних мовах програмування, як C++ та Java, на яких розроблено значну частину програм та додатків. Є й менш використовувані мови ОВП - це Delphi, Object Pascal, Ruby та ще.
Критика ООП
Незважаючи на в основному позитивні висловлювання у бік даної методології, нерідко принципи ОВП зазнають і критики. Як і ООП має свої недоліки.
По-перше, складність переходу. Щоб зрозуміти принципи ОВП, знадобиться досить багато часу, тим більше людям, які впритул працюють тільки з процедурними мовами програмування.
По-третє, зайва універсальність методів може призвести до того, що вихідний код і програми, що розробляються, будуть перевантажені незатребуваними в даному конкретному випадку функціями і можливостями. З іншого боку, відзначають неефективність з погляду розподілу пам'яті. Однак незалежно від думки оточуючих кількість програмістів ООП постійно зростає, а самі мови стрімко розвиваються.
Гальмує
