Во-первых, я хотел бы сказать, что я думаю, что это общая проблема, и может быть простое или общее решение, о котором я не знаю. Многие, вероятно, сталкивались с подобной проблемой. Спасибо за чтение.
Я создаю графический интерфейс, в котором каждый компонент должен взаимодействовать (или, по крайней мере, обновляться)
несколько других компонентов. В настоящее время я использую класс Singleton для достижения этой цели. Каждый компонент GUI получает экземпляр синглтона и регистрируется самостоятельно. Когда необходимо выполнить обновление, синглтон может вызывать открытые методы в зарегистрированном классе. Я думаю, что это похоже на паттерн Observer, но у синглтона больше контроля. В настоящее время программа настроена примерно так:
class c1 {
CommClass cc;
c1() {
cc = CommClass.getCommClass();
cc.registerC1( this );
C2 c2 = new c2();
}
}
class c2 {
CommClass cc;
c2() {
cc = CommClass.getCommClass();
cc.registerC2( this );
C3 c3 = new c3();
}
}
class c3 {
CommClass cc;
c3() {
cc = CommClass.getCommClass();
cc.registerC3( this );
C4 c4 = new c4();
}
}
и т.д.
К сожалению, класс синглтонов продолжает расти, так как требуется больше связи между компонентами.
Мне было интересно, будет ли хорошей идеей вместо использования этого синглтона передавать компоненты графического интерфейса более высокого порядка в качестве аргументов в конструкторы каждого компонента графического интерфейса:
class c1 {
c1() {
C2 c2 = new c2( this );
}
}
class c2 {
C1 c1;
c2( C1 c1 ) {
this.c1 = c1
C3 c3 = new c3( c1, this );
}
}
class c3 {
C1 c1;
C2 c2;
c3( C1 c1, C2 c2 ) {
this.c1 = c1;
this.c2 = c2;
C4 c4 = new c4( c1, c2, this );
}
}
и т.д.
Вторая версия меньше полагается на CommClass, но она все еще очень грязная, так как число закрытых переменных-членов увеличивается, а конструкторы растут в длину.
Каждый класс содержит компоненты GUI, которые должны взаимодействовать через CommClass, но я не могу придумать, как это сделать.
Если это кажется странным или ужасно неэффективным, опишите, пожалуйста, какой-то метод связи между классами, который будет продолжать работать по мере роста проекта. Кроме того, если это ни для кого не имеет смысла, я постараюсь дать реальные фрагменты кода в будущем и подумаю, как лучше задать вопрос. Спасибо.