Modo pulito OOP di mappare un oggetto al suo presentatore

Sto creando un gioco da tavolo (come gli scacchi) in Java, dove ogni pezzo è del suo tipo (come Pawn, Rookecc.). Per la parte GUI dell'applicazione ho bisogno di un'immagine per ciascuno di questi pezzi. Dal momento che fare pensa come

rook.image();

viola la separazione dell'interfaccia utente e della logica aziendale, creerò un presentatore diverso per ogni pezzo e quindi mapperò i tipi di pezzo ai presentatori corrispondenti come

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

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

Fin qui tutto bene. Tuttavia, sento che un guru OOP prudente si acciglierebbe nel chiamare un getClass()metodo e suggerirebbe di usare un visitatore per esempio come questo:

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;
  } 
}

Mi piace questa soluzione (grazie, guru), ma ha uno svantaggio significativo. Ogni volta che un nuovo tipo di pezzo viene aggiunto all'applicazione, PieceVisitor deve essere aggiornato con un nuovo metodo. Vorrei utilizzare il mio sistema come framework di giochi da tavolo in cui i nuovi pezzi potevano essere aggiunti attraverso un semplice processo in cui l'utente del framework avrebbe fornito l'implementazione sia del pezzo che del suo presentatore, e semplicemente lo avrebbe inserito nel framework. La mia domanda: esiste una soluzione OOP pulita senza instanceof, getClass()ecc. Che consentirebbe questo tipo di estensibilità?

esiste una soluzione OOP pulita senza instanceof, getClass () ecc. che consentirebbe questo tipo di estensibilità?

Si C'è.

Lascia che ti chieda questo. Nei tuoi esempi attuali stai trovando modi per mappare i tipi di pezzi alle immagini. In che modo questo risolve il problema di spostare un pezzo?

Una tecnica più potente della domanda sul tipo è seguire Tell, non chiedere . E se ogni pezzo avesse PiecePresenterun'interfaccia e assomigliasse a questo:

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);
    } 
  }
}

La costruzione sarebbe simile a questa:

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

L'uso sarebbe simile a:

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

L'idea qui è di evitare di assumersi la responsabilità di fare qualsiasi cosa di cui sono responsabili altre cose non chiedendole né prendendo decisioni basate su di essa. Tieni invece un riferimento a qualcosa che sa cosa fare di qualcosa e digli di fare qualcosa di ciò che sai.

Ciò consente il polimorfismo. Non ti interessa di cosa stai parlando. Non ti interessa quello che ha da dire. Ti importa solo che possa fare quello che ti serve.

Un buon diagramma che li mantiene in livelli separati, segue tell-Don't-ask e mostra come non accoppiare i layer a layer ingiustamente è questo :

Aggiunge un livello di caso d'uso che non abbiamo usato qui (e che possiamo sicuramente aggiungere) ma stiamo seguendo lo stesso modello che vedi nell'angolo in basso a destra.

Noterai anche che Presenter non usa l'ereditarietà. Usa la composizione. L'ereditarietà dovrebbe essere l'ultima via per ottenere il polimorfismo. Preferisco i disegni che preferiscono usare la composizione e la delega. Digita un po 'più la tastiera, ma è molto più potente.

Che dire di questo:

Il tuo modello (le classi di figure) ha metodi comuni che potresti aver bisogno anche in altri contesti:

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

Le immagini da utilizzare per visualizzare una determinata figura ottengono i nomi dei file da uno schema di denominazione:

King-White.png
Queen-Black.png

Quindi è possibile caricare l'immagine appropriata senza accedere alle informazioni sulle classi java.

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

Sono anche interessato a una soluzione generale per questo tipo di problemi quando devo allegare alcune informazioni (non solo immagini) a un insieme di classi potenzialmente in crescita. "

Penso che non dovresti concentrarti così tanto sulle lezioni . Piuttosto pensa in termini di oggetti business .

E la soluzione generica è una mappatura di qualsiasi tipo. IMHO il trucco è spostare quella mappatura dal codice a una risorsa che è più facile da mantenere.

