5.3. Ключові абстракції й механізми

5.3.1. Ключові абстракції

Пошук і вибір ключових абстракцій. Ключова абстракція – це клас або об’єкт, що входить у словник ПО. Найголовніша цінність клю­чових абстракцій полягає в тому, що вони визначають межі проб­леми: виділяють те, що входить у систему й тому важливе для нас, і усувають зайве. Завдання виділення таких абстракцій специфічні для предметної області. Правильний вибір об’єктів залежить від при­значення ІС і ступеня детальності опрацювання інформації.

Як ми вже відзначали, визначення ключових абстракцій пе­редба­чає два процеси: відкриття й винахід. Ми відкриваємо абстракції, слухаючи фахівців із ПО: якщо експерт про неї говорить, то ця абст­ракція дійсно важлива. Винаходячи, ми створюємо нові класи і об’єк­ти, які не обов’язково є частиною предметної області, але корисні під час проектування або реалізації системи. Наприклад, користувач бан­ко­­мату говорить “рахунок, зняти, покласти”; ці терміни – частина слов­ника предметної області. Розробник системи використовує їх, але додає свої, такі як база даних, диспетчер екрану, список, тощо. Ці ключові абстракції створені вже не предметною областю, а проек­туванням.

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

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

Визначивши нові абстракції, потрібно знайти їх місце в кон­тексті наявних класів і об’єктів. Не варто намагатися робити це строго зверху вниз або знизу вгору. Немає особливої необхідності будувати ієрархію класів, починаючи з найвищого класу, і потім доповнювати її підкла­сами. Частіше ви створюєте кілька незалежних ієрархій, усві­дом­люєте їх загальні ознаки й виділяєте один або кілька суперкласів. Треба кілька проходжень вверх й вниз ієрархією, щоб створити прог­рамний проект. Це лише спостереження, яке ґрунтується на досвіді й під­тверджує той факт, що об’єктно-орієнтоване проектування – процес послідовних наближень. Найчастіші реорганізації в ієрархії класів – це відомість частин, які збігаються, двох класів в один і поділ класу на два нові. 

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

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

Існують такі правила:

• об’єкти варто називати іменниками: theSensor або shape;

• класи – узагальненими іменниками: Sensors, Shapes;

• операції-модифікатори називають активними дієсловами: Draw, moveLeft;

• операції-селектори повинні містити запит або форму діє­слова “to be”: extentOf, isOpen;

• підкреслення й використання великих літер – на ваш розсуд, намагайтеся лише не суперечити самі собі.