Применение идентификаторов на моделях

Question

У меня есть два модельных объекта, которые имеют следующие отношения.

A {
 int id;
 List<B> bList;
}
B {
 int id;
 int idA; // references a particular object A with associated id
}

В классе A есть список объектов типа B. Проблема в том, что я не знаю, является ли хорошей практикой применение этих отношений. То есть убедитесь, что идентификатор B имеет идентификатор A. Прямо сейчас я рассматриваю вопрос о том, чтобы объект A возвратил объект-строитель, который будет создавать объекты B, для которых idA установлен на правильный идентификатор для текущего экземпляра. Является ли это хорошая практика или нет?

Edit: Я забыл некоторые детали. Я подумал об этом еще немного и понял, что это не единственная причина, по которой я могу использовать строителя. Объект B также имеет список объектов, который варьируется в зависимости от конкретного экземпляра A. Таким образом, каждый объект A по существу имеет свой объект B. Мое знание шаблонов проектирования, которое не так уж и много, подсказывает мне использовать шаблон компоновщика, о котором я говорил выше. Что вы, люди, думаете?

Answer 1

Я предпочитаю делать это на уровне БД, используя ограничения PK FK. Но если вы хотите, чтобы они были в вашем коде, самым близким структурным паттерном, на мой взгляд, является композитный паттерн. Я предлагаю сделать список доступных Объектов общего доступа A и другой подсписок для каждой ссылки A из B всякий раз, когда на него ссылается B, это позволяет легко уничтожать (удалять) ссылки из B всякий раз, когда A больше не существует. Кроме того, это гарантирует, что вы не добавляете A, который не существует, и поддерживаете согласованную и согласованную структуру.

 Public static List<Structure> mainList; // This must be updated whenever A created or instantiated by B

 Class Structure{
 Public A obj= new A();
 Public List<B> referencesOfA=new ArrayList<B>();
 }

  A {
  int id;
  List<B> bList;
  }
  B {
  int id;
  int idA; // references a particular object A with  associated id
   }

См: https://refactoring.guru/design-patterns/composite