Sto creando un gioco da tavolo (come gli scacchi) in Java, in cui ogni pezzo è di tipo proprio (come Pawn , Rook ecc.). Per la parte GUI dell'applicazione ho bisogno di un'immagine per ognuno 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 pezzi ai corrispondenti 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 prudente guru OOP aggrotta le sopracciglia chiamando un metodo getClass() e suggerirebbe di utilizzare un visitatore ad esempio in questo modo:
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, PezzoVisitor deve essere aggiornato con un nuovo metodo. Mi piacerebbe usare il mio sistema come una struttura di gioco da tavolo in cui nuovi pezzi potrebbero essere aggiunti attraverso un semplice processo in cui l'utente del framework fornirebbe solo l'implementazione sia del pezzo che del suo presentatore, e semplicemente collegarlo al framework. La mia domanda: esiste una soluzione OOP pulita senza instanceof , getClass() ecc. Che consentirebbe questo tipo di estensibilità?
