Класи. Ролі класу

Лекція 1. Повторення основних принципів ООП

Розробка об’єктно-орієнтованої парадигми була викликана труднощами, що мали місце в практиці розробки стандартного структурного програмування.

Метод функціональної декомпозиції – це основний підхід розробки структурного програмного забезпечення (ПЗ). Цей метод передбачає, що розроблювач розбиває (піддає декомпозиції) проблему на кілька функціональних етапів, що забезпечують її рішення. Розроблювач діє так тому, що простіше мати справу з невеликими частинами, чим із усією проблемою в цілому. Основна проблема методу функціональної декомпозиції полягає в тому, що він не дозволяє будь-яким чином підготувати текст програми до наступних змін, що з'являються в міру її поступової еволюції. Найчастіше подібні зміни пов'язані з необхідністю врахувати новий варіант поводження програми у вже існуючій системі. Якщо всю логіку реалізації обраної поетапної схеми помістити в одну велику функцію або єдиний модуль, то кожна зміна кожного з етапів буде потребувати внесення змін у цю функцію або модуль. З іншого боку, внесення змін зазвичай підвищує небезпеку появи помилок або інших небажаних наслідків. Інакше це можна сформулювати в такий спосіб.

1. Безліч помилок з'являються при внесенні в текст програми змін. Усякий раз, коли в текст програми необхідно внести зміни, виникає побоювання, що зміна тексту програми в одному місці може привести до збою в іншому. Чому ж це відбувається? Чи повинен програміст аналізувати всі наявні функції і звертати увагу на спосіб їхнього використання? Чи необхідно йому враховувати, як функції можуть взаємодіяти одна з одною? Чи зобов'язаний він перевіряти всю безліч різних подробиць, зв'язаних з кожною функцією, реалізовану цією функцією логіку, компоненти з якими ця функція взаємодіє, дані, що вона використовує.

2. Проблема формулювання вимог до створюваного програмного забезпечення. Не має значення, скільки зусиль було прикладено, наскільки ретельно був проведений аналіз - користувач просто не може сформулювати всі необхідні вимоги відразу. Занадто багато невідомого несе в собі майбутнє. Часи міняються. І так було завжди...Ніщо не може запобігти настанню змін. Однак це не значить, що до їхнього приходу не можна підготуватися.

Будь-яке опитування серед розроблювачів програмного забезпечення про якість наданих замовником вимог до створюваного програмного продукту навряд чи дасть велику розмаїтість відповідей. Швидше за все вони будуть наступними.

- Вимоги є неповними.

- Вимоги по більшій частині помилкові.

- Вимоги (і користувачі) суперечливі

- Вимоги не описують поставлену задачу докладно.

Практично немає шансів одержати відповідь, подібну наступний: "надані вимоги не тільки вичерпно повні, ясні і зрозумілі, але також включають опис усіх функціональних можливостей, що будуть потрібні замовникові протягом п'яти наступного років!"

Вимоги до програмного забезпечення завжди змінюються, більшість розроблювачів знають цю обставину і вважають її досить неприємною. Але лише деякі з них дійсно враховують можливість зміни існуючих вимог при написанні програм. Зміна вимог до програмного забезпечення відбувається внаслідок ряду простих причин:

- Погляди користувачів на їхні потреби змінюються як у результаті обговорень з розроблювачами, так і при ознайомленні з новими можливостями в області програмного забезпечення.

- Представлення розроблювачів про предметну область міняється в міру створення ними програмного забезпечення, призначеного для її автоматизації, оскільки їм стають відомі додаткові особливості цієї області.

- З'являються все нові обчислювальні середовища, призначені для розробки програмного забезпечення.

Все це зовсім не значить, що можна опустити руки і відмовитися від збору повноцінних вимог користувачів до створюваної системи. Навпроти, це значить, що необхідно навчитися пристосовувати створюваний програмний код до неминучого внесення змін. Це також виходить, що необхідно припинити обвинувачувати себе (або замовників) у тому, що є зовсім закономірним.

Щоб цілком зрозуміти зміст усього вищесказаного, уведемо деяку спеціальну термінологію. Мартін Фулер (Martіn Fowler) у книзі UML Dіstіlled описує три різних підходи до процесу розробки програмного забезпечення. Вони представлені в табл.

Таблиця 1.1. Різні підходи до процесу розробки програмного забезпечення

На концептуальному рівні	При цьому підході виявляються основні концепції досліджуваної предметної області, концептуальна модель може незначно або навіть узагалі не стосуватися питань її реалізації в створюваному ПЗ
На рівні спецификацій	У цьому випадку проектується саме програмне забезпечення, але лише з погляду його інтерфейсної частини, а не повної реалізації
На рівні реалізації	На цьому етапі створюється текст програм. У більшості випадків саме цей підхід сприймається як основний, але найчастіше виявляється виправданим попереднє звертання до підходів попередніх типів.

Об’єктно - орієнтована розробка програмної системи заснована на стилі, називаному проектуванням від даних. Проектування системи зводиться до пошуку абстракцій даних, що підходять для конкретної задачі. Кожна з таких абстракцій реалізується у вигляді класу, що і стає модулем - архітектурною одиницею побудови системи. В основі класу лежить абстрактний тип даних.

