Un objet doit-il connaître son propre ID?

22

obj.idsemble assez commun et semble également se situer dans la portée de quelque chose qu'un objet pourrait savoir sur lui-même. Je me demande pourquoi mon objet devrait-il connaître son propre identifiant?

Il ne semble pas avoir de raison de l'avoir? L'une des principales raisons de son existence est de le récupérer, et donc mes référentiels doivent le connaître, et donc l'utiliser pour l'interaction de la base de données.

J'ai également rencontré un problème où je voulais sérialiser un objet en JSON pour une API RESTful où l'ID ne semblait pas tenir dans la charge utile, mais seulement l'URI et l'inclure dans l'objet rendait cela plus difficile.

Un objet doit-il savoir son propre identifiant? pourquoi ou pourquoi pas?

mise à jour : Termes

  1. id: attribut identifiant sur un objet. en termes de base de données, une clé de substitution n'est pas une clé naturelle.
  2. Objet: une entité, ou autre objet identifiable de manière unique au sein du système.
object-oriented object-oriented-design xénoterracide
la source
1
Pour rester abstrait, s'il n'y a aucune raison de stocker des informations, ne les stockez pas. Cela crée juste des maux de tête.
3
Si vous ne connaissez pas la clé unique d'un objet, comment mettre à jour les données dans une base de données ou laisser l'utilisateur sélectionner une occurrence dans une liste?
NoChance
@EmmadKareem ce que je dis, c'est que la collection (référentiel) connaît l'identifiant, alors pourquoi l'objet lui-même en a-t-il besoin? Si je rendais une liste, je rendrais probablement la collection, qui connaît les identifiants.
xenoterracide
Si vous n'utilisez pas l'id stocké avec l'objet, et que vous n'avez jamais l'intention ou ne souhaitez pas l'utiliser, ce n'est clairement pas nécessaire.
GrandmasterB
@GrandmasterB bien sûr, vous utilisez l'identifiant, la question est de savoir si vous stockez l'identifiant en mémoire avec l'objet, et pourquoi.
xénoterracide

Réponses:

8

Réponse courte: l' inclusion d'un identifiant d'objet dans l'objet est indispensable s'il doit être référé.

Pour un scénario dans lequel vous prévoyez d'utiliser une collection d'objets et prévoyez de référencer un objet / entité individuel, l'identifiant doit être inclus. Cependant, il peut y avoir des cas où une clé / un identificateur naturel comme DateTimepeut répondre artificiellement à ce besoin.

De plus, vous pouvez avoir votre DTO en tant que conteneur léger de votre objet, qui peut ignorer / inclure l'identifiant d'objet en soi. Vraiment, tous ces choix dépendent vraiment des cas d'utilisation et des besoins de votre entreprise .

Modifier: si vous voulez identifier votre objet, vous devez avoir un identifiant. Cet identifiant peut être un identifiant de substitution, une date-heure, un guid, etc ... fondamentalement, tout ce qui identifie votre objet des autres de manière unique.

EL Yusubov
la source
2
pourquoi devraient-ils être inclus dans l'objet, plutôt que simplement dans la collection (en supposant que la collection est une sorte de dictionnaire)?
xenoterracide
mon point était que, si vous voulez identifier votre objet, vous devez avoir un identifiant. cela peut être Id, date-heure, etc ... tout ce qui identifie votre objet des autres.
EL Yusubov
1
bien sûr, ma question est plus de savoir pourquoi l'objet lui-même doit être au courant de cet identifiant.
xenoterracide
pour clarifier un peu, je veux dire un identifiant de substitution, généralement des choses comme les datetime ou les numéros de vin, sont naturelles et font donc partie des données, et ne sont pas nommées id(ou du moins je ne le ferais pas)
xenoterracide
6

Afin de laisser ma réponse aussi abstraite que votre question, je pense que vous avez en fait répondu à votre propre question.

