Лучшая модель привязки данных

public class SomeBean {
 private PropertyChangeSupport changeSupport = new PropertyChangeSupport(this);

 public void setProperty(String newValue) {
  String oldValue = property;
  property = newValue;
  changeSupport.firePropertyChange("propertyName", oldValue, newValue);
 }

 public void addPropertyChangeListener(PropertyChangeListener l) {
  changeSupport.add(l);
 }

 public void removePropertyChangeListener(PropertyChangeListener l) {
  changeSupport.remove(l);
 }
}

Это много кода для чего-то, что должно быть очень простым.

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

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

Экстремальное сцепление

Чтобы элемент GUI обновлялся при изменении значения модели, ему необходимо добавить себя в качестве прослушивателя этой модели. Например, вы можете представить, что если имя меняется в режиме, пользовательский интерфейс захочет обновить метку и заголовок окна. Если вы выполните математику, вы увидите, что «n» элементов пользовательского интерфейса, которые должны отслеживать «m» объекты модели, приведут к n * m связям. И, конечно же, ваша модель и ваш вид теперь очень тесно связаны, что добавляет еще больше проблем.

Экстремальное воздействие данных

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

Богоявление

Все эти соображения начали беспокоить меня совсем недавно, так как я был занят работой над плагином Eclipse. Я умножал количество объектов PropertyChangeSupport во всех моих моделях и в основном расширял один и тот же класс снова и снова (если мне повезло) или просто копировал / вставлял код выше (большую часть времени). Мне сильно не нравилось количество загрязнений, которое начало проникать в мой код, и я начал рассматривать альтернативы.

А потом я вспомнил пост, который я написал несколько месяцев назад о «местных автобусах». Мне пришло в голову, что, если бы я мог вставить шину сообщений между моделью и ее слушателями, тогда два мира стали бы полностью разъединенными. Кроме того, я мог бы добавить некоторую поддержку свойств, которая скрывала бы большую часть сложности.

JBus и свойства

Моя реализация локальной шины очень мала и очень проста и похожа на ту, что я описал в посте блога, связанном выше: слушатели являются методами, и они объявляют себя с аннотацией @Subscriber. Предполагается, что эти методы принимают один параметр, представляющий класс интересующего их события.

Вот быстрый пример:

public class App {

  @Subscriber
  public void event1(NotifyEvent ne) {
    System.out.println("event1: " + ne);
  }

}

JBus mb = new JBus();
jb.register(new App());
jb.post(new NotifyEvent("notify"));

Это первая часть сантехники. Элементы GUI, которые хотят получать обновления, будут просто объявлять себя подписчиками для определенных типов событий (как правило, PropertyChangeEvent, но это не должно быть ограничено этим).

Вторая часть заключается в том, чтобы максимально автоматизировать публикацию событий, и в итоге я создал для этого класс Property. Вот пример того, как его использовать:

public class Person {
  // A property that the GUI is interested in
  private Property<String> name;

  // A field that the GUI is not interested in
  private int age;

  public void setName(String n) {
    name.set(n);
  }
}

Первое, что вы заметите, это то, что, поскольку они имеют тип Property, свойства, которые публикуют события, легко идентифицировать в коде. Кроме того, свойства будут автоматически публиковать события всякий раз, когда вызывается их установщик, что подразумевает, что 1) им нужно иметь экземпляр шины сообщений и 2) им нужно знать имя свойства, под которым будут опубликованы изменения.

Поэтому конструктор Property выглядит следующим образом:

public class Property<T> {
  public Property(JBus bus, String propertyName, Object source) { ... }
}