Зарегистрировать все компоненты графического интерфейса в качестве наблюдателей или передать текущий объект следующему объекту в качестве аргумента конструктора? - PullRequest
3 голосов
/ 18 марта 2010

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

Я создаю графический интерфейс, в котором каждый компонент должен взаимодействовать (или, по крайней мере, обновляться) несколько других компонентов. В настоящее время я использую класс 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, но я не могу придумать, как это сделать.

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

1 Ответ

0 голосов
/ 17 апреля 2012

Немного трудно судить, можно ли решить то, что вы пытаетесь сделать, используя Внедрение зависимости . С использованием принципа Inversion of Control вы можете, если у вас есть несколько четко определенных интерфейсов, вводить их в конструкторы объектов без необходимости делать это явно. Это делается с использованием фреймворка, подобного String , который использует контейнер и рефлексию для выполнения задачи.

Есть много предположений относительно варианта использования, таких как:

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...