Очистити OOP спосіб відображення об’єкта на його презентаторі

Я створюю настільну гру (наприклад, шахи) на Java, де кожен твір є власним типом (наприклад Pawn, Rookтощо). Для частини програми GUI мені потрібно зображення для кожної з цих частин. Оскільки робити мислить, як

rook.image();

порушує розділення інтерфейсу користувача та бізнес-логіки, я створять різного презентатора для кожної деталі, а потім зіставляю типи творів відповідним доповідачам, як-от

private HashMap<Class<Piece>, PiecePresenter> presenters = ...

public Image getImage(Piece piece) {
  return presenters.get(piece.getClass()).image();
}

Все йде нормально. Однак я вважаю, що розсудливий гуру OOP нахмуриться, зателефонувавши на getClass()метод, і запропонував би використати відвідувача наприклад:

class Rook extends Piece {
  @Override 
  public <T> T accept(PieceVisitor<T> visitor) {
    return visitor.visitRook(this);
  }
}

class ImageVisitor implements PieceVisitor<Image> {
  @Override  
  public Image visitRook(Rook rook) {
    return rookImage;
  } 
}

Мені подобається це рішення (дякую, гуру), але воно має один істотний недолік. Кожен раз, коли до програми додається новий тип твору, PieceVisitor потрібно оновлювати новим методом. Я хотів би використовувати свою систему як рамку настільних ігор, куди нові фрагменти можна було б додати за допомогою простого процесу, коли користувач фреймворку забезпечив би реалізацію як фрагмента, так і його презентатора, і просто підключив його до рамки. Моє питання: є чисте рішення ООП без instanceof, і getClass()т.д. , які дозволили б для такого роду розширюваність?

чи є чисте рішення OOP без instanceof, getClass () тощо, що дозволило б розширити цей вид?

Так, є.

Дозвольте запитати у вас це. У своїх поточних прикладах ви знаходите способи зіставлення типів деталей із зображеннями. Як це вирішує проблему переміщення твору?

Більш потужна техніка, ніж запитувати про тип - це слідувати Tell, не запитувати . Що робити, якщо кожен фрагмент взяв PiecePresenterінтерфейс, і це виглядало приблизно так:

class PiecePresenter implements PieceOutput {

  BoardPresenter board;
  Image pieceImage;

  @Override
  PiecePresenter(BoardPresenter board, Image image) {
    public void display(int rank, int file) {
      board.display(pieceImage, rank, file);
    } 
  }
}

Конструкція виглядала б приблизно так:

rookWhiteImage = new Image("Rook-White.png");
PieceOutput rookWhiteOutPort = new PiecePresenter(boardPresenter, rookWhiteImage);
PieceInput rookWhiteInPort = new Rook(rookWhiteOutPort);
board[0, 0] = rookWhiteInPort;

Використання виглядатиме приблизно так:

board[rank, file].display(rank, file);

Ідея тут полягає у тому, щоб не брати на себе відповідальність за те, щоб робити щось, за що відповідають інші речі, не запитуючи про це та не приймаючи рішення на його основі. Замість цього тримайте посилання на щось, що знає, що з цим робити, і скажіть йому, щоб він робив щось, що ви знаєте.

Це дозволяє поліморфізм. Ви не дбаєте про те, з чим ви розмовляєте. Вам все одно, що це має сказати. Вам просто байдуже, що він може робити те, що вам потрібно зробити.

Хороша схема , яка тримає їх в окремих шарах, слід сказати-ні-запитати, і показує , як не пара шару до шару незаслужено знаходиться це :

Він додає шар шару використання, який ми тут не використовували (і, безумовно, можемо додати), але ми дотримуємось тієї ж схеми, яку ви бачите в нижньому правому куті.

Ви також помітите, що презентатор не використовує спадщину. Тут використовується композиція. Спадщина має бути крайнім способом отримати поліморфізм. Я віддаю перевагу дизайнам, які надають перевагу використанню композиції та делегації. Це трохи більше набору клавіатури, але це набагато більше потужності.

Що на рахунок того:

Ваша модель (класи малюнків) має загальні методи, які можуть знадобитися і в іншому контексті:

interface ChessFigure {
  String getPlayerColor();
  String getFigureName();
}

Зображення, які використовуються для відображення певної фігури, отримують імена файлів за схемою іменування:

King-White.png
Queen-Black.png

Тоді ви можете завантажити відповідне зображення без доступу до інформації про класи java.

new File(FIGURE_IMAGES_DIR,
         String.format("%s-%s.png",
                       figure.getFigureName(),
                       figure.getPlayerColor)));

Я також зацікавлений у загальному вирішенні подібних проблем, коли мені потрібно додавати певну інформацію (не лише зображення) до потенційно зростаючого набору класів ".

Я думаю, вам не варто так зосереджуватися на заняттях . Швидше думайте з точки зору бізнес-об’єктів .

І загальне рішення - це відображення будь-якого типу. Хитрість IMHO полягає в тому, щоб перенести це зіставлення з коду на ресурс, який легше підтримувати.

Мій приклад робить це відображення за умовами, яке досить легко здійснити і не дозволяє додавати інформацію, що стосується перегляду, у бізнес-модель . З іншого боку, ви можете вважати це "прихованим" відображенням, оскільки воно ніде не виражається.

