Проектування класів у жарт і всерйоз

Євген Каратаєв

Іноді так буває - зберуться люди і починають обговорювати серйозні проблеми. І втомлюються вже, а все одно продовжують. Зупинитися вже не можуть, тому як несерйозно вийде. І думки вже закінчуються. І тут хтось говорить жарт і всі сміються і ситуація розрядиться. Як така жартівлива розрядка і з'явилася ця робота. Незважаючи на жартівливість і нібито несерйозність, частка цікавого і корисного в ній є.

Як проектувати класи?

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

Щоб спроектувати класи, слід виконати по кроках наступний рецепт. Опис рецепта буде ілюструватиметься на настільки банальному прикладі, щоб його не можна було використовувати в реальній роботі. Як це і прийнято у справжніх комп'ютерних публікаціях.

Крок 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 + +. Звичайно ж, наведена методу не є абсолют. Як то кажуть, якщо переможеш в бою з порушенням статуту - молодець, творчо мислиш, відкидаючи застарілі догми. Якщо програв дотримуючись статут - негідник, який не зміг осягнути вікові істини. Якщо дана методу кому допоможе - то-то я поради ... Мені особисто іноді допомагає, особливо коли голова вже нічого не тямить і доводиться діяти на автопілоті. Або коли доводиться розбиратися у вихідні коди і відгадувати - що ж автор хотів сказати. Здійснювати свого роду модний нині реінжиніринг. Що цікаво, потім на свіжу голову перегляньте що понаписали і дивуєшся своїй прозорливості і взагалі того, що це працює.