1.4 Огляд коп

У зв’язку з тим, що неконтрольване застосування ООП призводить до викикнення проблем із здатністю великих програмних комплексів виконувати потрібні функції в заданих режимах та умовах застосування застосовують КОП(компонентно-орієнтоване програмування). КОП – одна з парадигм програмування, виникла як свого роду дисципліна, тобто набір певних обмежень, що накладаються на механізм об'єктно-орієнтованого програмування [7].

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

Працівники програмної інженерії розглядають компоненти як частину стартової платформи орієнтації на обслуговування. Компоненти відіграють цю роль, наприклад, у веб-сервісах та з недавніх пір у сервісно-орієнтованих архітектурах (SOA), завдяки чому компонент перетворюється веб-сервісом у сервіс та згодом успадковує подальші характеристики, вищі за характеристики звичайного компонента [7].

Компоненти можуть створювати або споживати події і можуть використовуватися для архітектур, керованих подіями (EDA) [7].

Індивідуальний програмний компонент – це програмний пакет, веб-служба, веб-ресурс або модуль, який інкапсулює набір пов'язаних функцій (або даних). Всі системні процеси розміщуються в окремі компоненти, так що всі дані та функції всередині кожного компонента є семантично пов'язаними (так само, як і зі змістом класів). Через цей принцип часто говорять про те, що компоненти модульні та згуртовані. Що стосується загальносистемної координації, компоненти спілкуються один з одним через інтерфейси. Коли компонент пропонує послуги для решти системи, він приймає наданий інтерфейс, який визначає послуги, якими можуть користуватися інші компоненти, і як вони можуть це робити. Цей інтерфейс можна розглядати як підпис компонента - клієнту не потрібно знати про внутрішню роботу компонента (реалізації), щоб ним скористатися. Цей принцип призводить до того, що компоненти, які називаються ікапсульованими [7].

1.4 Принципи SOLID

SOLID – це абревіатура складена з перших літер п'яти базових принципів об'єктно-орієнтованого програмування та дизайну запропонована Робертом Мартіном [9]. Принципи SOLID є дуже важливими при написанні програми так, як при їх дотриманні структура програми стає чіткою та правильною. Принципи SOLID використовуються для дизайну та розробки таких програмних систем, які, з великою ймовірністю, зможуть тривалий час розвиватися, розширятися і підтримуватися [9].

SOLID розшифровується як:

• принцип єдиного обов'язку (Single responsibility principle): Кожен об'єкт має виконувати лише один обов'язок;

• принцип відкритості/закритості (Open/closed principle): Програмні сутності повинні бути відкритими для розширення, але закритими для змін. Розширення певного класу/інтерфейсу може здійснюватись через його успадкування;

• принцип підстановки Лісков (Liskov substitution principle): Об'єкти в програмі можуть бути заміненими їх нащадками без зміни коду програми;

• принцип розділення інтерфейсу (Interface segregation principle): Багато спеціалізованих інтерфейсів краще за один універсальний. Інтерфейс може бути поділений на спеціалізовані ще на стадії проектування, заради майбутньої гнучкості програмних компонентів;

• принцип інверсії залежностей (Dependency inversion principle): Залежності всередині системи будуються на основі абстракцій, що не повинні залежати від деталей; навпаки, деталі мають залежати від абстракцій. Модулі вищих рівнів не мають залежати від модулів нижчих рівнів [9].

1.5 MVVM

Model-View-ViewModel – це шаблон проектування, що застосовується під час проектування архітектури застосунків (додатків). Публічно вперше був представлений Джоном Госсманом (John Gossman) у 2005 році як модифікація шаблону Presentation Model. MVVM орієнтований на такі сучасні платформи розробки, як Windows Presentation Foundation та Silverlight від компанії Microsoft [8].

MVVM полегшує відокремлення розробки графічного інтерфейсу від розробки бізнес логіки (бек-енд логіки), відомої як модель (можна також сказати, що це відокремлення представлення від моделі). Модель представлення є частиною, яка відповідає за перетворення даних для їх подальшої підтримки і використання. З цієї точки зору, модель представлення більше схожа на модель, ніж на представлення і оброблює більшість, якщо не всю, логіку відображення даних. Модель представлення може також реалізовувати патерн медіатор, організовуючи доступ до бек-енд логіки навколо множини правил використання, які підтримуються представленням [8].

MVVM використовується для відокремлення моделі та її відображення. Необхідністю цього є надання можливості змінювати їх незалежно одну від одної. Наприклад, розробник працює над логікою роботи з даними, а дизайнер – з користувацьким інтерфейсом [8].

Шаблон MVVM ділиться на три частини: модель (Model), як і в класичному шаблоні MVC, Модель являє собою фундаментальні дані, що необхідні для роботи застосунку. Вид(View), як і в класичному шаблоні MVC, – це графічний інтерфейс, тобто вікно, кнопки тощо. Модель вигляду (ViewModel, що означає «Model of View» ) з одного боку є абстракцією Вигляду, а з іншого надає обгортку даних з Моделі, які мають зв'язуватись. Тобто вона містить Модель, яка перетворена до Вигляду, а також містить у собі команди, якими може скористатися Вигляд для впливу на Модель. Фактично ViewModel призначена для того, щоб :

• здійснювати зв'язок між моделлю та вікном;

• відслідковувати зміни в даних, що зроблені користувачем;

• відпрацьовувати логіку роботи View (механізм команд) [8].