Євген Каратаєв
Іноді так буває - зберуться люди і починають обговорювати серйозні проблеми. І втомлюються вже, а все одно продовжують. Зупинитися вже не можуть, тому як несерйозно вийде. І думки вже закінчуються. І тут хтось говорить жарт і всі сміються і ситуація розрядиться. Як така жартівлива розрядка і з'явилася ця робота. Незважаючи на жартівливість і нібито несерйозність, частка цікавого і корисного в ній є.
Як проектувати класи?
Класи є визначення понять і відносин між ними, виражені на будь - якому об'єктному мовою. Коли говорять, що об'єкти - це ново, модно і все таке, мені це важко зрозуміти, оскільки нічого крім об'єктів ніколи не писав. Скоріше вже програмування без об'єктів - ось це дійсно новина.
Щоб спроектувати класи, слід виконати по кроках наступний рецепт. Опис рецепта буде ілюструватися на настільки банальному прикладі, щоб його не можна було використовувати в реальній роботі. Як це і прийнято в справжніх комп'ютерних публікаціях.
Крок 1
Слід взяти і потрясти замовника (або самого себе, якщо сама все придумала) на тему отримати побільше опису теми російською мовою. Треба саме російською. Нехай пише. Або дасть статтю в журналі. Теж буває. Побачить шеф статтю і засвітиться на тему "а мені теж треба". Після цього слід переглянути текст і викинути з нього все, що до справи не відноситься. Після чого дописати до нього те, що не згадано, а по ідеї повинно бути. Після таких виправлень російськомовного тексту його слід перечитати і трошки погорду, оскільки перший етап виконано.
Приклад, що може вийти в результаті:
У лісі народилася ялинка, у лісі вона росла.
Взимку і влітку струнка, зелена була.
Ось так от, грубо і зримо, будемо виділяти те, що відноситься до разбираемому прикладу.
Крок 2
Другий крок складається з того, що виписуємо окремо слова, є іменниками, прикметниками, дієсловами, спілками та іншими частинами мови. Хто давно нічого не писав на інших мовах крім C + +, Object Pascal, Java або інших, той може проконсультуватися у своїх молодших товаришів, яке слово чим є. У нашому прикладі вийде:
іменники: ліс, ялинка, зима, літо
дієслова: народитися, рости, бути
прикметники: струнка, зелена
спілки: і
займенник "вона" ганебно віднесемо до іменників, а прийменник "в" - до спілок.
Крок № 2 закінчений.
Крок 3
Третій крок полягає в такому ж, як і другий, монотонному переписуванні вихідного тексту. Тепер переписуємо по-іншому.
Кожному імені загального ставимо відповідно ім'я класу і називаємо його спадкоємцем якоїсь ієрархії.
Кожному імені власним ставимо у відповідність об'єкт як екземпляр якогось загального класу. У нашому прикладі власної назви немає, тому я, насупивши брови, можу сміливо заявити, що розбір прикладу з ім'ям власним є домашнє завдання і що взагалі "легко бачити, що".
Кожному прикметника ставимо у відповідність клас і називаємо його базовим. Ще краще - абстрактним. Якщо мова дозволить. Тим, хто пише на Java, взагалі пощастило - прикметником слід зіставляти інтерфейс в тому вигляді, в якому він визначений в Java.
Йдемо далі - як тільки бачимо дієслово, сміливо створюємо функцію, оскільки дієслово є дія, що переводить одне в інше або щось кудись передавальне.
Союзи є сигнал про існування предикативних умов, якщо беруть участь у вихідних матеріалах дії або про існування наборів даних, якщо беруть участь у вихідних матеріалах дії.
У нашому прикладі отримаємо:
Базові класи:
TСтройний, TЗелений.
Класи - спадкоємці, які можна завести:
ТЛес, теличку, ТЗіма, тліти.
Народитися, Рости, Бути.
Союз "і" однозначно вказує на наявність набору.
Цей крок найпростіший у технічному плані і може бути виконаний автоматично програмою проектування класів, якщо ця програма має досить великою словником. Одночасно з цим цей крок найбільш насичений ідеологічно - його виконання робить процес проектування незворотнім, який перейшов якийсь віртуальний рубікон і виключає існування ймовірних реальностей. Під сказав - навіть самого себе заінтригував.
Чому так? По наведеній ідеї проектування вихідний текст сам у собі містить деяку кількість визначень, якщо він виражений на якомусь зрозумілому людині мовою. Російська мова досить багатий в плані виразних можливостей і суть методи коштує в перекладі вже сформульованих визначень і відносин з однієї мови на іншу, що і є програмування, якщо цільовою мовою є машинна мова.
Прикметник відображається на абстрактні базові класи, оскільки прикметник за своєю суттю є ознака, що характеризує щось таким чином, що якщо прикметник ставиться до цього щось, то це щось є реалізація цього прикметника. Наприклад, якщо є прикметник "об'ємний", то завести такого об'єкта не можна. Але при цьому "об'ємним" можуть бути інші класи (іменники, імена загальні). "Об'ємним" може бути "ящик", "зображення", "поняття". Будь-яке з наведених іменників може бути використано в якості реалізації прикметника "об'ємний". Якщо деяку дію оперує поняттям "об'ємність", то як його аргументу можуть бути використані перелічені іменники. Приблизно так чинять механізми COM - оперуючи об'єктами, механізми ніколи не передають описувача об'єкта, завжди передається тільки описувач реалізованого інтерфейсу. Один об'єкт може реалізувати декілька інтерфейсів одночасно - наприклад, об'єкт може мати ознаки "об'ємний", "кольорової", "міцний" і так далі одночасно.
Іменники, імена загальні, відображаються в класи, за якими реально можуть бути заведені об'єкти. Основною відмінністю іменників є поняття "існування". Якщо щось є іменником, то це щось може існувати або не існувати. У програмуванні прямим аналогом є вписування в архітектуру класів однозначно виділеного класу, що відповідає саме за можливість заклади об'єкта. У Delphi це клас TObject, в MFC - CObject, в Java - теж щось типу Object. Класи, які можуть мати представників (за яким можна створити об'єкт), практично завжди є спадкоємці такого роду базового класу з додаванням власної поведінки та / або з множинним спадкуванням раніше оголошених інтерфейсів. При цьому інтерфейс базового об'єкта, скажімо TObject, реалізує саме і тільки інтерфейс існування. Для деяких засобів програмування такий об'єкт дійсно виглядає як якесь майже матеріальне ядро, що обростають іншими інтерфейсами. Але це необов'язково так. Наприклад, в тому ж COM функції існування виконуються через інтерфейс IUnknown.
Іменники, імена власні, відображаються на об'єкти як екземпляри якихось класів. Ім'я як в російській мові, так і в мові програмування грає одну й ту саму роль - вказати серед набору об'єктів один з них. Об'єкти іменуються і вказуються шляхом зазначення імені. Тут для розуміння методи, сподіваюся, нічого складного немає.
Дієслова відображаються на функції. Функції є реалізація алгоритму, послідовності якихось дій. Це не дані і не визначення. Функції відрізняються від інших понять тим, що вони здійсненні і при виконанні впливають на щось. Функція може щось перетворити, перевести об'єкт з одного стану в інший, або передати інформацію без змін. Прикметник характеризується набором дієслів. Вірно і зворотне - набір дієслів визначає прикметник, оскільки поняття визначається набором відносин, в якому вона бере участь. Наприклад, прикметник "об'ємний" може характеризуватися набором дієслів "вміщати", "порівняти". При цьому, що цікаво, якщо людині перерахувати набір слів, що його характеризує якесь прикметник, то він досить швидко відгадає це прикметник. Набір дієслів, що входять в опис прикметника, є ті ниточки, за які можна смикати об'єкт, до якого це прикметник ставиться. Дієслово в багатьох випадках програмістами не відноситься явно ні до якого прикметника, і при описі класу програміст просто успадковує клас TObject і додає йому функції. Насправді це так само є визначення прикметника, але, якщо можна так сказати, явно не іменованого. При цьому програміст міг би істотно виграти, якби додаються функції явно оформив би у вигляді інтерфейсу. Згодилося б на майбутнє.
Наявність спілок виду "і", "або", "не", "або" явно свідчить про існування предикативних умов або наборів даних. Якщо союз пов'язує аргументи якогось дії, то це формулювання предиката, якщо результату дії - то формулювання набору.
Як нескладно бачити, що приводиться методу проектування класів надзвичайно схожа на програмування мовою Пролог. Коли є вихідне опис прикладної області та завдання програміста полягає тільки в тому, щоб трохи переписати вихідну завдання, привести текст у відповідність з правилами опису визначень і фактів мови програмування, конкретного діалекту.
Крок 4
Крок полягає в тому, щоб з набору отриманих на третьому кроці відображень скласти ієрархію класів. Дієслова слід розподілити по прикметником, або явно додати до іменником. Іменники слід, якщо це необхідно, успадковувати від прикметників або від інших іменників. Імена власні повинні отримати клас і бути оформлені у вигляді об'єктів.
Отже, про дієсловах. Щоб віднести дієслово до прикметника, слід уважно прочитати вихідний текст російською і визначити контекст дії дієслова. З'ясувати, яке прикметник він характеризує. У нашому прикладі дієслова "народитися" та "рости" є неіменованим прикметниками і відносяться до іменника "ялинка". А дієслово "бути" відноситься до прикметника "кольорової" і "фігурний".
Прикметники "струнка" і "зелена" замінюємо на прикметники "фігурний" і "кольорової", відводячи їм можливість бути уточненими - яка саме фігура і який саме колір.
Іменники "ліс", "зима", "літо" відносимо до самостійних класів, утвореним від базового класу TObject. Іменник "ялинка" успадковуємо від базового класу TObject, від інтерфейсів "фігурний" і "кольорової", а також додаємо неіменовані інтерфейси з окремих дієслів "народитися" та "рости". Бути може, що при більшому обсязі вихідного тексту ми б прийшли до іншою схемою класів і виділили б ці неіменовані інтерфейси явно.
Досить цікавим є питання про союз "і". За початкового тексту, функція "бути" повертає набір з іменників "зима" і "літо". Якщо віднести ці іменники до різних класів, то отримаємо набір різнотипних даних. Це на мій погляд негарно і краще провести модифікацію схеми класів. Проведемо укрупнення класів "зима" і "літо" шляхом віднесення їх до одного класу і розрізненням їх ознакою "пора року". Вихідною ієрархією є:
class ТЗіма: public TObject {};
class TЛето: public TObjct {};
Результуючої ієрархією є укрупнена або агрегована:
enum ЕВремяГода = {зима, літо};
class ТВремяГода: public TObject
{
public:
ЕВремяГода ВремяГода;
};
Якщо цільова мова програмування дозволяє, то слід визначитися зі специфікатором константності аргументів, переданих за посиланням, і константності функцій за ознакою - змінює функція стан об'єкта чи ні. Якщо функція не змінює стан об'єкта, то, очевидно, вона може бути оголошена константної. До речі, якщо в результаті проектування класів ми отримаємо класи з тільки константними функціями, то сміливо можна сказати, що вихідний текст містив опис статичного стану об'єктів. Якщо ж в ієрархії отриманих класів всі функції тільки константні, то значить схема класів млява. І після цього можна йти назад до постановника і голосно запитувати: "І?"
Крок 5
На цьому кроці, до речі, останньому, слід акуратно, без помарок виписати схему класів на обраною мовою програмування. Тут вже потрібні тільки акуратність і знання синтаксису мови.
У нашому прикладі може вийти щось типу:
# Include ...
class TЛес: public TObject {};
enum ЕВремяГода {зима, літо};
class ТВремяГода: public TObject
{
ЕВремяГода ВремяГода;
public:
const ЕВремяГода GetВремяГода ()
{Return ВремяГода};
ТВремяГода (const ЕВремяГода & _ВремяГода)
: TObject (), ВремяГода (_ВремяГода)
{};
};
/ / Тут є два варіанти і другої в тім, щоб оголосити
/ / Час року як typedef ЕВремяГода ТВремяГода;
/ / Який варіант вибрати - справа смаку.
/ / Я вибрав перший тому, що він дозволяє заборонити
/ / Зміна пори року для створеного об'єкта.
typedef vector ВременаГода;
enum Фігура {ніяка, струнка};
enum Колір {ніякої, зелений};
class TФігурний
{
public:
/ / Отримання фігури, знаючи пори року
const virtual Фігура Бути (ВременаГода &) = 0;
/ / Отримання пори року, знаючи фігуру
const virtual ВременаГода Бути (Постать) = 0;
};
class TЦветной
{
public:
/ / Отримання кольору, знаючи пори року
const virtual Колір Бути (ВременаГода &) = 0;
/ / Отримання пори року, знаючи Колір
const virtual ВременаГода Бути (Колір) = 0;
};
class Теличка
: Public TObject,
public ТФігурний,
public ТЦветной
{
public:
const virtual Фігура Бути (ВременаГода &);
const virtual ВременаГода Бути (Постать);
const virtual Колір Бути (ВременаГода &);
const virtual ВременаГода Бути (Колір);
const ТЛес Народитися ();
const ТЛес Рости ();
Теличка (); / / конструктор викликається, коли ялинка народиться
~ Теличка ();
/ / Деструктор викликається не тоді, коли ялинку зрубають,
/ / А тоді, коли після Нового Року викинуть на смітник
/ / І бідний двірник повинен буде її спалити, оскільки
/ / Ялинки у контейнери вантажити не можна;)
};
/ / Отримали дві функції Бути з однаковим аргументом.
/ / Подібні проблеми слід вирішувати за правилами застосовуваного
/ / Мови. У нашому випадку доведеться поміняти
/ / Імена функцій на менш читабельні.
У прикладі я хотів спочатку писати на Object Pascal. Подумки розмовляючи з читачем, почув шум і тупіт ніг і вигуки з місць - "А чому не С ++?". Подумав і погодився - хай буде на C + +. Звичайно ж, наведена методу не є абсолют. Як то кажуть, якщо переможеш в бою з порушенням статуту - молодець, творчо мислиш, відкидаючи застарілі догми. Якщо програв дотримуючись статут - негідник, який не зміг осягнути вікові істини. Якщо дана методу кому допоможе - то-то я порадію ... Мені особисто іноді допомагає, особливо коли голова вже нічого не тямить і доводиться діяти на автопілоті. Або коли доводиться розбиратися в исходники і відгадувати - що ж автор хотів сказати. Здійснювати свого роду модний нині реінжиніринг. Що цікаво, потім на свіжу голову проглянеш що понаписував і дивуєшся своїй прозорливості і взагалі того, що це працює.