Что является хорошим способом представить отношения многих ко многим между двумя классами?

Допустим, у меня есть два типа объектов, A и B. Отношения между ними многие-ко-многим, но ни один из них не является владельцем другого.

И экземпляры A и B должны знать о соединении; это не только один путь.

Итак, мы можем сделать это:

class A
{
    ...

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

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

У меня вопрос: куда мне поместить функции для создания и уничтожения соединений?

Должно ли это быть A :: Attach (B), которое затем обновляет векторы A :: Bs и B :: As?

Или это должно быть B :: Attach (A), что кажется одинаково разумным.

Ни один из тех, кто чувствует себя хорошо. Если я перестану работать с кодом и вернусь через неделю, я уверен, что не смогу вспомнить, нужно ли мне делать A.Attach (B) или B.Attach (A).

Возможно, это должна быть такая функция:

CreateConnection(A, B);

Но создание глобальной функции также нежелательно, учитывая, что эта функция предназначена специально для работы только с классами A и B.

Другой вопрос: если я часто сталкиваюсь с этой проблемой / требованием, могу ли я как-то найти общее решение? Возможно, класс TwoWayConnection, который я могу извлечь или использовать в классах, которые разделяют этот тип отношений?

Каковы некоторые хорошие способы справиться с этой ситуацией ... Я знаю, как справиться с ситуацией «один-ко-многим» владеет D), но этот хитрее.

Изменить: просто чтобы сделать его более явным, этот вопрос не включает в себя вопросы собственности. И A, и B принадлежат некоторому другому объекту Z, а Z решает все вопросы, связанные с владением. Меня интересует только то, как создать / удалить связи «многие ко многим» между А и В.

Одним из способов является добавление открытого Attach()метода, а также защищенного AttachWithoutReciprocating()метода для каждого класса. Заведите Aи Bобщих друзей, чтобы их Attach()методы могли вызывать другие AttachWithoutReciprocating():

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

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

Если вы реализуете подобные методы для Bвас, вам не нужно будет помнить, какой класс вызывать Attach().

Я уверен, что вы могли бы обернуть это поведение в MutuallyAttachableклассе, который унаследован Aи Bунаследован, что позволит вам избежать повторения и набирать бонусные очки в Судный день. Но даже простой подход «реализуй это в обоих местах» сделает работу.

Возможно ли, чтобы сами отношения имели дополнительные свойства?

Если так, то это должен быть отдельный класс.

Если нет, то будет достаточно любого механизма управления списком возвратно-поступательного движения.

Обычно, когда я попадаю в такие ситуации, которые чувствуют себя неловко, но я не могу точно сказать, почему, потому что я пытаюсь положить что-то не в тот класс. Почти всегда есть способ вывести некоторую функциональность из класса Aи Bпрояснить ситуацию.

Одним из кандидатов на перемещение ассоциации является код, который создает ассоциацию в первую очередь. Может быть, вместо того, чтобы звонить, attach()он просто хранит список std::pair<A, B>. Если есть несколько мест, создающих ассоциации, его можно абстрагировать в один класс.

Другим кандидатом на перемещение является объект, которому принадлежат связанные объекты, Zв вашем случае.

Другим распространенным кандидатом на перенос ассоциации является код, который часто вызывает методы Aили Bобъекты. Например, вместо вызова a->foo(), который внутренне что-то делает со всеми связанными Bобъектами, он уже знает ассоциации и вызывает a->foo(b)для каждого. Опять же, если его называют несколько мест, его можно абстрагировать в один класс.

Много раз объекты, которые создают, владеют и используют ассоциацию, оказываются одним и тем же объектом. Это может сделать рефакторинг очень простым.

Последний метод заключается в получении отношения от других отношений. Например, братья и сестры являются отношениями «многие ко многим», но вместо того, чтобы хранить список сестер в классе братьев и наоборот, вы выводите эти отношения из родительских отношений. Другое преимущество этого метода заключается в том, что он создает единый источник правды. Нет никакого возможного способа для ошибки или ошибки времени выполнения создать несоответствие между списками брата, сестры и родителя, потому что у вас есть только один список.

Этот вид рефакторинга не волшебная формула, которая работает каждый раз. Вы все еще должны экспериментировать, пока не найдете подходящую для каждого отдельного обстоятельства, но я обнаружил, что это работает примерно в 95% случаев. В оставшиеся времена вам просто нужно жить с неловкостью.

Если бы я реализовывал это, я бы поместил Attach как в A, так и в B. Внутри метода Attach я бы вызвал Attach для переданного объекта. Таким образом, вы можете вызвать либо A.Attach (B), либо B.Attach ( А). Мой синтаксис может быть неправильным, я не использовал c ++ годами:

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);
    }
  }    
}

Альтернативным методом было бы создание 3-го класса, C, который управляет статическим списком пар AB.