Bersihkan cara OOP memetakan objek ke presenternya

Saya membuat permainan papan (seperti catur) di Jawa, di mana masing-masing bagian adalah jenisnya sendiri (seperti Pawn, Rookdll.). Untuk bagian GUI dari aplikasi saya perlu gambar untuk masing-masing bagian ini. Sejak melakukan berpikir seperti

rook.image();

melanggar pemisahan UI dan logika bisnis, saya akan membuat presenter yang berbeda untuk masing-masing bagian dan kemudian memetakan jenis potongan ke penyaji yang sesuai seperti

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

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

Sejauh ini baik. Namun, saya merasakan guru OOP yang bijaksana akan mengerutkan kening ketika memanggil getClass()metode dan akan menyarankan menggunakan pengunjung misalnya seperti ini:

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

Saya suka solusi ini (terima kasih, guru), tetapi memiliki satu kelemahan signifikan. Setiap kali tipe bagian baru ditambahkan ke aplikasi, PieceVisitor perlu diperbarui dengan metode baru. Saya ingin menggunakan sistem saya sebagai kerangka permainan papan di mana potongan-potongan baru dapat ditambahkan melalui proses sederhana di mana pengguna kerangka kerja hanya akan memberikan implementasi baik karya dan presenternya, dan cukup tancapkan ke kerangka kerja. Pertanyaan saya: apakah ada solusi OOP yang bersih tanpa instanceof, getClass()dll. Yang memungkinkan perluasan jenis ini?

apakah ada solusi OOP bersih tanpa instanceof, getClass () dll. yang akan memungkinkan untuk ekstensibilitas seperti ini?

Ya ada.

Izinkan saya bertanya kepada Anda. Dalam contoh Anda saat ini, Anda menemukan cara untuk memetakan jenis potongan ke gambar. Bagaimana cara mengatasi masalah sepotong yang dipindahkan?

Teknik yang lebih kuat daripada bertanya tentang tipe adalah mengikuti Tell, jangan bertanya . Bagaimana jika masing-masing bagian menggunakan PiecePresenterantarmuka dan tampilannya seperti ini:

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

Konstruksi akan terlihat seperti ini:

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

Gunakan akan terlihat seperti:

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

Idenya di sini adalah untuk menghindari mengambil tanggung jawab untuk melakukan apa pun yang hal-hal lain bertanggung jawab dengan tidak bertanya tentang hal itu atau membuat keputusan berdasarkan itu. Alih-alih pegang referensi untuk sesuatu yang tahu apa yang harus dilakukan tentang sesuatu dan katakan itu untuk melakukan sesuatu tentang apa yang Anda ketahui.

Ini memungkinkan terjadinya polimorfisme. Anda tidak PEDULI dengan apa yang Anda bicarakan. Anda tidak peduli apa yang harus dikatakan. Anda hanya peduli bahwa itu dapat melakukan apa yang perlu Anda lakukan.

Diagram yang baik yang membuat ini di lapisan yang terpisah, mengikuti tell-don't-ask, dan menunjukkan bagaimana untuk tidak memasangkan layer ke layer secara tidak adil adalah ini :

Ia menambahkan lapisan use case yang belum pernah kami gunakan di sini (dan tentu saja dapat menambahkan) tetapi kami mengikuti pola yang sama seperti yang Anda lihat di sudut kanan bawah.

Anda juga akan melihat bahwa Presenter tidak menggunakan warisan. Ini menggunakan komposisi. Warisan harus menjadi cara terakhir untuk mendapatkan polimorfisme. Saya lebih suka desain yang disukai menggunakan komposisi dan delegasi. Mengetik keyboard sedikit lebih banyak tetapi lebih banyak daya.

Bagaimana dengan itu:

Model Anda (kelas angka) memiliki metode umum yang mungkin Anda perlukan dalam konteks lain juga:

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

Gambar yang akan digunakan untuk menampilkan gambar tertentu mendapatkan nama file dengan skema penamaan:

King-White.png
Queen-Black.png

Kemudian Anda dapat memuat gambar yang sesuai tanpa mengakses informasi tentang kelas java.

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

Saya juga tertarik pada solusi umum untuk masalah seperti ini ketika saya perlu melampirkan beberapa informasi (tidak hanya gambar) ke sekumpulan kelas yang berpotensi berkembang. "

Saya pikir Anda tidak harus fokus pada kelas sebanyak itu. Alih-alih berpikir dalam hal objek bisnis .