Un objet doit connaître son propre ID s'il en a besoin.

Un objet ne devrait pas connaître son ID (ou qu'il en a même un) s'il n'en a pas besoin.

Comme vous l'avez souligné, il existe des cas où il est gênant ou inutile que l'objet conserve ou sache si son ID. Mais il existe d'autres cas où il est plus pratique pour l'objet de connaître son ID. Codez vos objets en fonction de leur utilisation.


la source
Dans quels cas est-il pratique pour lui de connaître son identifiant? Je l'ai réfléchi et j'ai pensé que la plupart d'entre eux pouvaient simplement être basés sur la façon dont il était codé, peut-être une boucle for utilisée pour le rendu obj.idpar opposition au rendu de la collection elle-même.
xenoterracide
1
@xenoterracide - la visualisation et la mise à jour asynchrones des enregistrements DB en sont un exemple. Dans certains cas, je n'aurai pas suffisamment d'informations pour identifier de façon unique un enregistrement, à l'exception de son ID, il est donc logique de conserver l'ID avec l'objet d'enregistrement.
mais est-ce une cause ou un effet? est-ce une exigence? si votre référentiel / collection / datamapper (ou une chaîne de celui-ci) est responsable de la persistance des mises à jour, et qu'il connaît l'identifiant et est capable de le transmettre ... J'essaie de comprendre s'il y a une raison pour qu'il le suive ou si il est là parce que beaucoup de gens utilisent un modèle d'enregistrement actif.
xenoterracide
@xenoterracide - dans les cas auxquels je pense, c'était définitivement un besoin causal. Pour certains cas dans lesquels j'ai été, il était beaucoup plus pratique de conserver l'ID associé à l'objet. Votre question était bonne car elle remettait en question une hypothèse de base que beaucoup de gens font. Nous avons tendance à apprendre quand nous creusons dans des hypothèses comme ça. D'un autre côté, ne pas trop analyser et aller dans la direction opposée. Sinon, vous finirez par faire en même temps des déclarations sacro-saintes que vous décomposiez en premier lieu.
4

Il est assez courant d'inclure l'ID, mais il est également courant d'utiliser des dictionnaires, c'est-à-dire les structures de données où chaque objet est associé à son ID de manière à ce que vous puissiez facilement récupérer cet objet en connaissant l'ID correspondant, mais l'objet ne sait pas il.

Par exemple, si vous créez une API avec deux méthodes:

Ensuite, vous n'avez pas besoin de renvoyer l'ID 452 dans la réponse JSON de la deuxième demande. L'utilisateur de l'API connaît déjà l'ID.

Arseni Mourzenko
la source
4

Je pense que cela est subjectif et dépend de votre conception.

Surtout si cela semble être une conception qui provient d'un enregistrement actif . Dans un enregistrement actif, votre entité dispose de méthodes pour effectuer des opérations de base de données et doit donc également connaître son identifiant de base de données.

Lorsque vous utilisez d'autres modèles tels qu'un référentiel avec un mappeur de données stockant ces données dans l'objet, cela devient inutile et peut-être inapproprié.

Prenons par exemple un Personobjet. On me donne un nom qui peut ou non être unique au sein d'une famille. Comme la population a grandi, les noms plus grands ne sont plus uniques et nous avons donc trouvé des identifiants de substitution pour un système de plus en plus grand. Par exemple: mon permis de conduire et mon numéro de sécurité sociale. Je ne suis pas né avec un identifiant, tous ces identifiants doivent être demandés.

La plupart d'entre eux ne font pas de bonnes clés primaires / identifiants pour les logiciels, car ils ne sont pas universels. Du moins pas en dehors de leur système spécifique, il est évident qu'un SSN est unique et cohérent avec la Social Security Administration. Puisque nous ne sommes généralement pas les fournisseurs de ces informations, vous ne les appelleriez pas idmais plutôt les données qu'ils représentent, par exemple SSN. Parfois, même contenir l'objet composé complet comme un DriversLicensequi pourrait contenir toutes les informations du permis de conduire.

Tous les identifiants généraux sont donc des clés de substitution dans le système et pourraient être remplacés par des références en mémoire, ne contenant que des identifiants pour faciliter la recherche et la persistance d'enregistrements.

Puisqu'une idn'est pas une donnée conceptuelle, je doute qu'elle fasse (généralement) partie de l'objet, car elle ne vient pas du domaine. Il devrait plutôt être conservé dans son but qui est d'identifier un objet qui n'a pas d'autre moyen de représenter une identité unique. Cela pourrait être fait dans un référentiel / collection avec easy.

Dans le logiciel, si vous devez représenter l'objet sous forme de liste, ou le conserver, vous pouvez simplement le faire à partir de l'objet de référentiel / collection, ou d'un autre objet associé à cela. Lorsque vous passez au Data Mapper (s'il est séparé), vous pouvez simplement passer .update( id, obj ).

