oop - мавен - Два объекта с зависимостями друг от друга. Это плохо?




идеальный мавен (3)

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

Кроме того, если это не так по соображениям производительности (например, у вас будет огромное количество комнат), вероятно, было бы более чистым сделать недвижимость или геттер, который будет перебирать комнаты и собирать людей, а не кэшировать их в отеле.

Я многому учусь о шаблонах дизайна, когда я строю свою собственную систему для своих проектов. И я хочу спросить вас о вопросе дизайна, на который я не могу найти ответ.

В настоящее время я создаю небольшой Chat-сервер, используя сокеты, с несколькими клиентами. Сейчас у меня есть три класса:

  1. Person-class, который содержит информацию как ник, возраст и объект Room.
  2. Room-class, который содержит информацию, такую ​​как имя комнаты, тему и список лиц, которые сейчас находятся в этой комнате.
  3. Отель-класс, который имеет список лиц и список номеров на сервере.

Я сделал диаграмму, чтобы проиллюстрировать ее:

У меня есть список людей на сервере в отеле-классе, потому что было бы неплохо отслеживать, сколько сейчас есть онлайн (без необходимости проходить через все комнаты). Люди живут в отеле-классе, потому что я хотел бы иметь возможность искать конкретного человека, не ища номера.

Это плохой дизайн? Есть ли другой способ добиться этого?

Благодарю.


Взаимная зависимость не плоха сама по себе. Иногда это требует использование данных.

Я думаю об этом по-другому. Будет проще поддерживать код, в котором меньше отношений вообще - взаимная зависимость или нет. Просто держите его как можно проще. Единственной дополнительной сложностью в вашей ситуации иногда является проблема с проверкой и яйцом во время создания и удаления последовательностей. У вас больше ссылок на бухгалтерию.

Если вы спрашиваете, нужен ли вам список людей в отеле в этом случае, я думаю, что есть два ответа. Я бы начал с того, что ваши объекты (в памяти) обеспечивали эти отношения, но вам не нужна дополнительная таблица соединений между людьми и гостиницами в базе данных. Если вы используете Hibernate, он автоматически генерирует эффективное соединение для вас, если вы попросите его для людей в отеле (он присоединится к отелям на номера.hotel_id для вас).


Строго говоря, проблема взаимной зависимости между классами может быть решена с помощью интерфейсов (абстрактных классов, если ваш язык, например, C ++ или Python) IRoom и IPerson ; в псевдокоде

interface IPerson
    IRoom getRoom()
    // etc

interface IRoom
    iter<IPerson> iterPerson()
    // etc

это делает только интерфейсы взаимозависимыми друг от друга - фактические реализации интерфейсов должны зависеть только от интерфейсов.

Это также дает вам много возможностей с точки зрения реализации, если вы хотите избежать циклических эталонных циклов (что может быть опасным, например, в CPython путем замедления сбора мусора) - вы можете использовать слабые ссылки, базовую реляционную базу данных с типичной " от одного до многих отношений "и т. д. и т. д. И для первого простого прототипа вы можете использовать то, что проще на выбранном вами языке (возможно, просто и, увы, обязательно круговое, ссылки [[указатели, на C ++]] с Person ссылающимся на Room и Room в list<Person> ).





dependency-management