Організація предметної області

У кожної інформаційної системи є предметна область. Це набір термінів, об'єктів і правил, якими оперує додаток. Організація предметної області, одна з найскладніших завдань, яка сьогодні стоїть перед розробниками. У переважній більшості випадків функціонування предметної області забезпечують реляційні бази даних і об'єктно-орієнтовані технології відображення. Реляційний і об'єктно-орієнтований підхід геніальні окремо. Проте їх композиція, при невмілому поводженні, перетворює архітектуру інформаційної системи в купу мотлоху, розібратися в якій буде важко навіть досвідченому фахівцеві.

Організація подання

Уявлення - це підсистема відображення даних. З її допомогою логіка предметної області відокремлюється від логіки відображення даних. Уявлення - це найстабільніша частина інформаційної системи. Відображення даних може мінятися дуже часто, на відміну від самих даних і методів їх обробки. Тому framework-система повинна надати зручні та гнучкі механізми роботи з логікою відображення. Для вирішення цього завдання використовуються шаблонні системи, чиє завдання полягає у відділенні логіки відображення і укладання її в окремі файли (шаблони відображення), які можна редагувати окремо від усіх інших частин системи. Завдяки цьому, роботу над проектом можна ефективно розпаралелити (Організація предметної області → програміст + адміністратор БД, Організація подання → верстальник + дизайнер).

Організація допоміжних підсистем

Під допоміжними підсистемами мається на увазі набір архітектурних рішень, покликаних полегшити працю програміста. Сюди можна віднести реалізації патернів загального призначення, які безпосередньо не відносяться до інших підсистем. Зокрема до допоміжних підсистем відносяться такі поняття як резолверів, хендла, різний реєстр (и), спостерігачі і т.д. Ці речі можуть бути використані в будь-якій іншій підсистемі для вирішення виникаючих проблем.

Наприклад, патерн singletone (одиночка) може бути використаний для підтримки декількох інстанцій об'єкта в одиничному екземплярі. Це завдання носить суто допоміжний характер і не може бути віднесено безпосередньо до рівня бізнес-логіки або будь-якого іншого.

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

Маленькі бібліотеки

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

Одна з причин трагедії: люди не люблять маленькі бібліотеки. Є в маленьких бібліотеках щось таке, що люди вважають неправильним. Придушіть в собі це почуття. Комп'ютеру абсолютно все одно, скільки у вас бібліотек.

Якщо ви написали код, який можна використовувати повторно, але він не вписується в вашу бібліотеку, створіть нову.

Тримайте свою базу бібліотек [репозиторій]

Більшість компаній не має ніякого поняття, який код у них є. І більшість програмістів до цих пір не повідомляють про те, що вони зробили і не цікавляться тим, що вже написано. Репозиторії покликані змінити ситуацію на краще.

В ідеальному світі програміст міг би зайти на сайт, подивитися по каталогу або пошуком знайти потрібний пакет бібліотек і закачати собі. Якщо ви можете налагодити таку систему, в якій програмісти на добровільній основі будуть підтримувати базу вихідників - це прекрасно. Якщо ви заведете бібліотекаря, який відстежує коефіцієнт повторного використання, то це просто розкішно.

Інший спосіб - автоматична генерація сховища з початкових кодів. Досягається подібний ефект через використання стандартних заголовків для класів, методів, бібліотек і різних підсистем. Такі заголовки служать водночас технічним керівництвом і пунктами в списку репозиторія.

Файли, що включаються

Можливість повторного використання існуючого коду є дуже важливим, тому що може зберегти час і гроші і сприяти узгодженості. Припустимо, що сайт Web містить текстове меню, яке повторюється на кожній сторінці. Замість повторного кодування меню буде значно легше закодувати його один раз і динамічно включати вміст меню на кожну з окремих сторінок Web. Це можна зробити за допомогою так званого серверного включення файлу.

Файли, що включаються можуть містити будь-який код XHTML або PHP і зазвичай зберігаються з розширенням. Inc, хоча можна використовувати також розширення. Php,. Txt, або. Htm. Вміст файлу, що включається кодується один раз і включається в будь-яку необхідну кількість сторінок PHP. Якщо під файлом, що включається робиться зміна, то оновлення автоматично відбивається на всіх сторінках PHP, які посилаються на цей файл.

