Làm sạch cách OOP ánh xạ một đối tượng đến người trình bày của nó

Tôi đang tạo một trò chơi cờ (như cờ vua) trong Java, trong đó mỗi quân cờ là loại riêng của nó (như Pawn, Rookv.v.). Đối với phần GUI của ứng dụng, tôi cần một hình ảnh cho mỗi phần này. Kể từ khi làm như nghĩ

rook.image();

vi phạm sự tách biệt giữa UI và logic nghiệp vụ, tôi sẽ tạo một người thuyết trình khác nhau cho mỗi phần và sau đó ánh xạ các loại phần cho người thuyết trình tương ứng của họ như

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

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

Càng xa càng tốt. Tuy nhiên, tôi cảm thấy một bậc thầy OOP khôn ngoan sẽ cau mày khi gọi một getClass()phương thức và sẽ đề nghị sử dụng một khách truy cập chẳng hạn như thế này:

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

Tôi thích giải pháp này (cảm ơn bạn, guru), nhưng nó có một nhược điểm đáng kể. Mỗi khi một loại mảnh mới được thêm vào ứng dụng, PieceVisitor cần được cập nhật với một phương thức mới. Tôi muốn sử dụng hệ thống của mình làm khung trò chơi hội đồng, nơi các phần mới có thể được thêm vào thông qua một quy trình đơn giản trong đó người dùng của khung sẽ chỉ cung cấp triển khai cả phần và người trình bày của nó, và chỉ cần cắm nó vào khung. Câu hỏi của tôi: có một giải pháp OOP sạch mà không có instanceof, getClass()vv sẽ cho phép loại mở rộng này?

Có một giải pháp OOP sạch mà không có instanceof, getClass (), v.v ... sẽ cho phép loại mở rộng này không?

Có, có.

Hãy để tôi hỏi bạn điều này. Trong các ví dụ hiện tại của bạn, bạn đang tìm cách ánh xạ các loại mảnh thành hình ảnh. Làm thế nào để giải quyết vấn đề của một mảnh được di chuyển?

Một kỹ thuật mạnh hơn so với hỏi về loại là làm theo Tell, đừng hỏi . Điều gì sẽ xảy ra nếu mỗi phần lấy một PiecePresentergiao diện và nó trông như thế này:

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

Việc xây dựng sẽ trông giống như thế này:

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

Sử dụng sẽ trông giống như:

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

Ý tưởng ở đây là để tránh chịu trách nhiệm làm bất cứ điều gì mà những thứ khác chịu trách nhiệm bằng cách không hỏi về nó cũng như không đưa ra quyết định dựa trên nó. Thay vào đó hãy tham khảo một cái gì đó biết phải làm gì về một cái gì đó và bảo nó làm gì đó về những gì bạn biết.

Điều này cho phép đa hình. Bạn không CHĂM SÓC những gì bạn đang nói chuyện. Bạn không quan tâm những gì nó nói. Bạn chỉ cần quan tâm rằng nó có thể làm những gì bạn cần làm.

Một sơ đồ tốt giữ các lớp này trong các lớp riêng biệt, tuân theo câu hỏi không hỏi và chỉ ra làm thế nào để không ghép lớp này thành lớp một cách bất công là đây :

Nó thêm một lớp ca sử dụng mà chúng tôi chưa sử dụng ở đây (và chắc chắn có thể thêm) nhưng chúng tôi đang theo cùng một mẫu bạn nhìn thấy ở góc dưới bên phải.

Bạn cũng sẽ nhận thấy rằng Người trình bày không sử dụng quyền thừa kế. Nó sử dụng thành phần. Kế thừa nên là cách cuối cùng để có được đa hình. Tôi thích các thiết kế ủng hộ sử dụng thành phần và ủy quyền. Nó gõ bàn phím nhiều hơn một chút nhưng nó mạnh hơn rất nhiều.

Thế còn

Mô hình của bạn (các lớp hình) cũng có một phương thức phổ biến mà bạn có thể cần trong ngữ cảnh khác:

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

Các hình ảnh được sử dụng để hiển thị một hình nhất định có được tên tệp bằng lược đồ đặt tên:

King-White.png
Queen-Black.png

Sau đó, bạn có thể tải hình ảnh phù hợp mà không cần truy cập thông tin về các lớp java.

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

Tôi cũng quan tâm đến giải pháp chung cho loại vấn đề này khi tôi cần đính kèm một số thông tin (không chỉ hình ảnh) vào một nhóm các lớp có khả năng phát triển. "

Tôi nghĩ bạn không nên tập trung vào các lớp học nhiều như vậy. Thay vì nghĩ về các đối tượng kinh doanh .

