Page 46 - 4252

лем, повинен бути переданий в контролер, і не повинен містити нічого, що від-
носиться до безпосереднього висновку (тобто має бути представлений у внут-
рішньому форматі програми).
Досить складно з першого разу розібратися і зрозуміти. На це потрібен час
і відповідний проект.
Але насправді нічого надскладного в цьому немає.
Уявімо собі як представлення будь-якого класу, який за допомогою шаб-
лонізатора виводить результат чи повідомлення про помилку. На його вхід по-
дається або масив з даними (об'єкт або що-небудь інше), або змінна, що містить
текст з помилкою.
В якості контролера буде виступати клас, що виробляє всі необхідні пере-
вірки коректності даних і генерує повідомлення про помилки. Перевірку даних
доцільно помістити саме в клас контролера, їх використовують досить часто.
Як варіант, можна просто успадковувати клас контролера від більш загального
класу, що реалізує перевірку вхідних даних за заданими правилами. Або, якщо
так буде зручніше, включити в клас контролера клас або серію функцій переві-
рки даних.
Цей же клас повинен передати дані, отримані в результаті роботи моделі, в
клас представлення для виводу.
Одними словами схему потоків даних у цій архітектурі пояснити складно,
тому звернемося до мови UML і до діаграми послідовностей зокрема (незначні
відступи від UML, прийняті в діаграмах, полягають в тому, що в деяких випад-
ках разом з іменами сутностей або об'єктів, дані переказують в дужках).
На цій діаграмі показана послідовність дій, а також послідовність переда-
них даних: від користувача, до користувача і між модулями.
Схема відображає типовий процес виведення форми, заповнення її корис-
тувачем і повернення користувачеві результатів. Ніяких помилок в даному ви-
падку не відбувається.
Діаграма послідовностей

45