Чи повинен об’єкт знати свій ідентифікатор?

22

obj.idздається досить поширеним, а також, здається, потрапляє в коло того, що об’єкт міг знати про себе. Я можу запитати, чому мій об’єкт повинен знати свій ідентифікатор?

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

Я також одного разу зіткнувся з проблемою, коли я хотів серіалізувати об’єкт до JSON для RESTful API, де ідентифікатор, здається, не вкладався у корисну навантаження, але лише URI і включення його в об'єкт ускладнило це.

Чи повинен об’єкт знати, що це власний ідентифікатор? Чому або чому ні?

оновлення : Умови

id: Атрибут ідентифікатора на об'єкті. з точки зору бази даних, сурогатний ключ не є природним ключем.
Об'єкт: цілісний об'єкт або інший унікальний ідентифікаційний об'єкт в системі.

object-oriented object-oriented-design

— ксенотерацид
джерело

1

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

3

Якщо ви не знаєте унікальний ключ об’єкта, як би ви оновили дані в базі даних або дозволили користувачеві вибрати події зі списку?

— NoChance

@EmmadKareem, що я говорю, це те, що колекція (сховище) знає ідентифікатор, то чому для цього потрібен сам об’єкт. Якби я передавав список, я, мабуть, рендерував колекцію, яка знає ідентифікатори.

— ксенотерацид

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

— ГрандмайстерB

@GrandmasterB добре, звичайно, ви використовуєте ідентифікатор, питання полягає в тому, чи зберігаєте ви ідентифікатор в пам'яті разом з об'єктом і чому.

— ксенотерацид

8

Короткий відповідь: Включення ідентифікатора об'єкта в об'єкт є обов'язковим, якщо він буде переданий.

Для сценарію, коли ви плануєте використовувати колекцію об'єктів і плануєте посилатися на окремий об'єкт / сутність, тоді слід включати ідентифікатор. Однак можуть бути випадки, коли природний ключ / ідентифікатор, подібний, DateTimeможе штучно задовольнити цю потребу.

Крім того, ви можете мати ваш DTO як легкий контейнер вашого об'єкта, який може пропускати / включати в себе ідентифікатор об'єкта. Дійсно, всі ці варіанти дійсно залежать від випадків та потреб вашого бізнесу .

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

— Е. Л. Юсубов
джерело

2

чому вони повинні бути включені в об'єкт, а не просто у колекцію (якщо колекція є якимось словником)?

— ксенотерацид

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

— EL Yusubov

1

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

— ксенотеррацид

щоб трохи уточнити, я маю на увазі сурогатний ідентифікатор, зазвичай такі речі, як дати або номери вінів, є природними і, таким чином, є частиною даних, а не названими id(або, принаймні, не хотів би)

— xenoterracide

6

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

Об'єкт повинен знати власний ідентифікатор, якщо це потрібно.

Об'єкт не повинен знати свій ідентифікатор (або що у нього навіть є), якщо цього не потрібно.

Як ви вказали, є випадки, коли об’єкт або незручно або непотрібно зберігати або знати, чи є його ідентифікатор. Але є й інші випадки, коли об’єкту зручніше знати його ідентифікатор. Кодуйте свої об'єкти відповідно до їх використання.

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

— ксенотеррацид

1

@xenoterracide - асинхронний перегляд та оновлення записів БД - один із прикладів. У деяких випадках у мене не буде достатньої інформації, щоб однозначно ідентифікувати запис, крім його ідентифікатора, тому має сенс зберігати ідентифікатор разом із об'єктом запису.

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

— ксенотерацид

@xenoterracide - у тих випадках, про які я думаю, це безумовно була причинною потребою. У деяких випадках, в яких я був, було набагато зручніше зберігати ідентифікатор, пов’язаний з об'єктом. Ваше запитання було гарним, оскільки воно кинуло виклик базовим припущенням, що стосуються багатьох людей. Ми схильні вчитися, коли ми копаємося в таких припущеннях. З іншого боку, не перестарайтеся аналізувати та йдіть у зворотному напрямку. Інакше ви в кінцевому підсумку зробите той самий час священних декларацій, які ви ламали в першу чергу.

4

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

Наприклад, якщо ви створюєте API двома методами:

http://api.example.com/products/

Завантажує список ідентифікаторів продуктів.
http://api.example.com/product/452/

Завантажує товар з ідентифікатором 452.

Тоді вам не потрібно повторно відправляти ідентифікатор 452 у відповіді JSON на другий запит. Користувач API вже знає ідентифікатор.

— Арсеній Муренко
джерело

4

Я думаю, що це суб’єктивно і залежить від вашого дизайну.

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

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

Візьмемо для прикладу Personпредмет. Мені дають ім’я, яке може бути або не бути унікальним у сім'ї. Оскільки кількість населення зростає, імена більше не є унікальними, і тому ми придумали сурогатні ідентифікатори для все більш масштабної системи. Приклади цього включають: моє водійське посвідчення та номер соціального страхування. Мені не народжується присвоєний ідентифікатор, всі ці ідентифікатори повинні бути подані на заявку.

Більшість із них не мають гарних первинних ключів / ідентифікаторів для програмного забезпечення, оскільки вони не є універсальними. Принаймні, не за межами їх конкретної системи, очевидно, що SSN є унікальним та послідовним для Адміністрації соціального захисту. Оскільки ми, як правило, не є постачальниками цієї інформації, ви б не називали їх, idа скоріше даними, які вони представляють, наприклад SSN. Іноді навіть містяться повністю складені об'єкти, такі як, DriversLicenseякий може містити всю інформацію, яку має водійське посвідчення.

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

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

У програмному забезпеченні, якщо вам потрібно представити об'єкт як список або зберегти його, ви можете просто зробити це з об'єкту сховища / колекції або іншого об'єкта, пов'язаного з цим. Переходячи до Data Mapper (якщо він окремий), ви можете просто пройти .update( id, obj ).

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

— ксенотерацид
джерело

2

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

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

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

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

— scrwtp
джерело

2

Ви маєте рацію, вам не потрібно зберігати ідентифікатор в об'єкті, доки його потрібно знати лише у контексті вашого сховища.

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

У цій ситуації у вас є два варіанти:

ввести новий аргумент функції 'id' у весь ланцюг функцій між контекстом сховища та функцією, де необхідний ідентифікатор
включити ідентифікатор в об’єкт

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

Ось чому я це роблю, коли це роблю.

— Пол Томан
джерело