Нижче показаний приклад типового файлу, що включається, що містить інформацію про заголовок сторінки.

Header.inc
<h3> Welcome to WebBooks.Com </ h3>
Цей приклад показує файл, що включається з ім'ям header.inc. Файл містить текст "Welcome to WebBooks.Com", оточений тегом XHTML <h3>. Він створює заголовок третього рівня, який можна тепер включати на всі сторінки, які складають сайт WebBooks. Після створення файлу, що включається, його можна включити в сторінку PHP за допомогою однієї з наступних функцій:
require (ім'я_файлу) - включає і перевіряє вказаний файл
include (ім'я_файлу) - інший спосіб підключення файлів

У наступному прикладі файл header.inc включається в існуючу сторінку PHP:
home.php
<? Php
require ('header.inc');
echo "<p> This is the WebBooks site...</ p>";
?>

Функція require () викликає файл header.inc і перевіряє вміст файлу. Вміст потім виводиться, так ніби воно було частиною сторінки home.php. У цьому прикладі функція require () кодується вгорі сторінки, так як вона містить інформацію заголовка. Оператор require () можна, однак, включити в будь-якому місці документа PHP. Розташування функції require () визначає, де буде виводитися вміст файлу в контексті сторінки PHP.
Welcome to WebBooks.Com
This is the WebBooks site...

Важливо відзначити, що при використанні файлів, що включаються, які містять конфіденційну інформацію, таку, як паролі або інформацію про користувача, файли повинні зберігатися з використанням розширення. Php, а не. Inc або іншого нестандартного розширення. Файли, які застосовують нестандартні розширення файлів, можуть завантажуватися з сервера Web, а їх вміст можна переглядати як звичайний текст. Використання розширення. Php гарантує, що клієнт не зможе побачити вихідний код, сервер поверне тільки код XHTML.

Використання функцій
Функції використовуються для розбиття великих блоків коду на менші, більш керовані одиниці. Міститься всередині функції код виконує певне завдання і повертає значення. PHP містить два типи функцій - визначені користувачем (або створені програмістом) і внутрішні (вбудовані функції), які є частиною визначення мови PHP. Цей розділ присвячений створенню та застосуванню певних функцій користувача.
Певні функції користувача створюються за допомогою ключового слова function. Вони особливо корисні у великих програмах PHP, так як можуть містити блоки коду, які можуть викликатися чи використовуватися в програмі, що дозволяє уникнути повторного переписування коду. Далі представлений приклад простої визначеної користувачем функції PHP:
function AddNumbers ($ num1, $ num2)
{

echo "Це приклад функції PHP. Вона обчислює суму двох чисел і повертає
результат, що викликається у програмі ";

 

return $ num1 + $ num2;

 

}

Певні функції користувача можуть викликатися в будь-якому місці блоку коду PHP. У PHP функція виконується при використанні в коді її імені. Після виклику функція отримує всі передані їй значення у формі параметрів, виконує певні завдання і повертає значення, що викликає програма. Простий приклад показаний нижче.
<? Php
function AddNumbers ($ num1, $ num2)

 

{
return $ num1 + $ num2;
}
echo "Сума 5 і 2 дорівнює". AddNumbers (5,2);
?>
Проте певна на початку функція AddNumbers () викликається тільки пізніше в програмі. Виклик функції відбувається в операторі echo. Виводиться рядок "Сума 5 і 2 дорівнює". Ім'я функції з'єднується з рядком виведення, викликаючи тим самим функцію. Для функції передається два параметри - 5 і 2. Вони присвоюються параметрами функції $ num1 і $ num2. Параметри складаються, і викликається оператор return, щоб "повернути" значення або суму двох чисел в те місце в блоці коду PHP, який спочатку викликав функцію. Висновок результату показаний нижче:
Сума 5 і 2 дорівнює 7
Імена функцій слідують тим же правилам, що і змінні у PHP. Допустимі імена можуть починатися з букви або підкреслення, після чого може слідувати будь-які літери, цифри або підкреслення.

Патерни проектування

Загальні відомості

В якості основи проектування інформаційних систем застосовуються "типові рішення" або "шаблони проектування" (Patterns).

Шаблони проектування (патерн, design pattern) - це багато разів застосовувана архітектурна конструкція, що надає рішення для загальної проблеми проектування в рамках конкретного контексту й описує значимість цього рішення.

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

У 1970-і роки архітектор Крістофер Олександр склав набір шаблонів проектування. В області архітектури ця ідея не отримала такого розвитку, як пізніше в області програмної розробки. Згідно з визначенням Крістофера Олександра: "Кожне типове рішення описує якусь повторювану проблему і ключ до її розгадки, причому таким чином, що ви можете користуватися цим ключем багаторазово, жодного разу не прийшовши до одного й того ж результату".

У 1987 році Кент Бек і Вард Каннігем взяли ідеї Олександра та розробили шаблони відповідно до розробки програмного забезпечення для розробки графічних оболонок мовою Smalltalk.

У 1988 році Ерік Гамма почав писати докторську дисертацію при Цюріхському університеті про загальну переносимість цієї методики на розробку програм.

У 1989-1991 роках Джеймс Коплін трудився над розробкою ідіом для програмування на C + + та опублікував у 1991 році книгу Advanced C + + Idioms. У цьому ж році Ерік Гамма закінчує свою докторську дисертацію і переїжджає до США, де у співробітництві з Річардом Хелмом, Ральфом Джонсоном і Джоном Вліссідсом публікує книгу Design Patterns - Elements of Reusable Object-Oriented Software. У цій книзі описані 23 шаблона проектування. Також команда авторів цієї книги відома громадськості під назвою Банда чотирьох (Gang of Four, часто скорочується до GoF). Саме ця книга стала причиною зростання популярності шаблонів проектування.

Іншим видатним діячем у галузі проектування програмних систем, який підтримав використання патернів, є Мартін Фаулер, який написав книгу "Архітектура корпоративних програмних додатків" (Patterns of Enterprise Application Architecture). Як зазначив Мартін Фаулер у своїй книзі "збираючись скористатися типовими рішеннями, не забувайте, що вони тільки відправна точка, а не пункт призначення".

У книзі Крейга Лармана "Застосування UML і шаблонів проектування" описано 9 шаблонів GRASP (General Responsibility Assignment Software Patterns, загальні зразки розподілу обов'язків) - патернів, використовуваних в об'єктно-орієнтованому проектуванні для вирішення спільних завдань за призначенням обов'язків класам і об'єктам. Кожен з них допомагає розв'язати певну проблему, що виникає при об'єктно-орієнтованому аналізі, і яка виникає практично в будь-якому проекті з розробки програмного забезпечення.

Головна користь кожного окремого шаблону полягає в тому, що він описує рішення цілого класу абстрактних проблем. Також той факт, що кожен шаблон має своє ім'я, полегшує дискусію про абстрактні структури даних (ADT) між розробниками, так як вони можуть посилатися на відомі шаблони. Таким чином, за рахунок шаблонів проводиться уніфікація термінології, назв модулів і елементів проекту.

Правильно сформульований шаблон проектування дозволяє, відшукавши вдале рішення, користуватися ним знову і знову.

Однак іноді шаблони консервують громіздку і малоефективну систему понять, розроблену вузькою групою. Коли кількість шаблонів зростає, перевищуючи критичну складність, виконавці починають ігнорувати шаблони і всю систему, з ними пов'язану. Нерідко шаблонами замінюється відсутність або недоліки документації, яка складна програмному середовищі.

Є думка, що сліпе застосування шаблонів з довідника, без осмислення причин і передумов виділення кожного окремого шаблону, уповільнює професійне зростання програміста. Люди, які дотримуються цієї думки, вважають, що знайомитися зі списками шаблонів треба тоді, коли "доріс" до них в професійному плані - і не раніше. Хороший критерій потрібного ступеня професіоналізму - виділення шаблонів самостійно, на підставі власного досвіду. При цьому, зрозуміло, знайомство з теорією, пов'язаної з шаблонами, корисно на будь-якому рівні професіоналізму і направляє розвиток програміста в правильну сторону. Сумніву піддається тільки використання шаблонів "за довідником".