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

Question

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

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

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

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

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

Спасибо.

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

Answer 1

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

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

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

Answer 2

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

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

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

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 - лучший выбор для богатых клиентов. Но, возможно, вы сможете почерпнуть некоторые дизайнерские идеи из их подхода.