Và giải pháp chung là một bản đồ của bất kỳ loại nào. IMHO mẹo là di chuyển ánh xạ từ mã sang tài nguyên dễ bảo trì hơn.

Ví dụ của tôi thực hiện ánh xạ này theo quy ước khá dễ thực hiện và tránh thêm thông tin liên quan vào mô hình kinh doanh . Mặt khác, bạn có thể coi nó là một ánh xạ "ẩn" vì nó không được thể hiện ở bất cứ đâu.

Một tùy chọn khác là xem đây là một trường hợp kinh doanh riêng biệt với các lớp MVC riêng bao gồm một lớp kiên trì có chứa ánh xạ.

Tôi sẽ tạo một lớp UI / view riêng cho từng phần chứa thông tin trực quan. Mỗi một trong các lớp pieceview này có một con trỏ tới mô hình / đối tác kinh doanh của nó chứa vị trí và quy tắc trò chơi của tác phẩm.

Vì vậy, hãy cầm đồ chẳng hạn:

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

Điều này cho phép tách hoàn toàn logic và UI. Bạn có thể chuyển con trỏ mảnh logic đến một lớp trò chơi sẽ xử lý việc di chuyển các mảnh. Hạn chế duy nhất là việc khởi tạo sẽ phải xảy ra trong lớp UI.

Tôi sẽ tiếp cận điều này bằng cách tạo ra Piecechung chung, trong đó tham số của nó là kiểu liệt kê xác định loại mảnh, mỗi mảnh có tham chiếu đến một loại như vậy. Sau đó, UI có thể sử dụng bản đồ từ bảng liệt kê như trước:

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

Điều này có hai lợi thế thú vị:

Đầu tiên, áp dụng cho hầu hết các ngôn ngữ được nhập tĩnh: Nếu bạn đặt bảng của bạn với loại mảnh thành xpect, thì bạn không thể chèn loại mảnh sai vào đó.

Thứ hai, và có lẽ thú vị hơn, nếu bạn đang làm việc trong Java (hoặc các ngôn ngữ JVM khác), bạn nên lưu ý rằng mỗi giá trị enum không chỉ là một đối tượng độc lập mà còn có thể có lớp riêng. Điều này có nghĩa là bạn có thể sử dụng các đối tượng loại mảnh của mình làm đối tượng Chiến lược để khách hàng hành vi của mảnh:

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

(Rõ ràng việc triển khai thực tế cần phức tạp hơn thế, nhưng hy vọng bạn có ý tưởng)

Tôi là một lập trình viên thực dụng và tôi thực sự không quan tâm kiến ​​trúc sạch hay bẩn là gì. Tôi tin rằng các yêu cầu và nó nên được xử lý cách đơn giản.

Yêu cầu của bạn là logic ứng dụng cờ vua của bạn sẽ được thể hiện trên các lớp trình bày (thiết bị) khác nhau như trên web, ứng dụng di động hoặc thậm chí ứng dụng bảng điều khiển để bạn cần hỗ trợ các yêu cầu này. Bạn có thể thích sử dụng màu sắc rất khác nhau, hình ảnh mảnh trên mỗi thiết bị.

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

Như bạn đã thấy tham số của người thuyết trình nên được truyền trên mỗi thiết bị (lớp trình bày) khác nhau. Điều đó có nghĩa là lớp trình bày của bạn sẽ quyết định cách thể hiện từng phần. Điều gì là sai trong giải pháp này?

Có một giải pháp khác sẽ giúp bạn trừu tượng hóa hoàn toàn UI và tên miền logic. Bảng của bạn phải được tiếp xúc với lớp UI và lớp UI của bạn có thể quyết định cách thể hiện các phần và vị trí.

Để đạt được điều này, bạn có thể sử dụng chuỗi Fen . Chuỗi Fen về cơ bản là thông tin trạng thái của bảng và nó cung cấp cho các mảnh hiện tại và vị trí của chúng trên tàu. Vì vậy, bảng của bạn có thể có một phương thức trả về trạng thái hiện tại của bảng thông qua chuỗi Fen, sau đó lớp UI của bạn có thể đại diện cho bảng theo ý muốn. Đây thực sự là cách các động cơ cờ vua hiện tại hoạt động. Công cụ cờ vua là ứng dụng bàn điều khiển không có GUI nhưng chúng tôi sử dụng chúng thông qua GUI bên ngoài. Công cụ cờ vua giao tiếp với GUI thông qua chuỗi fen và ký hiệu cờ vua.

Bạn đang hỏi rằng nếu tôi thêm một mảnh mới thì sao? Nó không thực tế rằng cờ vua sẽ giới thiệu một quân cờ mới. Đó sẽ là thay đổi lớn trong miền của bạn. Vì vậy, hãy làm theo nguyên tắc YAGNI.