Після того, як виконана декомпозиція програми (розроблена її структура) і відомі алгоритми розв'язку задач, можна приступати до реалізації наміченого плану. Потрібно чітко уявити, з якими даними буде працювати програма (чи окремий модуль) та які дії над ними доведеться виконувати. Дані та дії над ними утворюють об'єкт. Також можна уявити програму як набір об'єктів (реально існуючих фізичних об'єктів або абстрактних понять, що існують лише в нашій уяві), які взаємодіють між собою.
Наступним етапом буде поділ об'єктів на групи, що мають хоча б щось (дані, властивості, функціональність). У більшості випадків об'єкти будуть більше чи менше подібні. Деколи в групах можна буде виділити підгрупи і т. д., аж до складного ієрархічного дерева.
У кожній групі виділється найзагальніші властивості, притаманні всім без винятку об'єктам у групі та дії над ними. Отже, отримаємо базовий клас для цієї групи об'єктів, даними якого будуть загальні параметри об'єктів групи, а методами — дії, які можна проводити над даними будь-якого об'єкта групи.
Далі для кожної з підгруп (у межах виділеного класу об'єктів) додаємо притаманні лише їй властивості, як поля нового, породженого від базового класу. Додаткові дії, які властиві кожній підгрупі, стають методами породжених класів, а параметри, яких не мали об'єкти базового класу, — даними породжених (похідних) класів. Породження класів продовжується до тих пір, поки не будуть описані всі параметри об'єктів та дії, які необхідно над ними здійснювати для розв'язку поставлених задач. Описана послідовність повторюється для кожної з Групи об'єктів у програмі.
Для прикладу розглянемо програму, яка повинна грати в шахи. У ній можна виділити такі дві Групи об'єктів: перша — реалізує графічне відображення на екрані шахової дошки та фігур на ній, друга — реалізує логіку роботи програми — генерує ходи, перевіряє їх правильність, слідкує за часом і т. д.
Розглянемо першу групу. З чого вона складається? Сюди входять різноманітні видимі елементи: дошка, клітинки на ній, різні фігури, позначення рядів на дошці. Які в них параметри? Це — координати, розміри, колір для фігур, для клітинки — ще тип фігури, яка на ній знаходиться, для дошки — ще масив клітинок на ній і т. д. Які дії повинні виконувати об'єкти? Вони повинні реагувати або не реагувати на натискання мишкою чи на клавіатуру, відображатися, зникати, деякі ще повинні переміщуватись, причому по-різному. Що ж є спільним для них усіх? Серед параметрів — напевне, координати центра, ще колір і розмір по горизонталі та вертикалі, з дій — кожен із об'єктів повинен уміти створюватися, знищуватися та відображати себе на екрані.
Таким чином, базовий клас буде містити такі поля даних: координати "х", "у", "ширина", "висота", "колір"; методи — конструктор, що створює об'єкт, деструктор, що його знищує, та метод "відобрази себе". Оце й усе! Але описане лише один раз (!) для всіх видимих об'єктів.
Далі можна розділити видимі об'єкти на пасивні та активні.
Пасивними будуть написи на дошці, що позначають назви рядів, активними — всі решта, вони повинні мати метод, який змушує їх реагувати на натискання мишкою.
Тепер виділимо ще підклас фігур, що породжується від класу "активні видимі елементи", який має додатковий метод "перемісти мене" та поле даних або метод, що визначає допустимі ходи для даної фігури.
нший підклас ("група"), куди входять клітинки на дошці й сама шахова дошка, не повинен уміти переміщуватись, зате має важливу властивість — містити в собі (візуально — "на собі") інші об'єкти. Так, дошка містить 64 клітинки, а кожна клітинка — може містити якусь фігуру. Тому до даних цього класу, також породженого від "активних видимих елементів", слід додати ще поле даних (напевне, вказівник), який містить інший об'єкт(-и) класу — "видимі елементи". Також необхідні методи, які ці об'єкти "вставляють" у клас "Група" або видаляють з "Групи". Метод "відобрази себе" для "групи" завдяки поліморфізму можна доповнити відображенням об'єктів "групи" після того, як відобразилася сама "група".
Далі від "групи" можна успадкувати нові класи: "шахова дошка", "шахове поле", а від "шахового поля" — "поле останнього рядка", яке крім методів свого попередника може ще й перетворювати "пішака" у "королеву".
Цей, далеко не повний, приклад дає можливість зрозуміти лише основний підхід до проектування класів. Пофантазувавши трохи, можна отримати досить елегантну й, головне, завершену ієрархію об'єктів, які будуть уміти робити все, що від них може вимагати головна програма для розв'язування поставлених задач. Основне — кожна спільна для кількох об'єктів дія (і спільний елемент даних) описана лише один раз у базовому класі і більше ніде її не потрібно описувати повторно.
Якщо деякі дії передбачають виконання операцій над кількома об'єктами і при цьому необхідно мати безпосередній доступ до закритих даних класу, то такі дії робимо дружніми функціями для того класу, над даними якого вони працюють.
Деякі типи даних, які не доцільно робити класом, оскільки вони не мають власної функціональності, але які неодноразово використовуються в програмі (наприклад, масиви фіксованої довжини, списки чи структури) можемо описати, використавши typedef і помістити в заголовок одного з модулів.
Підрозділ "Розробка системи класів" відображає основну роботу, яка виконується при об'єктно-орієнтованому програмуванні, в результаті чого отримуються описи всіх класів з даними та методами, причому для методів уже задані їх параметри та тип результату, який вони повертають. Тобто, з точки зору інтерфейсу, робота над класами на цьому етапі вже завершена. Залишилося тільки "навчити" методи виконувати свою роботу.
Глобальні функції, які не є методами ні одного з класів, також поміщаються в один із модулів, а їх інтерфейсна частина описується в цьому підрозділі.
3.6.3 Розробка методів
Після того, як з інтерфейсною частиною "закінчено", залишилося лише розробити реалізацію методів, дружніх та глобальних функцій. Це завдання є досить простим, якщо на попередньому етапі було правильно спроектовано систему класів та детально пророблено інтерфейсні частини. Реалізація будь-якої функції (чи методу) розміщується в *.срр - частині модуля, на відміну від інтерфейсу, яка записується у *.h- файл. Потрібно лише акуратно записати ті дії, які має виконувати метод чи функція, не забуваючи користуватися вже готовими функціями та методами замість того, щоб увесь час змінювати дані за допомогою одних і тих же послідовностей операцій.
Так, метод "перемісти мене" (див. приклад у попередньому пункті) повинен лише змінити координати активного видимого елемента, а не намагатися перемалювати його самостійно — метод "відобрази себе" зробить це набагато краще.
Аналогічно метод "відобрази себе" для "групи" (шахової дошки чи клітинки), який повинен відображати об'єкти Групи після того, як відобразилася сама група, реалізується з використанням поліморфізму та успадкування. При цьому додається лише один-два оператори, оскільки і ґрупа, і видимі елементи вже самі вміють відображатися, необхідно лише "сказати" їм, щоб вони це зробили один за одним. У методі "відобрази себе" групи спочатку викликається метод "відобрази себе" базового класу ("видимий елемент"), який відображає саму дошку або клітинку, а далі — методи "відобрази себе" для всіх видимих елементів, що входять до групи. Для клітинки Це буде виклик "відобрази себе" для фігури, що стоїть на клітинці, а для дошки — виклик "відобрази себе" для всіх позначок та клітинок, які, у свою чергу, відобразять фігури, що на них знаходяться.
У даному підрозділі слід описати принцип дії основних методів та відмінності поліморфних (віртуальних) методів від методів базових класів.
3.6.4 Створення об'єктів і розробка головної програми
Нарешті, У цьому підрозділі слід описати процес створення самих об'єктів у програмі, функціональність та дані яких розроблені в попередніх підрозділах. Якщо кількість об'єктів, що будуть створені наперед невідома, або обсяг пам'яті, яку вони займають, є досить значним, тоді пам'ять для об'єктів слід виділяти "динамічно" з використанням оператора new.
Стосовно розглянутого прикладу із шахами, даний підрозділ, очевидно буде описувати, як створюється шахова дошка з 32 фігурами на ній та як перетворюються вибрані партнерами ходи в повідомлення шаховим фігурам.
Створивши об'єкти, можемо реалізувати певну послідовність дій або схему взаємодії між об'єктами, яка призводить до вирішення поставленого завдання.
Опис цієї послідовності дій чи схеми взаємодії, можливо, з прикладами для реальних вхідних даних чи повідомлень і є основою даного підрозділу. Такий опис повинен бути достатнім для розуміння всіх деталей реалізації алгоритму та можливих випадків, що зустрічаються при роботі програми.
3.6.5 Опис файлів даних та інтерфейсу програми
Якщо програма використовує файли як джерело вхідних даних або для зберігання проміжних чи кінцевих результатів роботи, то в даному підрозділі слід навести опис формату цих файлів. Він може бути виконаний у текстовому, табличному чи графічному вигляді.
Можна додавати до нього приклади реальних файлів із даними програми.
Особливо важливий даний підрозділ для програм, що працюють із базами даних, адже структура таблиць бази даних, перелік, типи полів, засоби взаємодії з базою даних, перетворення даних є основою таких програм.
Для інтерактивної програми з розвинутою системою меню та діалогових вікон у цьому підрозділі слід описати призначення елементів меню, роботу з ними, параметри, що вибираються в діалогових вікнах тощо. У цьому ж розділі слід описати інтерфейс програм, які працюють з параметрами командного рядка.
Якщо темою роботи є розробка модулів або бібліотеки, то слід детально описати порядок їх використання, навести в алфавітному порядку всі доступні для користувача глобальні типи даних і змінні, функції та класи.
