Два объекта с зависимостями друг для друга. Это плохо?
Я узнаю много о шаблонах разработки, когда я создаю свою собственную систему для моих проектов. И я хочу спросить Вас о вопросе о дизайне, на который я не могу найти ответ.
В настоящее время я создаю немного сервера Чата с помощью сокетов с несколькими Клиентами. Прямо сейчас у меня есть три класса:
- Класс человека, который содержит информацию как зарубка, возраст и объект Помещения.
- Класс помещения, который содержит информацию как имя помещения, тема и список Людей в настоящее время в той комнате.
- Класс гостиницы, которые имеют список Людей и список Комнат на сервере.
Я сделал схему для иллюстрирования его: 
У меня есть список людей на сервере в Классе гостиницы, потому что было бы хорошо отслеживать то, скольких там онлайн прямо сейчас (Не имея необходимость выполнять итерации через все комнаты). Люди живут в Классе гостиницы, потому что я хотел бы смочь искать определенного Человека, не ища комнаты.
Этот плохой дизайн? Есть ли другой способ, достигают его?
Спасибо.
4 ответа
Проблема взаимной зависимости между классами, строго говоря, может быть решена с помощью интерфейсов (абстрактных классов, если ваш язык, например. C++ или Python) IRoom и IPerson; в псевдокоде
interface IPerson
IRoom getRoom()
// etc
interface IRoom
iter<IPerson> iterPerson()
// etc
это делает только интерфейсы взаимно зависимыми друг от друга - фактические реализации интерфейсов должны зависеть только от интерфейсов.
Это также дает большую свободу действий в плане реализации, если вы хотите избежать круговых циклов ссылок (которые могут быть неприятны, например, в CPython, замедляя сборку мусора) -- вы можете использовать слабые ссылки, базовую реляционную базу данных с типичной таблицей "отношений один ко многим", и т.д., и т.п. И для первого простого прототипа вы можете использовать то, что проще всего в выбранном вами языке (вероятно, простые и, увы, обязательно круговые ссылки [[указатели, в C++]] с Person, ссылающимся на Room и Room на list).
Взаимная зависимость сама по себе неплоха. Иногда этого требует использование данных.
Я думаю об этом иначе. Будет легче поддерживать код, в котором в целом меньше взаимосвязей - взаимозависимости или нет.Просто сделайте это как можно проще. Единственная дополнительная хитрость в вашей ситуации - это иногда проблема с проверкой и яйцом во время последовательностей создания и удаления. У вас есть больше ссылок на бухгалтерский учет.
Если вы спрашиваете, нужен ли вам список лиц в этом случае, я думаю, есть два ответа. Я бы начал с того, что ваши объекты (в памяти) обеспечивали эти отношения, но вам НЕ нужна дополнительная таблица соединений между людьми и отелями в базе данных. Если вы используете Hibernate, он автоматически сгенерирует эффективное соединение для вас, если вы попросите его для людей в отеле (он присоединится к отелям на rooms.hotel_id за вас).
Мне это не нравится. В отеле есть номера, а в номерах есть люди. Люди не содержат комнат, они принадлежат им.
Вам не обязательно итерировать, чтобы получить количество гостей. Вы можете просто сохранить счетчик хода ($Hotel->total_guests) и изменять его по мере его изменения.
В более крупной системе это было бы плохо, но поскольку, насколько я понимаю о ваших приложениях, эти три класса используются только вместе, это не большая проблема. Просто не забудьте назвать переменные-члены пользователя таким образом, чтобы указать, что они содержат ссылку на комнату, а не на экземпляр.
Тоже Если это не связано с соображениями производительности (например, у вас будет огромное количество номеров), вероятно, было бы чище сделать собственность или getter, которая будет перебирать номера и собирать людей, а не кэшировать их в отеле.