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

Скажімо, у мене є два типи об’єктів, A і B. Взаємовідносини між ними багато-до-багатьох, але жоден з них не є власником іншого.

І A, і B випадки повинні знати про зв'язок; це не один спосіб.

Отже, ми можемо це зробити:

class A
{
    ...

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

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

Моє запитання: де я розміщую функції для створення та руйнування з'єднань?

Чи повинен бути A :: Attach (B), який потім оновлює A :: Bs і B :: Як вектори?

Або це має бути B :: Attach (A), що здається однаково розумним.

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

Можливо, це має бути така функція:

CreateConnection(A, B);

Але зробити глобальну функцію також здається небажаним, враховуючи, що це функція спеціально для роботи лише з класами A і B.

Інше питання: якщо я часто стикаюся з цією проблемою / вимогою, чи можу я якось прийняти загальне рішення? Можливо, клас TwoWayConnection, з якого я можу отримати або використовувати в межах класів, які поділяють цей тип відносин?

Які є хороші способи впоратися з цією ситуацією ... Я знаю, як виправити ситуацію "багато хто з" D "досить добре, але цей складний складніше.

Редагувати: щоб зробити це більш чітким, це питання не пов’язане з проблемами власності. І A, і B належать ще одному об'єкту Z, а Z опікується всіма питаннями власності. Мене цікавить тільки те, як створити / видалити зв’язки між багатьма та багатьма між A і B.

Один із способів - додати загальнодоступний 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-го класу, який керує статичним списком пар AB.