Изящный способ обработать Циклическое Событие в Java?

Это немного сложно, но вы можете сделать A действительно наблюдаемым объектом. Оба прядильщика (или что-то еще, что должно обновляться на основе значения A ) будут тогда наблюдать A . Всякий раз, когда A изменяется, счетчики (или снова любой другой объект) обновляются, чтобы отразить новое значение A . Это отделяет логику спиннеров друг от друга. В вашем примере здесь прядильщики не должны быть связаны друг с другом, потому что они действительно не имеют ничего общего друг с другом. Вместо этого они оба должны быть просто привязаны к A и позаботиться об обновлении своего собственного представления по отдельности.

Каждый раз, когда значение в первом счетчике изменяется, вы просто обновляете значение A , чтобы оно соответствовало ему. Каждый раз, когда значение во втором счетчике изменяется, вы, конечно, должны добавить 10 к его значению, прежде чем присвоить его A .

Обновление

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

Например, для второго волчка вычислите A-10, а затем сравните его с текущим значением волчка. Если оно одинаково, ничего не делайте, завершая бесконечный цикл. Аналогично для первого волчка.

Я думаю, что есть еще способы обновить модель волчка так, чтобы не вызывать событие, но я их не знаю.

Используйте одну модель SpinnerModel для обоих JSpinners. См. следующий код: Обратите внимание, что вызов setValue() выполняется только один раз, каждый раз, когда новое значение определяется одним из JSpinners.

import java.awt.BorderLayout;

import javax.swing.*;

public class Test {
    public static void main(String[] args) {
        JFrame jf = new JFrame();
        SpinnerModel spinModel = new MySpinnerModel();
        JSpinner jspin1 = new JSpinner(spinModel);
        JSpinner jspin2 = new JSpinner(spinModel);
        jf.setLayout(new BorderLayout());
        jf.add(jspin1, BorderLayout.NORTH);
        jf.add(jspin2, BorderLayout.SOUTH);
        jf.pack();
        jf.setVisible(true);
        jf.setDefaultCloseOperation(3);
    }
}

class MySpinnerModel extends AbstractSpinnerModel {
    private int _value = 0;
    private int _min = 0;
    private int _max = 10;

    @Override
    public Object getNextValue() {
        if (_value == _max) {
            return null;
        }
        return _value + 1;
    }

    @Override
    public Object getPreviousValue() {
        if (_value == _min) {
            return null;
        }
        return _value - 1;
    }

    @Override
    public Object getValue() {
        return _value;
    }

    @Override
    public void setValue(Object value) {
        System.out.println("setValue(" + value + ")");
        if (value instanceof Integer) {
            _value = (Integer) value;
            fireStateChanged();
        }
    }
}

Я не очень хочу решать вашу проблему, но она мне кажется интересной. Я уже сталкивался с ней и решал ее каждый раз по-разному. Но когда я думаю о "почему?", а не о "как?", я остаюсь в недоумении.
Эта проблема существует только потому, что я использую автоматику (MVC), которая должна была мне помочь, и именно таким образом. Искусство использования компонентов делает этот автоматизм препятствием для красивого кода.
Почему set #setEvent() должен производить то же событие, что и действие GUI?

Хотя мое мнение тоже довольно близко к паттерну Observer, но оно немного легче !!!

Использовать A как переменную с установщиком

private Integer A;

setA(int A)
{
  this.A = A;
  refreshSpinners();
}


refreshSpinners()
{
  setSpinnerA();
  setSpinnerAMinus10();
}

setSpinnerA()
{
   // show value of A
}

setSpinnerAMinus10()
{
   // show value of A-10
}

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

Однако дальнейшее погружение в реализацию пользовательского интерфейса может быть не тем ответом, который вам нужен. В этом случае я бы сказал, что лучшее, что вы можете сделать, - это либо ваше текущее защитное решение, либо лучшее извлечение логики в вашу модель (аналогично тому, что сказали Марк и Уильям). Как это можно сделать, будет зависеть от модели «реального мира», лежащей в основе конкретной реализации предоставленной головоломки.

Проблема решена

У меня есть много разных предложений. В частности, я хочу поблагодарить Марка У и преподобного Гонзо. Я здесь, чтобы подытожить эти идеи; это может сэкономить ваше время при просмотре большого количества текстов.

Эту проблему можно легко обойти, если аккуратно разделить представление и модель-контроллер. Мертвый цикл вызван зависимыми записями: write_1 -> write_2 -> write_1 -> ... . Интуитивно, разрыв зависимости может элегантно решить проблему.

Если мы углубимся в проблему, мы можем обнаружить, что обновление соответствующих представлений не обязательно требует внешнего вызова записи. На самом деле представление зависит только от данных, которые оно представляет. После этого мы можем переписать логику следующим образом: write_1 -> read_2 & write_2 -> read_1 .

Чтобы проиллюстрировать эту идею, давайте сравним 3 метода, упомянутых на разных плакатах: альтернативный текст http://www.freeimagehosting.net/uploads/2707f1b483.png

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

На практике это может быть реализовано примерно так (в кодах событий-ответов):

 setValue(newValue);
 anotherSyncUI.parse();  // not anotherSyncUI.setValue() any more
 anotherSyncUI.repaint();

Больше никаких циклов. Решено.

Как правило, ваша модель не должна определяться вашим графическим интерфейсом. То есть SpinnerModel, поддерживающий каждый JSpinner, не должен быть вашим значением A. (Это было бы ужасно неэлегантной тесно связанной зависимостью от конкретного представления.)

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

Я понимаю, что это похоже на ответ Марка В., и вы были обеспокоены тем, что это «сложно», но PropertyChangeSupport делает почти все это за вас.

Фактически, для тривиально простых случаев вы можете просто использовать один класс, который связывает метод «setProperty» с вызовом «firePropertyChange» (а также сохраняет значение в HashMap для любых вызовов «getProperty»).