Універсальний контейнер даних

В останні 5 років я, здебільшого, маю справу з додатками на базі Magento, в основу якої закладені ідеї максимальної гнучкості, розширюваності та адаптивності. Популярність Magento в e-commerce та кількість сторонніх модулів розширень до неї говорять про те, що ця платформа та реалізовані в ній ідеї радше успішні, ніж навпаки. В основу великої кількості об'єктів у Magento закладено концепцію універсального контейнера даних (Varien_Object у Magento 1 та MagentoFrameworkDataObject у Magento 2). Я знаходжу в подібних універсальних контейнерах певні паралелі з такими явищами, як

  • POJO (Java)
  • JSON
  • XPath
  • DOM
  • СУБД (реляційні та не дуже)
  • SPA (Single Page Applications)

ну і зрештою - з Гарвардської архітектурою ЕОМ, розробленої Говардом Ейкеном в 1930-х роках.

Що таке "універсальний контейнер даних"?

Це звичайний асоціативний масив, карта (map) у якому кожному ключу відповідають якісь дані, включаючи інші асоціативні масиви. Контейнер містить, таким чином, дерево даних з однією точкою входу та відсутністю замкнутих контурів (краще бажана умова). Щось типу:

У PHP з використанням magic-методів можна реалізувати те саме в такому вигляді:

Адресація в більш звичному вигляді (як шлях до файлу *nix):

Що маємо у результаті? Контейнер для перенесення будь-яких даних. Опис PHP розробником об'єктів, аналогічних POJO Java, зводиться до анотування їх акцесорів (get/set методів) у тому, щоб можна було використовувати автодоповнення в IDE. Можна все те ж саме робити через анотацію @property, це буде навіть трохи коротше (правда вимагатиме іншої реалізації DataObject, черезget, set), але мені зручніше осьтак:

"Навіщо нам весь цей тюнінг у зоопарку?"

Розширюваність

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

"Далекий космос"

Гнучка конвеєризація

Функції допускають завдання безлічі аргументів, але результат, як правило, повертається єдиний:

Якщо обмежити кількість вхідних аргументів у функцію-процесор одним єдиним аргументом (як і результат роботи функції):

У PHP конвеєр обробників міг би виглядати приблизно так:

Можна з набору подібних функцій-процесорів на описовому рівні будувати потік обробки даних:

і змінювати його в залежності від даних, що обробляються:

Даної техніки буде, як кажуть, "сто років на обід", але свою нішу вона має.

На мій погляд "Гарвардський підхід" містера Говарда Ейкена з поділу коду і даних може стати базою для достатньої кількості цікавих рішень у галузі розробки ПЗ. "Будемо шукати!" (С) С. С. Горбунков