Когда целесообразно использовать интерфейсы Java в настольной игре?

Question

(Примечание: это скорее теоретический вопрос)

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

Так что мне интересно, когда уместно использовать интерфейс в java или, более конкретно, когда может быть полезно в настольной игре, такой как шашки или шахматы, использовать интерфейс? Я пытаюсь понять, для чего я мог бы создать интерфейс (например, движения, рисование на доске и т. Д.), Который в то же время, скорее всего, принесет пользу программе.

Answer 1

Всегда полезно программировать на интерфейс, потому что он формализует класс, чтобы иметь необходимый набор методов. Это также позволяет собирать классы, которые реализовали общий интерфейс для совместной работы. Представьте, что у вас было много объектов, у которых был метод setColor. Вместо того, чтобы устанавливать цвет по отдельности или через списки каждого типа объектов, вы можете сделать так, чтобы они делали следующее:

Interface ColorSetter {
   public void setColor(Color color);
}

class Foo implements ColorSetter {
//details omitted
}

class Bar implements ColorSetter {
//details omitted
}

List<ColorSetter> colorSetters = new ArrayList<>();
colorSetters.add(new Foo());
colorSetters.add(new Bar());

// later...
for (ColorSetter c : colorSetters) {
   c.setColor(Color.blue);
}

Answer 2

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

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

Вы могли бы расширить свои знания, читая также принципы SOLID и проверяя общие шаблоны проектирования программного обеспечения (например, https://refactoring.guru/).

Answer 3

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

Например, интерфейс Piece может иметь несколько распространенных методов, таких как:

public interface Piece {
    String getName();
    Position getPosition();
    List<Movement> getAvailableMovements();
    void move(Movement movement);
    BufferdImage getImage();
}

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