Come modellare sotto Gerarchia con OOP

Question

Come modellare sotto Gerarchia con OOP

#1 da (1 voti)

-1

Nota che non posso utilizzare l'ereditarietà statica a causa delle limitazioni della lingua (Java).

Esiste una classe di costruzione generale. Ogni istanza di Building ha proprietà che esistono indipendentemente dalle variabili di istanza (come larghezza, lunghezza, livello massimo, danno BASE). Esistono numerosi tipi di edifici, come risorse e difensive, e all'interno di questi tipi ci sono gli edifici reali che un utente costruisce (come un mulino o un cannone).

Il problema è l'ereditarietà statica. Non posso richiedere sottotipi di Building per avere le proprietà statiche sopra menzionate.

Cosa ho provato:

1) Uso del pattern singleton per simulare l'ereditarietà statica (in modo efficace, i pattern di istanza di una classe che ha un'istanza hanno la stessa funzionalità di static). Tuttavia, ho bisogno di capacità di generare istanze di edifici sul posto (come quando un utente costruisce un segheria, che avrebbe un livello corrente che fa parte dell'istanza, non della classe). Pertanto, questo era inefficace.

2) Usare enum per rappresentare tutti gli edifici (quindi questi enumerri sarebbero LUMBERMILL , ARCHER_TOWER , ecc.). Tuttavia, ancora una volta, ho bisogno della possibilità di creare più istanze di questi tipi di edifici. Le enumerazioni sono funzionalmente equivalenti ai campi statici pubblici, pertanto non è possibile creare più istanze.

Vale la pena ricordare che sto usando Java, quindi se alcune soluzioni richiedono la creazione di istanze di tipi generici disponibili in fase di runtime, non sono in grado di farlo.

Come posso simulare questa ricerca usando OOP?

object-oriented java inheritance static

posta Mar Dev 16.04.2018 - 03:36

fonte

1 risposta

Leggi altre domande sui tag object-oriented java inheritance static

Esistono metodi per mappare il flusso di un programma? [chiuso] Perché utilizzare le istruzioni using quando si desidera riaprire le connessioni? [chiuso]

score 1 · Answer 1

Quindi, hai alcune proprietà legate a un tipo di edificio e alcune proprietà che sono legate a un'istanza di un edificio.

Questo tipo di struttura di classe funzionerebbe:

public class Building {
    private final BuildingType type;
    private int level;
    private int damage;
    // properties of a building
    ...
}

public enum BuildingType {
    LUMBERMILL(5, 4, 3, 0, ...), 
    ARCHER_TOWER(2, 2, 5, 100, ...),
    ...;
    private final int width;
    private final int length;
    private final int maxLevel;
    private final int baseDamage;
    // properties tied to the type of buildings
    ...
    private BuildingType(int width, int length, int maxLevel, int baseDamage, ...) {
        this.width = width;
        this.length = length;
        this.maxLevel = maxLevel;
        this.baseDamage = baseDamage;
        ...
    }
}

L'enum BuildingType può essere modificato in una classe regolare per consentire la creazione di nuovi tipi di edifici in modo dinamico e per consentire lo spostamento dei dati dal codice sorgente ai file di dati, che è spesso preferibile.

Se esistessero alcune restrizioni globali ai valori di alcuni attributi - ad esempio, se il valore di baseDamage dovesse essere maggiore di zero - allora tali restrizioni potrebbero essere aggiunte nella parte che inizializza un tipo di edificio.

Se la classe BuildingType è un enum (come sopra), non vedo alcun beneficio nel farlo. È solo un codice che verifica che alcune righe del codice 20 non contengano errori di digitazione. Non è molto produttivo. Se, tuttavia, gli attributi di BuildingTypes sono stati letti da un file di dati, dovrebbe esserci il codice che controlla i valori rispetto a tali restrizioni.

Se il tuo sistema di tipi di edifici ha una gerarchia, allora hai bisogno che le tue classi rappresentino quella gerarchia. Tuttavia, consiglierei di usare la composizione invece dell'ereditarietà a meno che non sia coinvolto un qualche comportamento polimorfico. Dovresti cercare di evitare la necessità di controllare il tipo di un oggetto in fase di runtime.

Una soluzione semplice potrebbe avere questo aspetto:

public class Building {
    private final BuildingType type;
    ...
}

public class BuildingType {
    private final BuildingClass class;
    ...
}

public class BuildingClass {
    private final BuildingClass parentClass;
    ...
}

Questo design consentirebbe una gerarchia arbitrariamente profonda di tipi di edifici. Ogni classe di edifici e ogni tipo di edificio potrebbe contenere alcuni dati.

Ad esempio, un'istanza di una miniera di carbone potrebbe avere quattro oggetti coinvolti:

Edificio: l'istanza specifica della miniera di carbone
BuildingType: miniera di carbone
BuildingClass: production / mine (due oggetti per due livelli di gerarchia)