Mappage vs composition

Question

Si j'ai deux classes avec une relation un-à-un, c'est le bon moment pour utiliser le mapping.

class A { ... } 
class B { ... } 
class C { 
    Map<A,B> a2b; 
} 

Et quand est-il temps d'utiliser la composition?

class A { 
    B myB; 
} 
class B { ... } 

La réponse changerait-elle si la relation était un-à-plusieurs et plusieurs-à-plusieurs?

Answer 1

Cela dépend de l'étendue de cette relation A à B utilisée tout au long du projet.

Si beaucoup de différentes zones du projet devront connaître le B associé à A, alors il est préférable que ce soit simplement une partie de l'objet A. D'autre part, si cette association n'est utilisée que dans une partie du projet, vous devez créer le HashMap dans cette partie du projet pour stocker la relation.

Cette réponse ne change pas s'il s'agit d'une relation un-à-plusieurs ou plusieurs-à-plusieurs.

Answer 2

L'utilisation d'un Map augmentera la complexité de l'ensemble.

Ceci parce que dans votre exemple une des deux classes (A) possède l'autre, cela est vrai, soit pour la composition (puisque vous avez besoin du A pour récupérer son B) soit pour la cartographie (depuis que vous avez besoin de la clé A pour la valeur B). Donc, s'il n'y a pas de besoin explicite d'utiliser une carte, évitez simplement cela. Pour les cas 1: N, M: N, vous devriez toujours considérer le type d'opérations que vous devrez effectuer sur les objets, car avoir un troisième objet qui gère juste le mappage entre les A et B n'est pas vraiment Solution OO, vous pouvez utiliser la composition. Un-à-plusieurs peut être modélisé avec List<B> à l'intérieur de A alors que plusieurs-à-plusieurs est le seul cas dans lequel un mappage peut être bon, sinon vous devrez explorer les deux objets pour comprendre leurs correspondances.

Peu de temps: si vous accéder aux données à partir d'un point de vue A (AB est propriétaire) alors vous n'avez pas besoin d'avoir une cartographie externe, sinon vous, mais il devrait être bidirectionnel (deux hashmaps).

Answer 3

La carte est bonne pour relations plusieurs-à-plusieurs (comme les tables jointes dans la conception de base de données). Tant que votre un-à-un ou relation un-à-plusieurs n'a pas besoin d'attributs spéciaux, il n'est pas nécessaire d'utiliser une troisième classe (cette troisième classe modéliserait la relation elle-même).

Faire une association, peut-être un bi-directionnel, si vous avez besoin regard des deux directions:

---

public class A { 
    private B b; 
    public A(B b){ 
    this.b = b; 
    b.setA(this); // for bi-directional association 
    } 
} 

---

public class B { 
    private A a; 
    public B(){}; 
    public void setA(A a) { 
    this.a=a; 
    } 
}