Як уникнути дублювання структур даних, коли частини програми написані різними мовами?

Наприклад, скажіть, що ви пишете додаток на Java .

Ваш додаток спілкується з сервером API, написаним на Python .

Сервер Python спілкується з базою даних SQL .

У вас також є веб-сайт для вашої програми, написаний на JavaScript .

З 4 різними мовами легко в кінцевому підсумку повторювати по суті однакові структури даних у 4 різні часи.

Наприклад, Userтип може виглядати приблизно так (псевдокод):

type User {
  integer id;
  string name;
  timestamp birthday;
}

Кожна частина проекту потребує певного представлення User. Частини Java та Python потребують двох різних classдекларацій. Базі даних потрібна Userдекларація таблиці. І передній сайт також повинен був представляти собою User.

Повторення цього типу 4 різних разів дійсно порушує принцип " Не повторюйся" . Також існує проблема, що якщо Userтип буде змінено, то ці зміни потрібно повторити в кожній іншій частині проекту.

Я знаю, що бібліотека протобуфів Google пропонує своєрідне рішення цієї проблеми, в якій ви пишете структуру даних за допомогою спеціального синтаксису, а потім бібліотека створює для вас декларацію структури в декількох різних мовах програмування. Але це все ще не стосується питання про необхідність повторення логіки перевірки для ваших типів.

Хтось має якісь пропозиції або посилання на книги / публікації в блозі з цього приводу?

design-patterns object-oriented-design code-reuse

— Нормангорман
джерело

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

— Павло

Можна спільно використовувати однакові структури даних, якщо на задньому та передньому кінці використовується одна і та ж мова. Ви не повторюєте себе, якщо використовуєте різні бази коду. Використовуйте інструменти для генерації класів із схем xml або рядків Json з різних платформ розробників.

— Джон Рейнор

Repeating this type 4 different times really breaks the Don't-Repeat-Yourself principle. Ні, це не так. У вас є 4 різні системи, які роблять різні речі. Ви забираєте ДУХУ занадто далеко. На мій досвід, тип повторного використання, який ви хочете зробити, - це насіння зла, тому що запроваджуйте жорстке сполучення. Це навіть гірше, ніж повторити User4 рази на 4 різних мовах. У розподілених середовищах проблема з'єднання є проблемою. СУХИЙ - ні.

— Лаїв

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

— Даніель Жур

Відповіді:

Ви не. Або справді, не слід.

Якщо ви вважаєте додаток, ваш сервер та веб-сайт окремими контекстами, то має сенс дублювати структури. Причини, чому це може бути хорошою справою:

Структури схожі, але не однакові. Навіть якщо 90% структури однакове у всіх контекстах. Це 10%, які доставлять вам великі головні болі.
Шаблони та реалізації можуть бути різними. Коли використовуються різні мови та рамки, стає занадто важким мати однакову реалізацію для всіх
Спільні структури стають залежністю, якою потрібно керувати. Спільна залежність значно ускладнює розвиток, оскільки великі зміни в одному контексті є безглуздими в іншому. Потрібно багато зусиль для координації розвитку цієї спільної залежності
У різних контекстах є різні розгортання. Навіть якщо вам вдасться поділити однакові структури даних та один і той самий код перевірки у всіх контекстах, все одно може статися так, що нова версія одного контексту розгорнута, тоді як інші перебувають на старій версії, тому ситуації, де є десинхронізація у версіях, все одно потрібно вирішувати

Незважаючи на те, що принцип DRY є дивовижним, я думаю, що обмін структурами даних у контекстах або шарах створює більше проблем, ніж вирішує. Особливо, якщо проект зростає досить великим, що різні люди працюють у різних контекстах.

— Ейфорія
джерело

Я думаю, що @Euphoric перерахував кілька вагомих причин не дублювати код. Однак, якщо це потрібно зробити, я б рекомендував використовувати генерацію коду.

Знайдіть канонічну форму даних

Для цього потрібно спочатку розкрити, що є канонічною формою даних. Це ваша схема SQL чи класи у вашій програмі Java?

Вивести (автоматично) інші форми з нього

Після цього придумайте спосіб генерувати всі інші форми з канонічної. Наприклад, якщо припустити, що ваша канонічна форма є схемою SQL, ви можете легко генерувати код JavaScript, Java та Python (SQL легко розбирається і є хорошим кандидатом для канонічного джерела).

Розмістити відмінності

Потрібно легко позначити розділи згенерованого коду як "не чіпати" - таким чином ви повинні розмістити необхідні відмінності між усіма різними представленнями (наприклад: спеціальний код, який ви написали для свого JS frontend та Java backkend), що необхідно зберегти через регенерації.
Візьміть приклад з Git; коли він відкриває редактор, щоб дозволити вам ввести повідомлення про фіксацію, файл вже містить текст, але він має # -------- >8 --------маркер, щоб знати, де закінчується ваш вміст і де починається його автоматично створений текст.

Все-таки, якщо можете - уникайте такого дублювання. Це PITA, навіть якщо більшість вашого коду генерується автоматично.

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

— Mael
джерело