Вибирайте інфраструктури, що добре поєднуються з іншими

Ерік Готорн

При виборі програмних інфраструктур, які будуть покладені в основу вашої системи, необхідно враховувати не тільки якість і можливості кожної інфраструктури (framework), але і те, як вони будуть взаємодіяти один з одним і наскільки легко буде адаптувати їх до нових програмним елементам, які вам, можливо, доведеться додати в ході еволюції системи З цього випливає, що обрані інфраструктури повинні бути неперекривающіеся, простими, компактними і спеціалізованими

Найкраще, якщо кожна інфраструктура або стороння бібліотека буде ставитися до окремої логічної області та вирішувати відокремлену завдання, не втручаючись в область інших задіяних інфраструктур

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

Щоб знизити ймовірність функціонального перекриття, вибирайте інфраструктури з високим відношенням корисного навантаження до баласту в контексті вимог вашої системи Корисне навантаження – це функціональність або можливості представлення даних, необхідні вашому проекту, а баласт – те, наскільки інфраструктура прагне охопити все що можна і вирішити всі завдання на світі Чи вимагає інфраструктура змішувати управління даними та їх подання Як сильно її модель даних або набір пакетів / класів виходять за межі того, що необхідно вашій системі Чи доведеться вам присягнути їй на вірність і надалі обмежити вибір інфраструктур тими, що відповідають її рамкам Чи обмежує її надлишкова складність можливості взаємодії Якщо вже інфраструктура обтяжена великою кількістю баласту, вона повинна забезпечувати хоча б 75% необхідної функціональності проекту

Система повинна складатися з неперекривающіхся інфраструктур – блискучих у своїй області, але при цьому простих, компактних і гнучких

Ерік Готорн (Eric Hawthorne) професійно займається створенням архітектури, проектуванням і розробкою обєктно орієнтованих програм і розподілених систем з 1998 року Перші 10 років його карєри пройшли в Macdonald Dettwiler – канадської системотехнической компанії, де серед іншого він мав можливість повчитися архітектурним тонкощам у самого Філіпа Крачтена (Philippe Kruchten)

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*