Будет ли в этом случае единый графический интерфейс?

Question

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

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

Answer 1

Существует множество мнений в этой области, см. Ссылки ниже.

Мне кажется, что мы должны стараться избегать синглетонов, потому что "такого числа как 1 нет".

[Это следует из моей теории, что «такого числа, как 2, не существует». Если у вас есть код, который допускает два с чем-то, и только два с чем-то, то вы пропустили хитрость - почти наверняка будет больше двух, вместо этого решите, как бороться со «многими».

«Нет такого числа, как 1 аргумент» в том, что когда вы думали, что может быть только одно из чего-то, будет некоторый контекст, в котором можно получить больше ... и обычно очень мало дополнительной работы, чтобы больше.

Посмотрите на ваш пример ... У меня есть различные объекты автомобилей, все они имеют доступ к одной и той же дороге? Похоже ли это на модель реалистичного мира? Дороги Великобритании и французские дороги, какая разница? ;-) Зачем встраивать это «единственное» предположение в ваш код?

Использование фабрик и внедрение зависимостей этих фабрик часто будет лучшим ответом. Множество материала в ответах на этот вопрос .

Answer 2

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

Это станет еще более очевидным, если вы решите самостоятельно протестировать автомобили. Если вы не можете предоставить макет для дороги, как вы будете их тестировать? И вы не сможете, потому что они ссылаются на свою дорогу через Синглтон.

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

Answer 3

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

Сокрытие этого за статическими методами гарантирует, что, если вы работаете над этим с кем-то еще, вы можете ограничить то, что вы хотите, чтобы они имели доступ к основному JFrame, но было бы бесполезно для чего-то вроде школьного проекта и т. Д.