Как отдельный класс GUI будет взаимодействовать с классами логики?

Question

Как отдельный класс GUI будет взаимодействовать с классами логики?

1

Я пытаюсь создать игру tic tac toe, которая имеет несколько классов. Один класс - это GUI-класс, который отображает 9 кнопок для представления 9 областей Tic Tac Toe Board. Другой класс - это мой класс драйвера, который настраивает игру. Другие классы - это логика игры (доска, ходы). Однако я не уверен, как позволить классам GUI и логическим классам взаимодействовать друг с другом.

Я не хочу, чтобы класс GUI имел прямой доступ к доске, но я не знаю, как еще я должен передавать информацию туда и обратно. Например, если я нажму кнопку, текст кнопки должен быть обновлен, чтобы отразить метку (либо X, либо O), но я не знаю, какой знак изменить текст, не проверяя, чей это ход, и что информация находится в классе Board. Нажатие кнопки также должно позволить Совету знать, какие пробелы доступны, и что игрок повернулся.

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

user3577266 27 апр. 2014, в 03:37

Источник

Теги:

java

model-view-controller

user-interface

3 ответа

0

вы можете сделать их статическими полями и получить к ним доступ через ClassType.getVariable()

например:

public class Board
{
    private static char currentPlayer = 'X';

    public static char getCurrentPlayer()
    {
        return currentPlayer;
    }
}

и в вашем графическом интерфейсе вы используете Board.getCurrentPlayer();

yitzih 26 апр. 2014, в 23:00

0

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

Код будет выглядеть так:

import Logicclassname
public guiclass{
Logicclassname logic=new logicclassname();
}

public void updatefield(){
logic.functiontoexecute();
/* rest of code*/
}

Mytherious 26 апр. 2014, в 22:06

0

Я пытаюсь избежать того, чтобы у моего класса GUI был экземпляр класса Board. Я думаю, что если я это сделаю, то графический интерфейс на самом деле не отделен от логики. Это было так, как сказал мой учитель: «Обратите внимание, что графический интерфейс должен поддерживать актуальность текущей позиции доски, но вы не хотите, чтобы сама доска была частью графического интерфейса. Что вы можете сделать Убедитесь, что методы, предоставляемые платой, позволяют графическому интерфейсу запрашивать у платы информацию, необходимую для обновления дисплея ».
user3577266 27 апр. 2014, в 01:11
0

Без экземпляра вы не сможете получить доступ к методам, насколько я знаю, но если вы хотите, чтобы Правление могло иметь доступ к методам, которые ему действительно нужны, сделайте их общедоступными, а остальные - приватными.
Mytherious 27 апр. 2014, в 01:16
0

То, как выразился мой учитель, заставляет меня поверить, что в моем графическом интерфейсе не должно быть экземпляра класса Board, но спасибо за вашу помощь.
user3577266 27 апр. 2014, в 01:22

Показать ещё 1 комментарий

Ещё вопросы

Я пытаюсь избежать того, чтобы у моего класса GUI был экземпляр класса Board. Я думаю, что если я это сделаю, то графический интерфейс на самом деле не отделен от логики. Это было так, как сказал мой учитель: «Обратите внимание, что графический интерфейс должен поддерживать актуальность текущей позиции доски, но вы не хотите, чтобы сама доска была частью графического интерфейса. Что вы можете сделать Убедитесь, что методы, предоставляемые платой, позволяют графическому интерфейсу запрашивать у платы информацию, необходимую для обновления дисплея ».
Без экземпляра вы не сможете получить доступ к методам, насколько я знаю, но если вы хотите, чтобы Правление могло иметь доступ к методам, которые ему действительно нужны, сделайте их общедоступными, а остальные - приватными.
То, как выразился мой учитель, заставляет меня поверить, что в моем графическом интерфейсе не должно быть экземпляра класса Board, но спасибо за вашу помощь.

aruisdante · Accepted Answer · 2014-04-26T23-53-00.000Z

Я думаю, вы неправильно понимаете концепции Model-View-Controller. В какой-то момент компоненты должны взаимодействовать друг с другом, потому что они должны передавать информацию между ними. Дело в том, чтобы отделить взаимодействие от реализации результата.

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

В вашем случае я бы разработал такие вещи, чтобы существовал класс игрового движка, который имеет такой метод, как:

int makeMove(row, column)

Если row и column являются координатами на доске, а возвращенный int представляет игрока (X = 0, O = 1 или аналогичный. Вы даже можете использовать enum чтобы быть более явным), чей ход был, так что графический интерфейс может обновить соответствующий квадрат значком проигрывателя.

Тогда игровой движок ожидал бы, что у представления есть по крайней мере эти два метода:

void setPlayerTurn(int player)

Что говорит графическому интерфейсу, что он должен обновлять дисплей, на чей ход он (тот же player что и выше)

void setPlayerWon(int player, rows, columns)

Что говорит GUI, что игрок победил, и что он должен обновить три квадрата, обозначенных rows и columns как те, которые сделали игрока победителем, а player - тем же номером игрока, что и выше, чтобы он мог отображать соответствующий статус сообщение.

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

Таким образом, GUI (просмотр) заканчивается ссылкой на Game Logic (модель) и наоборот. Но они только взаимодействуют друг с другом через очень узкий и обобщенный интерфейс. Никто не знает и не заботится о том, что другой делает с информацией, переданной через этот интерфейс.

Обратите внимание, что в этом упрощенном примере я объединил контроллер с представлением, что довольно часто можно делать, когда вы разрабатываете универсальный графический интерфейс. По сути, графический интерфейс разработан таким образом, что он только когда-либо будет полезен в качестве платы Tic Tac Toe, но он ожидает, что вы предоставите свой собственный набор правил (моделей).

Сказав это, вы могли видеть, как это не займет гораздо больше, чтобы отделить их еще больше, заставив GUI просто разоблачить методы, которые позволят вам установить состояние (текст и значок) произвольного квадрата на сетке и отобразить статус сообщение. Ожидается, что ему будет предоставлен контроллер, который предоставит метод для уведомления о том, на каком квадрате на сетке взаимодействует пользователь. Затем контроллер будет предоставлять клей для интерфейса между этим общим представлением "сетка с представлением состояния" и логической моделью игры, которая ожидает интерфейс, описанный выше.

В этом случае GUI (представление) получает ссылку на контроллер и наоборот, а затем контроллер получает ссылку на Game Logic (модель) и наоборот.

Спасибо! Это, безусловно, имеет большой смысл.