Модульність
Інкапсуляція дозволяє сховати від кінцевого користувача деталі реалізації і зробити систему менш складною і більш зрозумілою. Концепція модульності йде далі. Тепер, коли об'єкти визначені і непотрібні подробиці заховані, потрібно згрупувати об'єкти в логічні модулі, що поєднують взаємозалежні об'єкти і класи, а іншим модулям нехай будуть доступні тільки ті деталі інтерфейсу, що абсолютно необхідні. Інтерфейсні частини знаходяться у файлах заголовків (за традицією вони мають розширення .h чи .hpp). При цьому деталі реалізації, що не представляють інтересу для інших модулів, залишаться у файлах типу .с, .сс, .ср чи .срр. У чому переваги такого підходу?
По-перше, уявимо собі програмний проект, у якому беруть участь кілька програмістів. Коли класи й об'єкти рознесені по окремих модулях, кожен програміст може працювати незалежно від інших. Один з одним модулі поєднують тільки інтерфейсні частини об'єктів, що знаходяться в заголовних файлах і визначені звичайно до стадії реалізації. Модульність підтримує великомасштабне програмування - на противагу програмуванню маломасштабному, що має схильність валити всі класи й об'єкти в одну купу. У об’єктно-орієнтованій розробці фізичному втіленню передує визначення абстрактних і логічних взаємин.
По-друге, перевага модульної організації в тім, що окремі модулі можна модифікувати і перекомпілювати, не торкаючись серйозно іншу частину системи — інтерфейси залишаються тими ж, що були.
Третьою перевагою модульності є легкість, з якою уміло згруповані по модулях об'єкти і класи можна повторно використовувати в інших проектах з мінімальними змінами чи без них взагалі. Повторне використання програмного забезпечення — це одна з найвищих цілей об’єктно-орієнтованої розробки; немає кращого шляху полегшити собі роботу, чим використовувати класи, об'єкти і модулі, що уже добре відомі!
Ієрархія
Навіть маючи на озброєнні абстракцію, інкапсуляцію і модульність, можна упустити загальну картину системи: навколо стільки абстрактних об'єктів, що за всіма просто не устежити. І отут приходить на допомогу ієрархія. Ієрархію можна вважати, мабуть, візитною карткою об'єктно-орієнтованого стилю. Найбільш затяті його адепти стверджують навіть, що якщо в проекті не використовується ієрархія ( частіше називають наслідуванням), то він просто не об'єктно-орієнтований.
При розгляді абстракції великі переваги дає виділення об'єктів з певною визначеною функціональністю. При аналізі проблемної області часто буває, що кілька об'єктів мають очевидно схожі структури чи функціональність. Якщо поводження об'єкта чи класу аналогічно поводженню іншого класу, то ми маємо справу з простим наслідуванням. Якщо ж у функціональності чи структурі класу присутні риси декількох класів, то має місце випадок множинного наслідування.
Наслідування часто пояснюють як можливість установити відношення "приналежності" між об'єктами, класами і типами даних. Явний приклад множинного спадкування: качконіс – успадковує характерні риси як ссавців, так і пернатих. Без механізму спадкування вам доведеться постійно повторюватися. Таким чином, ієрархія — це ще одна характеристика об'єктів, яку завжди варто відшукувати, займаючись об'єктно-орієнтованими аналізом і проектуванням.
Поліморфізм
Поліморфізмом називають можливість перевизначення різних функцій та операцій. Поліморфізм полягає в тому, що, по-перше, будь-яку операцію або функцію, яка визначена стандартним чином, можна перевизначити всередині класу так, що вона виконуватиме зовсім інші дії, по-друге, може існувати одночасно багато різних функцій у класі з однаковим ім’ям, але з різною кількістю або типами параметрів.
Огляд аналізу і проектування
Поняття об'єктно-орієнтованого аналізу, проектування і програмування дуже близькі і нерідко вживаються одне замість іншого. Але, перш ніж йти далі, давайте все-таки коротко позначимо розходження між ними:
З об'єктно-орієнтованого аналізу, як правило, починається цикл розробки; ми розглядаємо задачу з погляду класів і об'єктів.
На стадії проектування в нас уже сформувалося виразне уявлення про проблему як сукупності сутностей і їхніх взаємин, і ми починаємо розбивати задачу на реальні класи й об'єкти.
Об’єктно-орієнтоване програмування полягає власне у втіленні в життя наших класів і об'єктів (використовуючи, у даному випадку, C++).
Темі об'єктно-орієнтованого аналізу і проектування присвячено чимало чудових глибоких праць: але практично всі автори — як теоретики, так і практики— згодні з думкою батька-засновника C++ Бъярна Страуструпа (Bjarne Stroustrop), який стверджує, що досконалих правил ідентифікації об'єктів проблемної області не буває. Експериментування, навчання на своїх успіхах і своїх помилках — це найкраще правило.
Методи аналізу
Об'єктно-орієнтований аналіз переслідує своєю ціллю розглянути об'єкти у вашій проблемній області. Можна намагатися класифікувати об'єкти по подібності в поведінці чи характерних рисах. Це непроста задача, але давайте згадаємо — існує безліч наук набагато більш древніх, ніж обчислювальна техніка, у яких класифікація об'єктів своєї предметної області дотепер залишається улюбленим проводженням часу. Так що нічого немає правильного або неправильного — потрібно працювати з тим, що працює!
Аналіз поведінки
Звичайно основна увага приділяється ідентифікації в задачі об'єктів реального світу. Однак іноді буває зручніше розглядати наслідувані обов'язки — хто, кому і що повинено надати — і будувати ієрархію, групуючи спільні обов'язки.
Аналіз області застосування
Коли йде розробка якоїсь системи, то це, найчастіше, не перша система такого роду. Можна поговорити із людьми, знайомими з предметом. Наприклад, якщо йде розробка вексельної системи для юридичної фірми, можна поговорити з юристами і нотаріусами. Вони, напевно, користалися схожими системами і можуть розповісти масу цікавого не тільки про те, що повинна робити нова система, але і про те, чого вона робити не повинна. І ще вони прекрасно знайомі з "об'єктами", що будуть фігурувати в системі — протоколами, звітами і т.п. Ніколи не можна недооцінювати знання і можливу допомогу кінцевих користувачів.
Аналіз "з кінця"
Експерти в предметній області абсолютно незамінні, коли розглядається задача з погляду майбутнього використання продукції. Спілкуючись з користувачами, потрібно уявити собі різні схеми роботи системи. А потім, програючи ці сценарії, вичленувати об'єкти, взаємозв'язки і моделі поведінки, необхідні для забезпечення адекватної функціональності.
Структурний аналіз
Ми всі дуже добре знайомі з практикою поділу задачі на підзадачі. Чи то це обумовлено нашим освітою, чи це в нашій природі, але для більшості з нас це не представляє особливих зусиль. Виділивши етапи і під етапи, спробуємо побачити об'єкти і їхні взаємозв'язки.
Який би аналітичний підхід до проблеми не застосовувався, завжди потрібно пам'ятати, що ж ми шукаємо. Ключові характеристики об'єктів — це абстракція, інкапсуляція, модульність і ієрархія. Коли ми окреслили об'єкти — будь-яким доступним нам методом — почнемо з того, що постараємося зрозуміти, яка інформація абсолютно необхідна взаємодіючим класам (інкапсуляція). Розберемося, які класи взаємозалежні, а які ні (модульність). І нарешті подивимося, які класи мають схожі характеристики і функціонування (ієрархія). Поки ми перебуваємо в стадії аналізу і проектування, ми вільні як завгодно комбінувати об'єкти, розділяти їх і так далі. Коли ж почнеться реалізація, повертатися буде вже занадто пізно. Давайте експериментувати, поки є можливість!
Проектування
Як уже згадувалося, об'єктно-орієнтовані аналіз і проектування — дуже близькі родичі. Коли задача проаналізована, залишається насправді тільки уточнити деталі реалізації. Тут самий час зосередитися на взаємозв'язках між об'єктами і модулями. Роздивитися типи спадкування між об'єктами, визначити необхідні типи повідомлень, число параметрів і так далі. Існує ряд систем позначення для відтворення проекту на папері. Гарне документування проекту може істотно полегшити його втілення в життя.
Вигоди
Тепер, розглянувши характеристики об'єктів і деякі технології аналізу і проектування, можна коротенько резюмувати вигоди об’єктно-орієнтованої розробки.
Проект повинен
• Грамотно використовувати об'єктно-орієнтовані конструкції C++. Широко використовуйте класи і наслідування.
• Створювати по можливості самодостатні класи — вони будуть гарними кандидатами на повторне використання.
• Бути зрозумілим. Найбільша вигода об'єктно-орієнтованого проектування — в представленні проблеми в легкодоступному, тим хто розуміє, вигляді.
Захоплення ресурсів при ініціалізації
Однією з переваг об'єктно-орієнтованого програмування, яке упускається часто з виду, — це концепція захоплення ресурсів при ініціалізації, що належить Бьерну Страуструпу. Конструктори в C++ викликаються при створенні об'єкта, а деструктори — при його видаленні, оскільки він стає більш не потрібний. Об'єкти, що вимагають ресурсів, такі як файли або блоки пам'яті повинні успішно захоплювати потрібні ресурси ще до того, як їх можна буде вважати дійсно створеними.