Avis de non - responsabilité : je n'ai pas encore essayé de construire un système qui ne contient pas l'identifiant au sein de l'entité et peut donc me prouver le contraire.

xénoterracide
la source
2

Comme GlenH7 l'a noté dans un commentaire, c'est une bonne question, car elle remet en question ce que beaucoup de gens tiennent pour acquis. Mon point de vue, cependant, est que même si le fait d'omettre l'identifiant peut sembler conceptuellement pur, la chose pragmatique à faire serait de conserver l'identifiant avec l'objet sur autant de couches du système que possible. Cela coûte peu, mais peut être utile lorsque les choses commencent à s'effondrer.

Une entité peut ne pas avoir besoin de connaître son identifiant, tout comme une personne n'a pas besoin de connaître son numéro d'identification personnel, son numéro de permis de conduire ni aucun autre identifiant pouvant être utilisé dans votre région. Vous pourriez certainement vous en passer la plupart du temps. Il est cependant sage de porter une sorte d'identification sur vous, au cas où.

La même chose peut être dite d'un objet. Indépendamment des subtilités de la couche d'accès aux données, l'objet est finalement mappé à une certaine entrée de base de données. Cette entrée peut uniquement être identifiée de manière unique par l'ID de l'objet. Si tel est le cas, je préférerais avoir ces informations à ma disposition à tout moment, que je débogue du code d'interface utilisateur, que le nombre soit chiffré dans la couche métier, le référentiel lui-même ou un système dépendant sur un service Web. Ou si je consulte les journaux d'erreurs d'ailleurs.

Dans votre cas, si vous ne récupérez que les données de la base de données et les transmettez via le service Web, il peut être judicieux de ne pas l'identifier. Je ne pense tout simplement pas que cela ait plus de sens que de le garder dans le cas général.

scrwtp
la source
2

Vous avez raison, vous n'avez pas besoin de stocker l'identifiant dans l'objet, tant que vous n'avez besoin de le connaître que dans votre contexte de référentiel.

La situation change lorsque vous passez l'objet à du code en dehors de ce contexte, du code qui n'a pas demandé l'objet par id (et donc ne le sait pas encore), mais qui a besoin de l'id dans un but quelconque (par exemple, pour le placer sur une liste des identifiants qui seront demandés au référentiel ultérieurement, par encore un autre code).

Dans cette situation, vous avez deux options:

  • introduire un nouvel argument de fonction 'id' dans toute la chaîne de fonctions entre le contexte du référentiel et la fonction où l'id est nécessaire

  • inclure l'id dans l'objet

Dans la plupart de ces cas, le stockage de l'id à l'intérieur de l'objet sera la meilleure solution. Cela réduira également les changements de code lorsque l'ID est nécessaire dans des endroits imprévus, et il peut parfois être utile pour le débogage.

C'est pourquoi je le fais quand je le fais.

Paul Thomann
la source