Dan solusi generik adalah pemetaan apa pun. Trik IMHO adalah memindahkan pemetaan itu dari kode ke sumber daya yang lebih mudah dipelihara.

Contoh saya melakukan pemetaan ini dengan konvensi yang cukup mudah diimplementasikan dan menghindari menambahkan informasi terkait tampilan ke dalam model bisnis . Di sisi lain Anda dapat menganggapnya sebagai pemetaan "tersembunyi" karena tidak diungkapkan di mana pun.

Pilihan lain adalah melihat ini sebagai kasus bisnis terpisah dengan lapisan MVC-nya sendiri termasuk lapisan ketekunan yang berisi pemetaan.

Saya akan membuat UI / view class yang terpisah untuk setiap bagian yang berisi informasi visual. Setiap salah satu dari kelas tampilan ini memiliki penunjuk ke model / rekan bisnisnya yang berisi posisi dan aturan permainan potongan tersebut.

Jadi, ambil pion misalnya:

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

Ini memungkinkan untuk pemisahan logika dan UI sepenuhnya. Anda bisa meneruskan pointer potongan logika ke kelas game yang akan menangani pemindahan potongan. Satu-satunya kelemahan adalah bahwa Instansiasi harus terjadi di kelas UI.

Saya akan mendekati ini dengan membuat Piecegenerik, di mana parameternya adalah jenis enumerasi yang mengidentifikasi jenis potongan, masing-masing bagian memiliki referensi ke satu jenis tersebut. Kemudian UI dapat menggunakan peta dari enumerasi seperti sebelumnya:

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

Ini memiliki dua keunggulan menarik:

Pertama, berlaku untuk sebagian besar bahasa yang diketik secara statis: Jika Anda menentukan papan Anda dengan tipe potongan untuk xpect, Anda tidak dapat memasukkan jenis potongan yang salah ke dalamnya.

Kedua, dan mungkin lebih menarik, jika Anda bekerja di Jawa (atau bahasa JVM lainnya), Anda harus mencatat bahwa setiap nilai enum bukan hanya objek independen, tetapi juga dapat memiliki kelasnya sendiri. Ini berarti bahwa Anda dapat menggunakan objek jenis potongan Anda sebagai objek Strategi untuk memberi pelanggan perilaku potongan:

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

(Jelas implementasi yang sebenarnya harus lebih kompleks dari itu, tetapi mudah-mudahan Anda mendapatkan ide)

Saya seorang programmer pragmatis dan saya benar-benar tidak peduli apa itu arsitektur yang bersih atau kotor. Saya percaya persyaratan dan itu harus ditangani dengan cara sederhana.

Persyaratan Anda adalah logika aplikasi catur Anda akan diwakili di berbagai lapisan presentasi (perangkat) seperti di web, aplikasi seluler, atau bahkan aplikasi konsol sehingga Anda perlu mendukung persyaratan ini. Anda mungkin lebih suka menggunakan warna yang sangat berbeda, membuat gambar pada setiap perangkat.

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

Seperti yang Anda lihat, parameter presenter harus diteruskan pada setiap perangkat (lapisan presentasi) secara berbeda. Itu berarti lapisan presentasi Anda akan memutuskan bagaimana untuk mewakili setiap bagian. Apa yang salah dalam solusi ini?

Ada solusi lain yang akan membantu Anda untuk abstrak UI dan logika domain sepenuhnya. Papan Anda harus diekspos ke lapisan UI Anda dan lapisan UI Anda dapat memutuskan bagaimana cara mewakili bagian dan posisi.

Untuk mencapai ini, Anda dapat menggunakan string Fen . String Fen pada dasarnya adalah informasi keadaan papan dan memberikan potongan saat ini dan posisi mereka di papan tulis. Jadi papan Anda dapat memiliki metode yang mengembalikan keadaan papan saat ini melalui string Fen maka lapisan UI Anda dapat mewakili papan sesuai keinginan. Inilah sebenarnya cara kerja mesin catur saat ini. Mesin catur adalah aplikasi konsol tanpa GUI tetapi kami menggunakannya melalui GUI eksternal. Mesin catur berkomunikasi dengan GUI melalui string fen dan notasi catur.

Anda bertanya bagaimana jika saya menambahkan bagian baru? Tidak realistis bahwa catur akan memperkenalkan karya baru. Itu akan menjadi perubahan besar di domain Anda. Jadi ikuti prinsip YAGNI.