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

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

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

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

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

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

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

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

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

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

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

• класи варто називати узагальненими іменниками: Sensos, Shapes,

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

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

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