"Використовуйте карту замість класу для представлення даних" -Річ Хікі

У цьому відео Річ Хікі , творець Clojure, він радить використовувати карту для представлення даних, а не використовувати клас для їх представлення, як це робиться на Java. Я не розумію, як це може бути краще, оскільки як користувач API може знати, що таке вхідні ключі, якщо вони просто представлені у вигляді карт.

Приклад :

PersonAPI {
    Person addPerson(Person obj);
    Map<String, Object> addPerson(Map<String, Object> personMap);
}

У другій функції, як користувач API може знати, які входи створюють людину?

Резюме Exagg'itive ^(TM)

Ви отримуєте кілька речей.

• Прототипне успадкування та клонування
• Динамічне додавання нових властивостей
• Співіснування об’єктів різних версій (рівня специфікації) одного класу.
  • Об'єкти, що належать до останніх версій (рівні специфікації), матимуть додаткові "необов'язкові" властивості.
• Огляд властивостей, старих і нових
• Вступ до правил перевірки (обговорюється нижче)

Є один фатальний недолік.

• Компілятор не перевіряє наявність неправильно написаних рядків для вас.
• Автоматичні інструменти рефакторингу не перейменують назви ключових властивостей для вас, якщо тільки ви не заплатите за вигадливі.

Річ у тому, що ви можете отримати самоаналіз, використовуючи, гм, самоаналіз. Ось що зазвичай буває:

• Увімкнути роздуми.
• Додайте у свій проект велику бібліотеку самоаналізу.
• Позначте різні методи та властивості об’єктів за допомогою атрибутів чи приміток.
• Нехай бібліотека самоаналізу робить магію.

Іншими словами, якщо вам ніколи не потрібно взаємодіяти з FP, вам не доведеться приймати поради Річ Хікі.

І останнє, але не найменше (ні найкрасивіше), хоча використання Stringключа властивості має найпростіший сенс, вам не доведеться використовувати Strings. Багато застарілих систем, включаючи Android ™, широко використовують цілі ідентифікатори через весь фреймворк для посилань на класи, властивості, ресурси тощо.

_{Android є торговою маркою Google Inc.}

Ви також можете зробити обидва світи щасливими.

Для світу Java реалізуйте геттери та сетери як завжди.

Для світу FP реалізуйте

• Object getPropertyByName(String name)
• void setPropertyByName(String name, Object value) throws IllegalPropertyChangeException
• List<String> getPropertyNames()
• Class<?> getPropertyValueClass(String name)

Всередині цієї функції так, некрасивий код, але є плагіни IDE, які заповнять це для вас, використовуючи ... е, розумний плагін, який читає ваш код.

Ява сторона Java буде такою ж ефективною, як і зазвичай. Вони ніколи не використовуватимуть цю потворну частину коду. Можливо, ви навіть захочете сховати його від Javadoc.

FP сторони світу можуть писати який завгодно "нехай" код, який вони хочуть, і вони, як правило, не кричать на вас про те, що код повільний.

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

Зокрема, серіалізація / десеріалізація часто вимагає подібної методики.

Просто деякі загальні думки щодо "карти як об'єкта".

1. Ви все ще повинні надати функцію для перевірки такої "карти як об'єкта". Різниця полягає в тому, що "карта як об'єкт" дозволяє отримати більш гнучкі (менш обмежувальні) критерії перевірки.
2. Ви можете легко додати поля додавання в "карту як об'єкт".
3. Щоб забезпечити специфікацію мінімальної вимоги дійсного об'єкта, вам потрібно буде:
   • Перелічіть набір мінімально необхідних клавіш, які очікуються на карті
   • Для кожного ключа, значення якого потрібно перевірити, надайте функцію перевірки значення
   • Якщо є правила перевірки, для яких потрібно перевірити кілька ключових значень, вкажіть це також.
   • Яка користь? Надання специфікації таким способом є інтроспективним: ви можете написати програму для запиту мінімально необхідного набору клавіш та отримання функції перевірки для кожної клавіші.
   • В OOP все це згортається в чорний ящик, на ім’я "інкапсуляція". Замість машиночитаної логіки перевірки абонент може лише зчитувати читану людиною "API документацію" (якщо, на щастя, вона існує).

Це відмінна розмова того, хто дійсно знає, про що говорить. Я рекомендую читачам переглянути всю справу. Це всього 36 хвилин.

Одним з його головних моментів є те, що простота відкриває можливості для змін згодом. Вибір класу для представлення Personнадає негайну перевагу створення статично перевіреного API, як ви вказали, але це пов'язано з витратами на обмеження можливостей або збільшення витрат на зміни та повторне використання.

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

Нижче наведено деякі зміни коду (одна або дві з них були згадані у бесіді), які потенційно простіші за допомогою списку карт порівняно зі списком Personоб’єктів:

• Надсилання особи на сервер REST. (Функція, створена для розміщення Mapпримітивів у форматі, що передається, може бути багаторазовим і може бути навіть надана в бібліотеці. Для Personвиконання тієї ж роботи об'єкту, ймовірно, знадобиться спеціальний код).
• Автоматично побудувати список людей із запиту реляційної бази даних. (Знову одна загальна та багаторазово використана функція).
• Автоматично генерувати форму для відображення та редагування людини.
• Використовуйте загальні функції для роботи з особовими даними, які вкрай неоднорідні, як студент проти співробітника.
• Отримайте список усіх осіб, які проживають у певному поштовому індексі.
• Використовуйте цей код, щоб отримати список усіх підприємств у певному поштовому індексі.
• Додайте людині специфічне поле, не зачіпаючи інших клієнтів.

Ми постійно вирішуємо подібні проблеми, маємо шаблони та інструменти для них, але рідко зупиняємось на думці, якби вибір більш простого, гнучкішого представлення даних на початку полегшив би нашу роботу.

• Якщо дані мають незначну поведінку або взагалі відсутні, з гнучким вмістом, який може змінитися, скористайтеся картою. IMO, типовий "явабейський" або "об'єкт даних", який складається з анемічної моделі домену з N полями, N сеттерами і N Getters, - це марна трата часу. Не намагайтесь вразити інших своєю прославленою структурою, загорнувши її у клас фантазії. Будьте чесні, уточнюйте свої наміри та використовуйте Карту. (Або, якщо це має сенс для вашого домену, об'єкта JSON або XML)

• Якщо дані мають істотну фактичну поведінку, наприклад методи ( Tell, Don't Ask ), тоді використовуйте клас. І погладьте себе по спині за використання справжнього об'єктно-орієнтованого програмування :-).

• Якщо дані мають велику кількість важливої поведінки перевірки та обов'язкові поля, використовуйте клас.

• Якщо дані мають помірну кількість поведінки перевірки, це є межею.

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

• Основним недоліком використання Map є те, що користувач повинен передати значення Strings, ints, Foos тощо. Якщо це сильно дратує і схильне до помилок, розгляньте клас. Або розгляньте клас помічників, який обертає Карта відповідними дітьми.

API для a mapмає два рівні.

1. API для карт.
2. Конвенції програми.

API може бути описано на карті за умовами. Наприклад, пара :api api-validateможе бути розміщена на карті або :api-foo validate-fooможе бути умовою. На карті можна навіть зберігати api api-documentation-link.

Використання конвенцій дозволяє програмісту створити специфічну для домену мову, яка стандартизує доступ до всіх типів, реалізованих у вигляді карт. Використання (keys map)дозволяє визначати властивості під час виконання.

Немає нічого магічного в картах і немає нічого магічного в об’єктах. Це все відправлення.