Які недоліки у відображенні інтегральних ідентифікаторів для перерахунків?

Я думав над створенням власних типів для таких ідентифікаторів:

public enum CustomerId : int { /* intentionally empty */ }
public enum OrderId : int { }
public enum ProductId : int { }

Моя основна мотивація цього - запобігати помилку, коли ви випадково передаєте orderItemId функції, яка очікувала orderItemDetailId.

Здається, що ентузіасти безперебійно працюють із усім, що я хотів би використовувати в типовому веб-додатку .NET:

• Маршрутизація MVC працює чудово
• Серіалізація JSON працює чудово
• Кожна ОРМ, яку я думаю, працює чудово

Тож зараз мені цікаво: "чому я не повинен цього робити?" Це єдині недоліки, про які я можу придумати:

• Це може заплутати інших розробників
• Це вводить невідповідність у вашій системі, якщо у вас є нецілісні ідентифікатори.
• Може знадобитися додаткове лиття, наприклад (CustomerId)42. Але я не думаю, що це буде проблемою, оскільки маршрутизація ORM та MVC зазвичай передає вам значення типу enum безпосередньо.

Отже, моє запитання: що я пропускаю? Це, мабуть, погана ідея, але чому?

Чудова ідея створити тип для кожного виду ідентифікаторів, головним чином, із зазначених вами причин. Я б цього не зробив, реалізуючи тип як enum, оскільки створення правильної структури або класу дає вам більше варіантів:

• Ви можете додати неявну конверсію до int. Якщо ви подумаєте про це, то інший напрям, int -> CustomerId, той проблемний, який заслуговує явного підтвердження від споживача.
• Ви можете додати ділові правила, які визначають, які ідентифікатори є прийнятними, а які - ні. Йдеться не лише про слабку перевірку того, чи є позитивний int: іноді список усіх можливих ідентифікаторів зберігається в базі даних, але змінюється лише під час розгортання. Тоді ви можете легко перевірити, чи вказаний ідентифікатор існує проти кешованого результату відповідного запиту. Таким чином, ви можете гарантувати, що ваша програма швидко вийде з ладу за наявності недійсних даних.
• Методи на ідентифікаторі можуть допомогти вам зробити дорогі перевірки існування БД або отримати відповідний об'єкт / домен.

Про реалізацію цього можна прочитати у статті Функціональний C #: Первісна одержимість .

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

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

З мого POV ідея гарна. Намір надати різні типи непов'язаним класам ідентифікаторів і в іншому випадку виразити семантику за допомогою типів і дозволити компілятору перевірити це, є хорошим.

Я не знаю, як це працює в .NET-продуктивності, наприклад, значення перерахувань обов'язково поля. Код OTOH, який працює з базою даних, швидше за все, пов'язаний з I / O, і ідентифікатори в коробці не будуть вузьким місцем.

У досконалому світі ідентифікатори були б незмінними і порівнянними лише за рівність; Фактичні байти - це деталь реалізації. Непов’язані ідентифікатори мали б несумісні типи, тому ви не могли помилково використовувати один для іншого. Ваше рішення практично відповідає рахунку.

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

Якщо ви робите, ви б не вирішили своєї основної мети запобігти випадковому призначенню ідентифікатора типу A ідентифікатору типу B Тож перерахунки не корисні для вашої мети.

Це викликає питання, хоча якщо було б корисно створити типи для ідентифікатора клієнта, ідентифікатора замовлення та ідентифікатора продукту, походячи з Int32 (або Guid). Я можу придумати причини, через які це було б неправильно.

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

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