Лучший способ отделить бизнес от логики презентации?

Question

Я хочу создать игру, которая будет работать как локально, так и онлайн.

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

Это отлично работает для сообщений типа запрос-ответ.Но как насчет сообщений, которые отправляет сервер, где я должен обновить некоторые компоненты графического интерфейса (т. е.JLabels)?

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

На правильном ли я пути?Потому что я думаю, что это не так.Есть какие-нибудь предложения?

Спасибо.

ПРИМЕЧАНИЕ:Клиент представляет собой простой графический интерфейс Java Swing.

Answer 1

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

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

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

Answer 2

Я признаю, что занимаюсь веб-разработкой, поэтому у меня не так уж много опыта работы со Swing.

Но я всегда думал, что мой подход к этому заключался бы в том, чтобы разбить приложение на пакеты / view, /model и / controller.Отношения были бы однонаправленными:/controller знал бы как о / model, так и о / view, но ни один из них не импортировал бы какие-либо классы из / controller или друг из друга.

Компоненты слоя / view никогда не будут JFrames;это всегда будет JPanel или другой подходящий контейнер, который при необходимости можно было бы скомпоновать в JFrames.Каждый из них будет иметь ссылки на интерфейсы прослушивателя, инициализированные в конструкторах, и будет ссылаться на них для обработки событий:

public class ExamplePanel extends JPanel implements ActionListener
{
    private JButton button;
    private ActionListener buttonListener;

    public ExamplePanel(ActionListener buttonListener)
    {    
        this.button = new JButton("Do Something");
        this.buttonListener = buttonListener;
        this.button.addListener(this.buttonListener);
    }

    public void actionPerformed(ActionEvent e)
    {
        this.buttonListener.actionPerformed(e);
    }
}

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

Я признаю, что никогда не следил за этим до конца.

У людей из Spring есть богатый клиентский модуль Swing, но, похоже, он впал в немилость.Похоже, они решили, что направление BlazeDS - лучший выбор для богатых клиентов.Но, возможно, вы сможете почерпнуть некоторые дизайнерские идеи из их подхода.