Інший варіант - розглянути це як окремий діловий випадок із власними шарами MVC, включаючи стійкий шар, що містить відображення.

Я створив би окремий інтерфейс / клас перегляду для кожного фрагмента, який містить візуальну інформацію. Кожен із цих класів огляду має вказівник на свою модель / діловий аналог, який містить положення та правила гри.

Тому візьміть наприклад пішака:

class Pawn : public Piece {
public:
    Vec2 position() const;
    /**
     The rest of the piece's interface
     */
}

class PawnView : public PieceView {
public:
    PawnView(Piece* piece) { _piece = piece; }
    void drawSelf(BoardView* board) const{
         board.drawPiece(_image, _piece->position);
    }
private:
    Piece* _piece;
    Image _image;
}

Це дозволяє повністю розділити логіку та інтерфейс користувача. Ви можете передати логічний елемент вказівника до ігрового класу, який би обробляв переміщення фігур. Єдиним недоліком є ​​те, що примірник повинен був би відбуватися в класі інтерфейсу користувача.

Я би підійшов до цього, зробивши Pieceзагальне, де його параметр - це тип перерахування, який ідентифікує тип фрагмента, кожен фрагмент має посилання на один такий тип. Тоді користувальницький інтерфейс міг використовувати карту з перерахування, як і раніше:

public abstract class Piece<T>
{
    T type;
    public Piece (T type) { this.type = type; }
    public T getType() { return type; }
}
enum ChessPieceType { PAWN, ... }
public class Pawn extends Piece<ChessPieceType>
{
    public Pawn () { super (ChessPieceType.PAWN); }

Це має дві цікаві переваги:

По-перше, застосовно до більшості мов, які набираються статично: Якщо ви параметризуєте свою дошку типом фрагмента до xpect, ви не можете вставити в неї неправильний тип фрагмента.

По-друге, і, мабуть, цікавіше, якщо ви працюєте на Java (або інших мовах JVM), ви повинні зауважити, що кожне значення enum не є просто незалежним об'єктом, але воно може мати і свій клас. Це означає, що ви можете використовувати об'єкти типу шматок як об’єкти стратегії, щоб замовити поведінку фрагмента:

 public class ChessPiece extends Piece<ChessPieceType> {
    ....
   boolean isMoveValid (Move move)
    {
         return getType().movePatterns().contains (move.asVector()) && ....


 public enum ChessPieceType {
    public abstract Set<Vector2D> movePatterns();
    PAWN {
         public Set<Vector2D> movePatterns () {
              return Util.makeSet(
                    new Vector2D(0, 1),
                    ....

(Очевидно, що реальні реалізації повинні бути складнішими за це, але, сподіваємось, ви отримаєте ідею)

Я прагматичний програміст, і мені дуже байдуже, чиста чи брудна архітектура. Я вважаю, що вимоги мають бути вирішені простим способом.

Ваша вимога - ваша логічна програма буде представлена ​​на різних шарах (пристроях) презентації, наприклад, в Інтернеті, мобільних додатках або навіть консольних програмах, тому вам потрібно підтримати ці вимоги. Ви можете віддати перевагу використовувати дуже різні кольори, фрагменти зображень на кожному пристрої.

public class Program
{
    public static void Main(string[] args)
    {
        new Rook(new Presenter { Image = "rook.png", Color = "blue" });
    }
}

public abstract class Piece
{
    public Presenter Presenter { get; private set; }
    public Piece(Presenter presenter)
    {
        this.Presenter = presenter;
    }
}

public class Pawn : Piece
{
    public Pawn(Presenter presenter) : base(presenter) { }
}

public class Rook : Piece
{
    public Rook(Presenter presenter) : base(presenter) { }
}

public class Presenter
{
    public string Image { get; set; }
    public string Color { get; set; }
}

Як ви бачили, параметр презентатора повинен передаватися на кожному пристрої (презентаційному шарі) по-різному. Це означає, що ваш презентаційний шар вирішить, як представити кожен твір. Що не так у цьому рішенні?

Є ще одне рішення, яке допоможе вам повністю абстрагувати інтерфейс користувача та логіку домену. Ваша дошка повинна піддаватися шару вашого інтерфейсу, і ваш шар інтерфейсу може вирішити, як зобразити фрагменти та позиції.

Для цього можна скористатися рядком Fen . Рядок Fen - це в основному інформація про стан борту, і він дає поточні фрагменти та їх положення на борту. Таким чином, на вашій дошці може бути метод, який повертає поточний стан плати за допомогою рядка Fen, тоді ваш шар інтерфейсу може представляти дошку за своїм бажанням. Це насправді, як працюють сучасні шахові двигуни. Шахові двигуни - консольне застосування без GUI, але ми використовуємо їх через зовнішній графічний інтерфейс. Шаховий двигун спілкується з GUI через фен-струни та шахові позначення.

Ви запитуєте, що робити, якщо я додам новий твір? Нереально, що шахи введуть новий твір. Це було б величезними змінами у вашому домені. Тому дотримуйтесь принципу YAGNI.