Conception orientée objet, définir relation

Question

Je suis vraiment confus au sujet de OOD lors de la conception de système relativement important. Toujours, nous parlons de has-une relation entre deux entités. Ma question concerne l'un qui possède l'autre?

1. Lors de la conception d'un parking, il y a beaucoup d'espace de stationnement. Si la voiture a un champ de données appelé espace de stationnement, ou si l'espace de stationnement doit tenir la voiture? ou les deux? Dans un système de réservation de bibliothèque, je suppose qu'il existe une bibliothèque de classes, un livre de classe et un utilisateur de classe. L'utilisateur doit-il passer la commande (livre), ou passer la commande d'achat de livre (utilisateur), ou passer la commande de bibliothèque (livre, utilisateur)?

Cela a été très déroutant pour moi. Tout commentaire/suggestion est le bienvenu.

Lily

Answer 1

Cela dépend de la situation et de ce que vous entendez par "propre".

Dans votre premier exemple, il existe une relation un-un entre une voiture et un espace de stationnement. Du point de vue de la base de données, vous devrez faire un jugement sur qui devrait «posséder» l'autre (quelle table «possède» la clé étrangère). Vous feriez ce jugement sur l'utilisation prévue - par exemple - puisqu'un parking est susceptible de rester fixe, mais vous avez des voitures qui vont et viennent tout le temps, il pourrait être plus logique que le parking "possède" la voiture. C'est là que vos compétences de conception entrent en jeu. Dans le second exemple, il me semble qu'un seul livre ne peut être extrait que par un utilisateur à la fois, et «check out» est une action qui se produit sur un livre. Par conséquent, la solution correcte est Book.checkout(user). Construire sur ce point, un utilisateur est susceptible de vérifier plus d'un livre à la fois, donc je serais enclin à avoir une méthode de caisse sur la bibliothèque, de sorte que Library.checkout(Books[], user) appelé Book.checkout(user) à son tour.

Answer 2

Pour # 1, l'espace de stationnement doit tenir un registre de si elle est occupée et si oui, quelle voiture est en elle. Sinon, pour voir si vous pouvez vous garer quelque part, vous devrez interroger chaque voiture pour voir si elles sont à cet endroit.

Ma pensée immédiate pour le n ° 2 est qu'il devrait être Library.checkout(Book, User) de sorte que vous notiez qu'un utilisateur a extrait un livre spécifique. Cela dépend fortement de ce que vous essayez de faire, et vous devriez le concevoir de manière à ce qu'il soit le plus facile possible pour le problème en question. Parfois, la réplication des données à deux endroits n'est pas une mauvaise idée tant que vous le gardez synchronisé. Par exemple, si vous avez besoin de savoir où une voiture spécifique est garée, vous finirez par vouloir garder une trace de ces données dans la classe Car, sinon vous devrez interroger chaque place de stationnement pour savoir si cette voiture est garée là.

Answer 3

Dans la conception orientée objet, l'objet peut être considéré comme une entité. À ce stade, vous pouvez utiliser la modélisation de la relation Entité pour mieux comprendre qui doit posséder quoi. Lorsque vous concevez votre modèle, vous ne devriez pas vous soucier de la façon dont vous allez l'implémenter. Je veux dire que vous ne devriez pas penser à qui va posséder quoi parce que c'est un autre processus de la conception qui est quand vous allez convertir votre modèle en objets (cela peut être une table de données, XML, objet C#, ....): seulement à ce point contre la relation que l'entité a eu, vous pouvez décider qui doit posséder quoi (parfois même contre les exigences que je vous montrerai plus tard). Lors de la conception, vous devez vous concentrer uniquement sur vos besoins. Dans le cas de la voiture et du parking, vous devriez penser à:

Combien de voitures de parc on peut occuper?

Combien de voitures un parc peut-il accueillir?

À quel type de réponse mon système répond-il? EX: en tant qu'utilisateur je veux savoir où une voiture est garée contre son numéro de plaque d'immatriculation (dans ce cas, la réponse précédente serait fausse car si vous laissez le parc posséder la voiture, vous devriez parcourir le parc pour trouver la voiture)

Comme vous pouvez le voir, cela dépend vraiment de vos besoins professionnels, en particulier lorsque vous avez une relation "one-to-one" (comme dans ce cas). Donc, je peux vous suggérer de jeter un oeil à "Entity relation Modeling" et de s'en tenir à son concept pour mieux concevoir votre modèle d'objet.

Answer 4

1. Dans ce cas, sans aucun doute l'espace de stationnement doit tenir une voiture (il est appelé agrégation), parce que la relation entre l'espace voiture et un parking est pas permanent (différentes voitures peuvent être garées au même endroit de stationnement dans le même jour Dans ce cas, je pense, l'utilisateur veut obtenir un livre, donc l'interface graphique de ce système doit avoir un bouton (ou autre) que l'utilisateur doit cliquer pour réserver un livre. Ainsi, l'utilisateur appelle une méthode checkout(book) du système (objet Bibliothèque le représente) pour vérifier si le livre est libre (ou disponible). Ensuite, le système (Bibliothèque) vérifie si le livre n'a pas été réservé auparavant par un autre utilisateur, il appelle donc la méthode Book.check() pour toutes les instances de ce livre. Dans une telle solution chaque compte d'utilisateur dans le système devrait avoir une liste de livres réservés que la méthode utilise Book.check().

Answer 5

Penser hors de la boîte, je ne pense pas que les exemples que vous avez fourni un naturel « a un » ou « possède une » relation, et il y a plus de relations que « a un » ou « propriétaire d'un ". À mon avis, je voudrais utiliser une relation faiblement couplée pour vos exemples, dans la perspective de la mise en œuvre, j'utiliserais une carte pour décrire et maintenir cette relation, ce qui signifie, pour un parking et une voiture, je mettrais une carte dans la classe Parking, et mappez ses emplacements aux voitures, si nous trouvons un emplacement existant sur la carte, nous savons que la fente est occupée, sinon, c'est une fente libre, pour moi, ça n'a pas beaucoup de sens non plus de dire voiture possède la fente ou la fente possède la voiture; pour l'exemple de la bibliothèque, la même chose, le livre et son emprunteur sont dans une relation très lâche, je mettrais une carte dans la classe de la bibliothèque, et mapper le livre à son emprunteur. Et qui est le gars fait vraiment l'action de caisse? c'est soit le personnel de la bibliothèque ou la machine automatique ou simplement la bibliothèque, donc nous pouvons avoir une bibliothèque.checkout (utilisateur, livres), et à l'intérieur de la méthode, mettre des livres et des utilisateurs dans la carte.

Pour le bonus, qu'est-ce qu'un scénario relationnel "a un"? pas un homme a une voiture, ce n'est pas vraiment un "a un", même nous avons "a un" dans la phrase (ne laissez pas le langage humain vous tromper), cela signifie simplement, à l'intérieur de la classe de la voiture, il y a un champ String appelé ownerName ou ownerId, c'est tout. Un exemple pour un vrai scénario de relation «a un» est que l'homme a un cœur ou une voiture a un moteur, ce qui signifie que dans l'implémentation, il y a vraiment un champ de classe Coeur à l'intérieur de la classe humaine.

Comme c'est beau le design orienté objet!