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


12

Наприклад, скажіть, що ви пишете додаток на 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 пропонує своєрідне рішення цієї проблеми, в якій ви пишете структуру даних за допомогою спеціального синтаксису, а потім бібліотека створює для вас декларацію структури в декількох різних мовах програмування. Але це все ще не стосується питання про необхідність повторення логіки перевірки для ваших типів.

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


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

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

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

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

Відповіді:


12

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

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

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

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


5

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

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

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

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

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

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

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

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


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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.