Чи має бути відомий бізнес-ідентифікатор суб'єкта господарювання представленим типом у DDD / OOP?

9

На практиці це означає використання користувацького (незмінного) classнад тим stringчи іншим примітивним типом.

Приклади:

Видавництво: Міжнародний стандартний номер книги.
Фінанси: Міжнародний ідентифікаційний номер цінних паперів.

Переваги:

Може забезпечити формат ідентифікатора.
Стає першокласним членом моделі.

Недоліки:

Додає стійке тертя (наприклад, Entity Framework).
Більше коду.

— Лігво
джерело

Чи варто використовувати спеціальний клас? Звичайно. Чи варто використовувати їх як ідентифікатори? Абсолютно ні :) Ідентифікатор з діловим значенням може викликати неприємності на цьому шляху.

— Сонго

2

@Songo Для мене це аргумент того, що ідентифікатори повинні мати значення семантики значень , але примітивні типи - це не єдині типи зі значеннями семантики, так що не обов'язково виключати класи imo. Не соромтеся публікувати конкуруючу відповідь, хоча я забув зробити це.

— Іксрек

1

Старе моє питання торкнулося цієї теми з різними думками: programer.stackexchange.com/questions/281827/… Я пішов із створенням типів і продовжую це робити.

— Ziv

6

Якщо ви можете надати класу достатньо корисної функціональності, щоб виправдати додану складність того, що це не рядок, тоді зробіть це. Підозрюю, що для таких ідентифікаторів, як ISBN та ISIN, це не так.

Щоб клас ідентифікатора був корисним, я очікую, що він виглядатиме приблизно так:

class ISIN {
    fromCUSIP()
    fromRawISINString()
    toString(ISIN::FormatType)
    getExchange()
    getCountryCode()
    getLastFourDigits()
    getWhateverCode()
    ...
}

Якщо натомість це виглядає більше так:

class ISIN {
    getString()
    setString()
}

Тоді я б повністю скинув клас, використовую регулярні рядки скрізь і переконуюсь, що я послідовно використовую "isin" у всіх відповідних назвах змінних.

Зауважте, що в деяких мовах додавання нового типу майже не має «додаткової складності» у типових програмах, і в цьому випадку вам буде запропоновано створити новий тип, навіть якщо він не мав би функціоналу взагалі. Але це не стосується більшості традиційних мов OOP, таких як C ++.

— Іксрек
джерело

6

Я б сказав, піти на це. Я б заперечував, що переваги переважають недоліки в цьому випадку. Додатковий код, ймовірно, буде досить мінімальним, і питання постійності можна вирішити досить легко, забезпечивши якийсь перетворювач між вашим новим класом і типом, який очікує база даних (я ніколи не використовував Entity Framework, але я знаю, що це відносно безболісно в Зимує).

Однією з переваг, яку можна отримати, визначивши свій власний клас, є те, що компілятор може гарантувати, що будь-які методи, які хочуть ISBN або ISIN, знають під час компіляції, якщо ви спробуєте передати неправильне значення. Також буде набагато важче випадково переписати це поле у вашій сутності. Ми можемо уникати таких поширених помилок:

book.setAuthor(otherBook.getAuthorName());
book.setIsbn(otherBook.getAuthorName());
book.setPrice(otherBook.getPrice())

Якщо ISBN - це клас, а не примітивний тип, то вищезгаданий код навіть не складеться, заощаджуючи багато часу на налагодження.

— Метт Уотсон
джерело

1

сетери та геттери? Це 1992 рік?

— Майлз Рут