Об’єктно - орієнтована розробка програмної системи зосереджена на об'єктах, тому текст створюваних програм також будується на використанні об'єктів, а не функцій. Що ж таке об'єкт? Традиційно об'єкт розглядається як сукупність даних і методів (об’єктно-орієнтований термін для функцій). У класу дві різні ролі: модуля і типу даних. Клас - це модуль, архітектурна одиниця побудови програмної системи. Клас - це тип даних, що задає реалізацію деякої абстракції даних, характерної для проблемної області, в інтересах якої створюється програмна система.

Перевага використання об'єктів полягає в тому, що на них покладається відповідальність за їхню власну поведінку. Спочатку об'єкти відносять до визначеного типу. Дані об'єкта дозволяють йому визначати свій стан, а програмний код об'єкта забезпечує його коректне функціонування (тобто виконання тих дій, для яких він, власне, призначений).

На концептуальному рівні об'єкти виступають як сукупність зобов'язань.

На рівні визначення специфікацій об'єкти розглядаються як набір методів, що можуть викликатися іншими об'єктами або цим же об'єктом.

На рівні реалізації об'єкти розглядаються як сукупність програмного коду і даних.

На жаль, вивчення й обговорення методів об’єктно-орієнтованого проектування найчастіше ведеться тільки з погляду рівня реалізації - у термінах програмного коду і даних, а не з позицій концептуального рівня або рівня визначення специфікацій.

Оскільки об'єкти мають обов'язки і несуть повну відповідальність за свої дії, обов'язково повинний існувати спосіб керувати ними - тобто вказувати, що необхідно зробити. Не забувайте, що об'єкт містить дані, що описують його поточний стан, і методи, що реалізують його функціональність. Деякі методи об'єкта ідентифікуються як методи, доступні для інших об'єктів. Набір цих методів визначає відкритий інтерфейс об'єкта (publіc іnterface).

Клас є визначенням лінії поведінки об'єкта. Він містить повний опис наступних елементів:

- усіх елементів даних, що входять до складу об'єкта;

- усіх методів, що об'єкт здатний виконувати;

- необхідних способів доступу до наявних елементів даних і методам.

У класу дві різні ролі: модуля і типи даних. Клас - це модуль, архітектурна одиниця побудови програмної системи. Клас - це тип даних, що задає реалізацію деякої абстракції даних, характерною для проблемної області, в інтересах якої створюється програмна система.

Об'єктно-орієнтована розробка програмної системи заснована на стилі, званому проектуванням від даних. Проектування системи зводиться до пошуку абстракцій даних, придатних для конкретного завдання. Кожна з таких абстракцій реалізується у вигляді класу, який і стає модулем - архітектурною одиницею побудови нашої системи. В основі класу лежить абстрактний тип даних.

Оскільки елементам даних, що утримується в об'єкті, можна привласнювати різні значення, об'єкти того самого класу будуть містити різні набори конкретних значень даних, але, у той же час, володіти однієї і тією же функціональністю (реалізованої методами). Щоб одержати доступ до об'єкта, попередньо варто повідомити програму, що необхідний новий об'єкт визначеного типу (тобто того класу, до якого відноситься цей об'єкт). Створюваний новий об'єкт одержує назву екземпляра класу. Створення екземпляра класу називається його реалізацією. Абстрактні класи визначають поведінку інших, родинних їм класів. Ці "інші" класи представляють специфічний тип родинного поводження. Такий клас зазвичай називають конкретним класом, оскільки він представляє особливу визначену, фіксовану реалізацію загальної концепції.

Зі спадкуванням тісно зв'язаний ще один важливий механізм проектування сімейства класів - механізм абстрактних класів.

Визначення. Клас називається абстрактним, якщо він має хоча б один абстрактний метод.

Визначення. Метод називається абстрактним, якщо при визначенні методу задана його сигнатура, але не задана реалізація методу.

Оголошення абстрактних методів і абстрактних класів має супроводжуватися модифікатором abstract. Оскільки абстрактні класи не є повністю визначеними класами, не можна створювати об'єкти абстрактних класів. Абстрактні класи можуть мати нащадків, які частково або повністю реалізують абстрактні методи батьківського класу. Абстрактний метод є віртуальним методом, перевизначеним нащадком, тому до них застосовується стратегія динамічного зв'язування.

На концептуальному рівні абстрактні класи - це просто шаблони для створення інших класів. Отже, за допомогою абстрактного класу ми просто привласнюємо власну назву деякій множині родинних класів. Це дозволить нам надалі розглядати дану множину як єдину концепцію.

Оскільки об'єкти несуть повну відповідальність за власну поведінку, існує безліч елементів, доступ до яких з боку інших об'єктів вони дозволяти не зацікавлені. Раніше вже згадувалося поняття відкритий інтерфейс (publіc іnterface) - воно охоплює всі методи об'єкта, доступні для будь-яких інших об'єктів. В об’єктно-орієнтованих системах існує кілька рівнів доступу до елементів об'єктів.

Можливими модифікаторами в оголошенні класу можуть бути модифікатори abstract, virtual і чотири модифікатора доступу, два з яких - private і protected - можуть бути задані тільки для вкладених класів. За замовчуванням клас має атрибут доступу internal. Щоб зробити клас доступним не тільки класам одного проекту, його явно потрібно оголосити з атрибутом public. Так що в простих випадках оголошення класу може виглядати так С#:

public class Rational { тіло_класу }

У тілі класу можуть бути оголошені: константи; поля; конструктори і деструктори; методи; події; класи (структури, делегати, інтерфейси, перерахування).

Дата добавления: 2015-08-18