Qual è un buon modo per rappresentare una relazione molti-a-molti tra due classi?

Diciamo che ho due tipi di oggetti, A e B. Il rapporto tra loro è molti-a-molti, ma nessuno dei due è il proprietario dell'altro.

Entrambe le istanze A e B devono essere consapevoli della connessione; non è solo un modo.

Quindi, possiamo fare questo:

class A
{
    ...

    private: std::vector<B *> Bs;
}

class B
{
    private: std::vector<A *> As;
}

La mia domanda è: dove inserisco le funzioni per creare e distruggere le connessioni?

Dovrebbe essere A :: Attach (B), che quindi aggiorna A :: Bs e B :: Come vettori?

O dovrebbe essere B :: Attach (A), che sembra ugualmente ragionevole.

Nessuno di questi si sente bene. Se smetto di lavorare con il codice e torno dopo una settimana, sono sicuro che non sarò in grado di ricordare se dovrei fare A.Attach (B) o B.Attach (A).

Forse dovrebbe essere una funzione come questa:

CreateConnection(A, B);

Ma creare una funzione globale sembra anche indesiderabile, dato che è una funzione specifica per lavorare solo con le classi A e B.

Un'altra domanda: se incontro spesso questo problema / requisito, posso in qualche modo crearne una soluzione generale? Forse una classe TwoWayConnection da cui posso derivare o utilizzare all'interno di classi che condividono questo tipo di relazione?

Quali sono alcuni buoni modi per gestire questa situazione ... So come gestire abbastanza bene la situazione "C possiede D", ma questa è più complicata.

Modifica: solo per renderlo più esplicito, questa domanda non comporta problemi di proprietà. Sia A che B appartengono a qualche altro oggetto Z e Z si occupa di tutti i problemi di proprietà. Sono interessato solo a come creare / rimuovere i collegamenti molti-a-molti tra A e B.

Un modo è quello di aggiungere un Attach()metodo pubblico e anche un AttachWithoutReciprocating()metodo protetto a ogni classe. Fai amicizia Ae fai Bamicizia reciproca in modo che i loro Attach()metodi possano chiamare l'altro AttachWithoutReciprocating():

A::Attach(B &b) {
    Bs.push_back(&b);
    b.AttachWithoutReciprocating(*this);
}

A::AttachWithoutReciprocating(B &b) {
    Bs.push_back(&b);
}

Se si implementano metodi simili per B, non sarà necessario ricordare su quale classe chiamare Attach().

Sono sicuro che potresti avvolgere quel comportamento in una MutuallyAttachableclasse che eredita Ae sia B, evitando così di ripeterti e di segnare punti bonus nel Giorno del Giudizio. Ma anche l'approccio non sofisticato implementa in entrambi i posti farà il lavoro.

È possibile che la relazione stessa abbia proprietà aggiuntive?

In tal caso, dovrebbe essere una classe separata.

In caso contrario, sarà sufficiente qualsiasi meccanismo di gestione delle liste alternativo.

Di solito quando mi trovo in situazioni come queste che mi fanno sentire imbarazzante, ma non riesco proprio a capire perché, è perché sto cercando di mettere qualcosa nella classe sbagliata. C'è quasi sempre un modo per spostare alcune funzionalità fuori dalla classe Ae Bper rendere le cose più chiare.

Un candidato per spostare l'associazione è il codice che crea l'associazione in primo luogo. Forse invece di chiamarlo attach()semplicemente memorizza un elenco di std::pair<A, B>. Se ci sono più posizioni che creano associazioni, possono essere astratte in una classe.

Un altro candidato per una mossa è l'oggetto che possiede gli oggetti associati, Znel tuo caso.

Un altro candidato comune per lo spostamento dell'associazione è il codice che spesso chiama metodi Ao Boggetti. Ad esempio, invece di chiamare a->foo(), che internamente fa qualcosa con tutti gli Boggetti associati , conosce già le associazioni e chiama a->foo(b)per ognuna. Ancora una volta, se più posti lo chiamano, può essere astratto in una singola classe.

Molte volte gli oggetti che creano, possiedono e usano l'associazione capita di essere lo stesso oggetto. Ciò può rendere il refactoring molto semplice.

L'ultimo metodo è derivare la relazione da altre relazioni. Ad esempio, i fratelli e le sorelle sono una relazione molti-a-molti, ma piuttosto che tenere un elenco di sorelle nella classe dei fratelli e viceversa, si ricava quella relazione dalla relazione dei genitori. L'altro vantaggio di questo metodo è che crea un'unica fonte di verità. Non è possibile che un errore o un errore di runtime crei una discrepanza tra gli elenchi fratello, sorella e genitore, poiché hai un solo elenco.

Questo tipo di refactoring non è una formula magica che funziona ogni volta. Devi ancora sperimentare fino a quando non trovi una buona misura per ogni singola circostanza, ma ho scoperto che funziona circa il 95% delle volte. Le restanti volte devi solo convivere con l'imbarazzo.

Se lo stavo implementando, inserivo sia Attach in A che B. All'interno del metodo Attach, chiamerei Attach sull'oggetto passato. In questo modo puoi chiamare A.Attach (B) o B.Attach ( UN). La mia sintassi potrebbe non essere corretta, non uso c ++ da anni:

class A {
  private: std::vector<B *> Bs;

  void Attach (B* obj) {
    // Only add obj if it's not in the vector
    if (std::find(Bs.begin(), Bs.end(), obj) == Bs.end()) {
      //Add obj to the vector
      Bs.push_back(obj);

      // Attach this class to obj
      obj->Attach(this);
    }
  }    
}

class B {
  private: std::vector<A *> As;

  void Attach (A* obj) {
    // Only add obj if it's not in the vector
    if (std::find(As.begin(), As.end(), obj) == As.end()) {
      //Add obj to the vector
      As.push_back(obj);

      // Attach this class to obj
      obj->Attach(this);
    }
  }    
}

Un metodo alternativo sarebbe quello di creare una terza classe, C che gestisce un elenco statico di accoppiamenti AB.