Il mio esempio fa questa mappatura per convenzione che è abbastanza facile da implementare ed evita di aggiungere informazioni relative alla vista nel modello di business . D'altra parte potresti considerarlo una mappatura "nascosta" perché non è espressa da nessuna parte.

Un'altra opzione è di vedere questo come un caso aziendale separato con i propri livelli MVC, incluso un livello di persistenza che contiene il mapping.

Vorrei creare una classe UI / view separata per ogni pezzo che contiene le informazioni visive. Ognuna di queste classi pieceview ha un puntatore al suo modello / controparte commerciale che contiene la posizione e le regole di gioco del pezzo.

Quindi prendi una pedina per esempio:

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;
}

Ciò consente la completa separazione della logica e dell'interfaccia utente. È possibile passare il puntatore del pezzo logico a una classe di gioco che gestisca lo spostamento dei pezzi. L'unico inconveniente è che l'istanza dovrebbe avvenire in una classe UI.

Mi avvicinerei a questo facendo un Piecegenerico, dove il suo parametro è il tipo di un elenco che identifica il tipo di pezzo, ogni pezzo con un riferimento a un tale tipo. Quindi l'interfaccia utente potrebbe utilizzare una mappa dall'enumerazione come prima:

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); }

Questo ha due vantaggi interessanti:

In primo luogo, applicabile alla maggior parte delle lingue tipizzate staticamente: se parametrizzi la tua tavola con il tipo di pezzo su xpect, non puoi quindi inserire il tipo sbagliato di pezzo in esso.

In secondo luogo, e forse più interessante, se stai lavorando in Java (o in altri linguaggi JVM), dovresti notare che ogni valore enum non è solo un oggetto indipendente, ma può anche avere una sua classe. Ciò significa che è possibile utilizzare gli oggetti del tipo di pezzo come oggetti Strategia per personalizzare il comportamento del pezzo:

 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),
                    ....

(Ovviamente le implementazioni effettive devono essere più complesse di così, ma spero che tu abbia l'idea)

Sono un programmatore pragmatico e non mi interessa davvero cosa sia un'architettura pulita o sporca. Credo che i requisiti debbano essere gestiti in modo semplice.

Il tuo requisito è che la logica dell'app per gli scacchi sia rappresentata su diversi livelli di presentazione (dispositivi) come sul Web, sull'app mobile o persino sull'app console, quindi devi supportare questi requisiti. Puoi preferire l'uso di colori molto diversi, immagini dei pezzi su ciascun dispositivo.

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; }
}

Come hai visto, il parametro presenter deve essere passato su ciascun dispositivo (livello di presentazione) in modo diverso. Ciò significa che il tuo livello di presentazione deciderà come rappresentare ogni pezzo. Cosa c'è di sbagliato in questa soluzione?

C'è un'altra soluzione che ti aiuterà a sottrarre completamente l'interfaccia utente e la logica del dominio. La tua board dovrebbe essere esposta al tuo layer UI e il tuo layer UI può decidere come rappresentare pezzi e posizioni.

Per raggiungere questo obiettivo, è possibile utilizzare la stringa Fen . La stringa Fen è sostanzialmente informazione sullo stato della scheda e fornisce i pezzi correnti e le loro posizioni a bordo. Quindi la tua scheda può avere un metodo che restituisce lo stato corrente della scheda tramite la stringa Fen, quindi il tuo livello UI può rappresentare la scheda come desidera. Questo è come funzionano gli attuali motori di scacchi. I motori di scacchi sono un'applicazione console senza GUI ma li usiamo tramite GUI esterna. Il motore di scacchi comunica alla GUI tramite stringhe di fen e notazione di scacchi.

Mi stai chiedendo cosa succede se aggiungo un nuovo pezzo? Non è realistico che gli scacchi introdurranno un nuovo pezzo. Sarebbe un grande cambiamento nel tuo dominio. Quindi segui il principio YAGNI.