Дуже часто у публікаціях про архітектуру програмного забезпечення можна знайти використання слів “шар”, “прошарок”, “пласт” чи “рівень” (layer). Навіть у найбільш популярному “архітектурному” патерні MVC (Model View Controller) використовується (помилково) концепція шарів, де Model, View та Controller є шарами.
Я помітив, що використання поняття шару швидше шкодить, аніж допомагає розумінню архітектури програмного забезпечення і тому вирішив опублікувати цей допис.
Як відбувається декомпозиція?
Як з’їсти слона? – По шматочку! Вирішення будь-якої проблеми, після того, як вона досліджена та зрозуміла, починається з її декомпозициї. Саме рішення початкової проблеми є композицією рішень менш складних проблем, на які було розкладено початкову проблему. За необхідністю підпроблеми також розкладаються на ще менші проблеми і так ми поїдаємо слона по шматочку.
Таким чином, наше рішення прадставляється деревом рішення підпроблем і це фундаментальна штука, майже як закон природи. Де ж тут можуть бути шари?
Вертикальний розтин
Якщо прослідувати певною гілкою дерева рішень, описаного вище, то будемо мати своєрідний вертикальний розтин, продемонстрований нижче на прикладі MVC “архітектури”.
Поняття шару має лише одне застосування – пояснення будови певного мікро-рішення, але навіть у такому випадку лише вводить в оману. Краще за все буде прийняти, що ніяких шарів не існує, окрім тих випадків, коли ми прискіпливо контролюємо одноманітність.
Навіщо це може бути необхідно? За допомогою одноманітності досягається простота розуміння, як щось працює. Цей же підхід використовується у фреймворках, наприклад, Ruby on Rails, що очікує реалізації розробниками певних ін’єкцій коду: моделей, контроллерів та відображень, що спростовує, але й сильно обмежує розробку.
Абстракція нашарувань, як і всі інші, “тече”. Виникають рівно ті ж проблеми, що й зі спадкуванням в ООП. Ми, певно, вже всі знаємо, що слід надавати перевагу композиції (деревам) а не спадкуванню (нашаруванням). Саме тому концепції шарів слід уникати.
Залишити відповідь