Зачем использовать связанные свойства javabean вместо событий? - PullRequest
Новая
       9

Зачем использовать связанные свойства javabean вместо событий?

2 голосов
/ 23 февраля 2010

Что именно является точкой связанных свойств? Мне кажется, что они представляют собой менее безопасную для типов версию событий с использованием EventObjects - кажется немного слабым использование проверки на равенство строк для event.getPropertyName ().

Зачем вам использовать один над другим?

Ответы [ 3 ]

1 голос
/ 23 февраля 2010

Весь смысл Java Beans состоит в том, что система (в частности GUI Builder) может исследовать Java Bean и настраивать его без каких-либо предварительных знаний об этом компоненте.

Хотя это довольно круто, на самом деле это полезно только в этой конкретной ситуации, и в наши дни аннотации будут работать НАМНОГО лучше.

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

Ответ на @Mike грызун

Допустим, вы разрешаете своему пользователю создавать класс, которым вы будете управлять. Этот класс имеет "Main" и может обрабатывать пару событий.

Обычно ваш пользователь делает что-то вроде этого: 

class UserClass(someClass) {
    void mainMethod() {
        someClass.addEventListener(new EventListener() {
            public void eventsHappen(Event e){
                    event1(e)
                }
            }
        }
        someClass.addDifferentEventListener(new DifferentEventListener() {
            public void eventsHappen(DifferentEvent e){
                    event2(e)
                }
            }
        }
    } 

    public void event1(Event e) {
        //java code for event 1
    }
    public void event2(DifferentEvent e) {
        // java code for event 2
    }
}

В любом случае, вы поняли идею. Конечно, вы предполагаете, что этот класс где-то зарегистрирован - возможно, в файле xml / config. Вы читаете его, создаете его экземпляр и выполняете mainMethod (определенный соглашением или интерфейсом), и он регистрируется сам и начинает получать вызовы обработчиков событий.

Теперь вот как вы можете выполнить то же самое с помощью аннотаций: (Вы можете распознать шаблон - это в значительной степени то, как Junit комментирует тесты.) 

class UserClass() {
    @Event1
    void event1Method(Event e) {
        event1's code
    }
    @Event2
    void event2Method(AnotherEvent e) {
        event2's code
    } 
}

Это гораздо более прямолинейно и удаляет большую часть шаблона, а также устраняет необходимость в соглашении или интерфейсе, аннотации более четко определены и независимы. (На самом деле вам даже НЕ НУЖНЫ аннотации событий, если вы хотите проверить параметры, передаваемые в методы, но драконы лежат в этом общем направлении).

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

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

0 голосов
/ 23 февраля 2010

Я думаю, что спецификация JavaBeans была разработана с учетом общей обработки объектов. Например, помещение JavaBean в IDE и использование редактора визуальных свойств для его настройки. В этом случае в среде IDE будет использоваться общее PropertyChangeEvent и т. Д.

Или, если вы хотите скопировать одинаковые именованные свойства из одного компонента в другой ... это еще один случай использования компонента (класс BeanUtils).

Но, если вы планируете делать что-то конкретное, как говорит Ноэль Анг, я бы рекомендовал печатать строго по буквам.

0 голосов
/ 23 февраля 2010

JavaBeans - это спецификация. Он определяет связанное свойство как то, изменение которого приводит к отправке уведомления, а PropertyChangeEvent является санкционированным объектом уведомления.

Таким образом, предполагаемый редактор бобов JavaBeans-spec должен прослушивать PropertyChangeEvents. Помимо необходимости работать с этой спецификацией, я бы сам не использовал ее.

...