Плохо ли иметь класс, который содержит указатели на большинство объектов и ссылаться на него через него?

Question

Я работаю над своим первым большим проектом с довольно большим количеством компонентов. И когда я столкнулся с необходимостью обмениваться данными между несколькими объектами разных классов, я решил создать класс State, который будет содержать указатели на все важные объекты, и я передаю его каждому новому объекту через конструктор. Таким образом, чтобы получить доступ к объекту, я всегда буду использовать state.object.method (); Я также использую это для отделения сервера от клиента при одновременной работе, имея два объекта состояния.

Итак, поскольку я не являюсь опытным программистом (пока :)), и меня очень волнует структура программы вещей, и ее построение «правильным» образом, и я нигде не видел этого остальное. Это приличная структура? Или есть какие-то проблемы, которых я пока не вижу? Я не думаю, что правильно ОО?

Если это нормальный способ сделать это, я думаю, что вопрос о дыре становится субъективным, и здесь не должно быть обсуждения. Если так, прости.

-Кодер, который беспокоится о структуре. (Кто может сидеть по ночам, пытаясь реструктурировать, если он чувствует, что код становится уродливым)

Answer 1

Вам лучше использовать внедрение зависимостей, где каждому классу передаются все объекты, от которых он зависит.Для ситуаций уведомления / публикации вы можете использовать шаблон Observer или шаблон слушателя, где компонент публикует данные посреднику, а слушатели слушают эти данные.Используя эти две модели, вы сможете сократить свое состояние до менее чем 6 объектов или полностью удалить его.

Answer 2

Вы создали своего рода объект менеджера, который обрабатывает «состояние» приложения, управляя коллекцией объектов.

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

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

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

Большая часть наиболее оптимального дизайна зависит от модели, лежащей в основе вашего приложения. Следует обратить внимание на чрезмерно статичное определение, создание зависимостей между объектами, свойства жизненного цикла, такие как создание объектов по требованию и создание при инициализации приложения, и количество ссылок между объектами (если ваш менеджер ссылается на каждый другой объект в вашем приложении. неправильно.)

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