Мови програмування: структурний та об’єктно-орієнтований підходи 1. 2. 3. 4. 1 Загальна характеристика сучасного стану розвитку мов програмування (2 -8) Структурний підхід (9 -14) Об’єктно-орієнтований підхід (15 -23) Характеристика ООП (24 -33)
Загальна характеристика сучасного стану розвитку мов програмування Програмні комплекси, що створюються сьогодні стають все складнішими. З чим пов’язані ці складнощі: 1. Складність предметної області – програмісти створюють програми, які моделюють досить складні процеси, які самі по собі залежать від великої кількості факторів і описуються досить складними математичними моделями. Використання комп’ютера не робить ці проблеми простішими. 2
Загальна характеристика сучасного стану розвитку мов програмування 2. Складність управління проектами – підмічено, що з лінійним зростанням програми її складність зростає експоненціально. При цьому залучення додаткових сил, як правило, бажаного ефекту не надає: якщо п’ять програмістів пише програму два місяці то 10 програмістів навряд чи напишуть її за один місяць – результат може бути зворотнім – без якісного менеджменту програму взагалі не напишуть. 3
Загальна характеристика сучасного стану розвитку мов програмування 3. Вимоги до гнучкості системи – в ідеалі процес розробки системи виглядає так: замовник проекту чітко окреслює вимоги до проекту, у яких відсутні протиріччя та нез’ясованості. Програмісти систему реалізують і після здачі проекту усі летять відпочивати на Канари. На практиці все відбувається інакше. Під час розробки з’ясовується, що замовник уявляє собі готовий проект не так як програмісти. Створення системи це завжди компроміс: замовник і розробники повинні постійно спілкуватися між собою і слідкувати за тим, щоб прийняті рішення задовольняли обидві сторони. Здачею проекту зазвичай справа не закінчується: через деякий час існуюче рішення вже не задовольняє замовника і він звертається до розробників з пропозицією доопрацювати або частково переробити проект. 4
Загальна характеристика сучасного стану розвитку мов програмування 4. Складність поведінки системи – відмінність програмних систем від систем реального світу полягає у тому, що вони є дискретними. Об’єкти реального світу живуть за безперервними законами – невеликі впливи тягнуть за собою невеликі наслідки. У світі комп’ютерних систем діють інші закони. Навіть невелика помилка у самому незначному модулі може потягти за собою непередбачені наслідки (аж до краху системи). Боротися з цим неможливо – можна тільки проводити повне і детальне тестування системи (тестування займає 50% часу розробки проекту) та проектувати систему так, щоб локалізація і виявлення помилок проходили з якнайменшими затратами часу. 5
Загальна характеристика сучасного стану розвитку мов програмування 6 Як можна перебороти зазначені складності сучасних комп’ютерних систем. Відповідь вже давно відома: «золоте правило» в загальному вигляді звучить так «розділяй і володарюй» . Це правило використовується при проектуванні у будь-якій галузі. Ідея полягає в тому, щоб розділити систему на більш мілкі підсистеми (виконати декомпозицію системи). Після цього окремі підсистеми можна розробляти окремо.
Загальна характеристика сучасного стану розвитку мов програмування В 7 програмуванні також ні у кого нема заперечень від декомпозиції проекту. Але проблема полягає не у тому щоб виконати декомпозицію, а у тому як її виконати. Нажаль сьогодні невідомий найкращий спосіб розділення системи на підсистеми (мабуть цей спосіб не буде відомий ніколи). Можна говорити тільки про різні підходи до вирішення цієї проблеми.
Загальна характеристика сучасного стану розвитку мов програмування Підходи по декомпозиції можуть бути такими: l структурне програмування; l l метод потоків даних; автоматне програмування; логічне програмування; l об’єктно-орієнтоване програмування. l Будь який підхід може бути найкращим для вирішення конкретної проблеми. Але найбільш відомі підходи що отримали найбільше розповсюдження це структурне програмування та об’єктно-орієнтоване програмування. 8
Структурне програмування 9 Структурне програмування отримало свій розвиток у 60 -70 роки ХХ сторіччя завдяки роботам Е. Дейкстри. У його основі лежить ідея алгоритмічної декомпозиції: пропонується розділяти складну систему на окремі частини у яких застосовуються різні алгоритми і реалізовувати кожний алгоритм окремо. Саме структурне програмування заохочує процедурне мислення: якщо у вашій програмі деяка дія повторюється декілька раз, виділяйте цю дію в окрему процедуру. Структурне програмування дотепер залишається дуже гарним (а нерідко й найкращим) підходом, якщо мова йде про невеликі проекти.
В основу методу структурного програмування покладено три ідеї l l l 10 розділяти велику програму на множину маленьких підпрограм; об’являти у програмах змінні та типи значень які вони приймають; використовувати у маленьких програмах тільки послідовні команди, команди розгалуження та команди циклу.
Розділяй велику програму на множину маленьких підпрограм 11 Написати одну велику програму, яка вирішує одночасно багато задач значно складніше ніж написати декілька невеликих програм. Цей підхід не тільки спрощує процес написання великих програм, але й значно полегшує процес внесення в них змін і пошуку помилок, оскільки тепер не потрібно модифікувати програму в цілому - досить визначити відповідну підпрограму й працювати тільки з нею.
Оголошуй у програмах змінні 12 Споконвічно можна було створювати змінні в будь-якому місці програми й привласнювати їм значення будь-яких типів, завдяки чому розібратися, що робить програма, було практично неможливо. Тому й було вирішено, що всі змінні повинні оголошуватися на початку розділу де вони використовуються. У цьому випадку інші програмісти могли зрозуміти, для чого в програмі використовуються ті чи інші змінні.
Оголошуй у програмах типи значень змінних та констант 13 Як засіб боротьби з помилками було прийнято ще одне рішення: при оголошенні змінних повинен вказуватися тип даних, які ці змінні можуть містити. Якщо ви спробуєте привласнити змінній значення іншого типу (не того, який був для неї оголошений), це відразу ж буде сприйнято як помилка й виконання програми припиниться. Цей спосіб запобігає створенню й поширенню програм, що неправильно зберігають дані. А як відомо, некоректні дані приводять до збоїв у роботі комп’ютерів, на яких вони обробляються.
Використовуй тільки: послідовні команди, розгалуження та циклу. 14 Найбільші проблеми в ранніх програмах виникали при використанні спеціальної команди GOTO. Через постійні переходи з одного кінця програми в інший практично неможливо було зрозуміти, що саме ця програма робить. Ідея структурного програмування поклала цьому кінець і обмежила переміщення по програмі виконанням тільки трьох видів команд.
Об’єктно-орієнтований підхід 15 Головне завдання будь-якого принципу програмування - визначити спосіб декомпозиції системи на прості підсистеми. Об’єктно-орієнтований підхід має на меті подання програмної системи у вигляді сукупності незалежних об'єктів, що взаємодіють між собою. Об'єктна декомпозиція радикально відрізняється від алгоритмічної: l людина, що застосовує структурне програмування, представляє систему у вигляді сукупності процедур; l людина ж, що дотримується об’єктноорієнтованого мислення, представляє систему у вигляді набору об'єктів.
Об’єктно-орієнтований підхід на прикладі комп’ютера Прекрасним прикладом втілення ідей об’єктноорієнтованого мислення (і його плюсів) є сучасний персональний комп'ютер. Його можна розглядати як систему, що складається із самостійних об'єктів: материнської плати, дисководів, відеокарти, звукової карти, монітора, миші, клавіатури й т. д. Хоча комп'ютер - пристрій дуже складний, такий поділ на складові вирішує відразу кілька проблем. 16
Об’єктно-орієнтований підхід на прикладі комп’ютера Кожна із складових комп'ютера може бути розроблена незалежно друг від друга. Єдине, що необхідно знати розробникам, приміром, звукової карти - це протокол, який використовується для спілкування карти із пристроєм (не обов'язково комп'ютером), до якого вона буде підключена. Розробнику карти нічого не потрібно знати про те у якому саме комп'ютері буде встановлено карту, які параметри інших складових. ª 17
Об’єктно-орієнтований підхід на прикладі комп’ютера Пристрої приховуються за своїм інтерфейсом. Якщо інтерфейс пристрою (наприклад тип порту та спосіб передачі даних) залишається незмінним, то архітектуру пристрою можна повністю переробити без шкоди для системи в цілому. Зламана відеокарта легко замінюється новою, застаріле обладнання - більш сучасним. ª 18
Об’єктно-орієнтований підхід на прикладі комп’ютера ª 19 Використання стандартизованих інтерфейсів дозволяє порівняно легко підключати до комп'ютера додаткове устаткування - від принтера й модему до цифрового відеомагнітофона й руля з педалями.
Об’єктно-орієнтований підхід на прикладі комп’ютера - недоліки За простоту зміни самих об'єктів за умови незмінних інтерфейсів доводиться розплачуватися більшими складностями при зміні самих інтерфейсів. Наприклад, інтерфейс (тобто форма рознімання й кількість ніжок) процесора Pentium II відрізняється від інтерфейсу Pentium. Щоб модернізувати комп'ютер із процесором Pentium, потрібна заміна материнської плати. l 20
Об’єктно-орієнтований підхід на прикладі комп’ютера - недоліки Система, що складається з об'єктів, працює менш ефективно, чим система, побудована як один блок. Спілкування об'єктів між собою часто тягне непродуктивні накладні витрати. Відомо, що системи, реалізовані як єдиний модуль (наприклад ігрові приставки Super Nintendo, Sony Play. Station), показують більш високу продуктивність, чим персональний комп'ютер з подібними характеристиками (частотою процесора, обсягом оперативної пам'яті й т. д. ). l 21
Об’єктно-орієнтований підхід на прикладі комп’ютера - недоліки Система, що складається з об'єктів, коштує набагато дорожче, ніж аналогічна система, побудована як один блок. На практиці цілком може виявитися, що значна частина схеми одного модуля комп'ютера вже реалізована в іншому. Але скористатися цим неможливо (тому що окремі модулі повинні бути самостійними й незалежними). Альтернативні рішення (Super Nintendo, Sony Play. Station) дуже складно модернізувати, зате ціна виявляється набагато менше. l 22
Об’єктно-орієнтований підхід вердикт 23 Незважаючи на всі недоліки, переваги об'єктної моделі є все-таки більш значними. Об'єктна модель далеко не ідеальна, але інші, як правило, виявляються ще гірші. (За аналогією із висловлюванням Уїнстона Черчилля: Демократія це дуже погана система влади, але кращої людство поки що не придумало).
Характеристика ООП - абстрагування Абстрагування — це спрощений опис або виклад системи, 24 при якому одні властивості або деталі (істотні для розгляду в цей момент) виділяються, а інші ігноруються. Будь-які моделі об'єктів реального світу, і які зустрічаються в комп'ютерних програмах, теж є абстракціями. Кошик, що перебуває на робочому столі Windows, імітує дійсний кошик для сміття. У ньому важливі тільки три аспекти: зовнішній вигляд, можливість викинути документ у кошик і можливість дістати його з кошика якщо документ видалили помилково. Побачити систему що розроблюється як набір ключових абстракцій (причому вибрати як можна більш вдале для реалізації подання) — головне завдання об’єктноорієнтованого проектування. У програмуванні абстракції реалізуються за допомогою об'єктів, причому кожний об'єкт є представником деякого класу (із цієї причини об'єкти іноді називають екземплярами класу).
Характеристика ООП - інкапсуляція Інкапсуляція (encapsulation) - це механізм, що поєднує дані й код, що маніпулює цими даними, а також захищає те, і інше від зовнішнього втручання або неправильного використання. В об’єктно-орієнтованому програмуванні код і дані можуть бути об'єднані разом; у цьому випадку говорять, що створюється так званий "чорний ящик". Коли коди й дані поєднуються таким способом, створюється об'єкт (object). Інакше кажучи, об'єкт це те, що підтримує інкапсуляцію. 25
Характеристика ООП - інкапсуляція Гарна абстракція немислима без відділення інтерфейсу від реалізації. Лише в цьому випадку її розроблювач зможе скористатися перевагами об'єктної моделі. З одного боку, ніщо не перешкодить йому в майбутньому змінити або поліпшити поточну реалізацію моделі (зрозуміло, за умови незмінності інтерфейсу); з іншого боку, він відгородить своїх колег від необхідності вивчати реалізацію абстракції, щоб нею скористатися, не говорячи вже про те, що такий підхід захищає абстракцію від можливих спроб її доробки (далеко не завжди вмілої) ким-небудь, крім автора. 26
Характеристика ООП - модульність Подання системи у вигляді набору абстракцій придатне лише для невеликих розробок. У серйозних проектах кількість окремих абстракцій може досягати декількох сотень (якщо не більше). У цьому випадку необхідна якась проміжна ланка між окремо взятими абстракціями й системою в цілому. Саме таку роль відіграють модулі. 27
Характеристика ООП - модульність 28 З погляду програміста модульність - це поділ програми на фрагменти, які компілюються окремо, але можуть встановлювати зв'язки один з одним. Модуль (у програмуванні) складається звичайно із двох частин: интерфейсної (у якій описуються інтерфейси абстракцій, що становлять модуль) і частині, що містить реалізації абстракцій. Якщо головне завдання ООП полягає у виділенні абстракцій системи, то головне завдання при проектуванні модульної структури проекту - умілий розподіл абстракцій по модулях
Характеристика ООП - поліморфізм Поліморфізм (polymorphism) - це властивість, що дозволяє те саме ім'я використати для рішення двох або більше схожих, але технічно різних завдань. Метою поліморфізму, стосовно до ООП, є використання одного імені для завдання загальних для класу дій. Виконання кожної конкретної дії буде визначатися типом даних. 29
Характеристика ООП - поліморфізм 30 Концепцією поліморфізму є ідея "один інтерфейс, безліч методів". Це означає, що можна створити загальний інтерфейс для групи близьких за змістом дій. Перевагою поліморфізму є те, що він допомагає підвищити складність програм, дозволяючи використання того ж інтерфейсу для завдання єдиного класу дій. Вибір конкретної дії, залежно від ситуації, покладається на компілятор. Вам, як програмістові, не потрібно робити цей вибір самому. Потрібно тільки пам'ятати й використати загальний інтерфейс.
Характеристика ООП - спадкування Спадкування (inheritance) - це процес, за допомогою якого один об'єкт може здобувати властивості іншого. Точніше, об'єкт може успадковувати основні властивості іншого об'єкта й додавати до них риси, характерні тільки для нього. Спадкування є важливим, оскільки воно дозволяє підтримувати концепцію ієрархії класів (hierarchical classification). Застосування ієрархії класів робить керованими більші потоки інформації. 31
Характеристика ООП – спадкування приклад Ми створили примітивний клас, який назвали Автомобіль, з складовими: двигун, кермо і 4 колеса. Більше ніяких подробиць. Після деяких роздумів ми вирішили розвинути проект і створити ще три класи, більш детальних і розвинутих: автобус, вантажівка і амфібія. У кожного з цих класів, як і у автомобіля є двигун, кермо і 4 колеса, але є у кожного відмінності. Автобус має пасажирський салон, вантажівка має кузов, а амфібія – гребний гвинт. 32
Характеристика ООП – спадкування приклад Як створювати програмний код для кожного з цих класів. Найпростіша можливість це написати код для автомобіля потім скопіювати його до кожного з нових класів і дописати особливості які притаманні нашим новим класам. Більш зручний і «правильний» спосіб – спадкування. Ми просто об’являємо, що новий клас Вантажівка є спадкоємцем класу Автомобіль. При цьому Вантажівка неявно тепер володіє усім кодом свого батька – автомобіля. Тим самим нічого не написавши у код програми ми можемо користуватися нашою вантажівкою як автомобілем. 33 Щоб з автомобіля зробити вантажівку ми пишемо йому нові процедури і функції. Так само робимо і для автобуса й амфібії.
Характеристика ООП – спадкування Без використання ієрархії класів, для кожного об'єкта довелося б задати всі характеристики, які б вичерпно його визначали. Однак при використанні спадкування можна описати об'єкт шляхом визначення того загального класу (або класів), до якого він належить, з тими спеціальними рисами, які роблять об'єкт унікальним. 34
Скачать презентацию Мови програмування структурний та об єктно-орієнтований підходи 1 2
АППОИ_2_Мови програмування.ppt