Aggirare le regole in Wizards and Warriors

In questa serie di post sul blog , Eric Lippert descrive un problema nella progettazione orientata agli oggetti usando maghi e guerrieri come esempi, dove:

abstract class Weapon { }
sealed class Staff : Weapon { }
sealed class Sword : Weapon { }

abstract class Player 
{ 
  public Weapon Weapon { get; set; }
}
sealed class Wizard : Player { }
sealed class Warrior : Player { }

e quindi aggiunge un paio di regole:

• Un guerriero può usare solo una spada.
• Un mago può usare solo uno staff.

Quindi continua a dimostrare i problemi che si incontrano se si tenta di applicare queste regole utilizzando il sistema di tipo C # (ad esempio, rendere la Wizardclasse responsabile per assicurarsi che un mago possa usare solo uno staff). Si viola il principio di sostituzione di Liskov, si rischiano eccezioni di runtime o si finisce con un codice che è difficile da estendere.

La soluzione che propone è che la classe Player non convalida. Viene utilizzato solo per tenere traccia dello stato. Quindi, invece di dare a un giocatore un'arma:

player.Weapon = new Sword();

lo stato è modificato da se Commandsecondo Rules:

... creiamo un Commandoggetto chiamato Wieldche prende due oggetti di stato del gioco, a Playere a Weapon. Quando l'utente invia un comando al sistema "questa procedura guidata dovrebbe brandire quella spada", quel comando viene valutato nel contesto di un insieme di Rules, che produce una sequenza di Effects. Ne abbiamo uno Ruleche dice che quando un giocatore tenta di impugnare un'arma, l'effetto è che l'arma esistente, se ce n'è una, viene lasciata cadere e la nuova arma diventa l'arma del giocatore. Abbiamo un'altra regola che rafforza la prima regola, che dice che gli effetti della prima regola non si applicano quando un mago cerca di impugnare una spada.

Mi piace questa idea in linea di principio, ma ho una preoccupazione su come potrebbe essere utilizzata nella pratica.

Nulla sembra impedire a uno sviluppatore di aggirare il Commandse Rulesemplicemente impostando il parametro Weapona a Player. La Weaponproprietà deve essere accessibile dal Wieldcomando, quindi non può essere effettuata private set.

Allora, che cosa fa impedire che uno sviluppatore di fare questo? Devono solo ricordare di non farlo?

L'intero argomento a cui portano serie di post sul blog è nella parte cinque :

Non abbiamo motivo di credere che il sistema di tipo C # sia stato progettato per avere una generalità sufficiente per codificare le regole di Dungeons & Dragons, quindi perché ci stiamo provando?

Abbiamo risolto il problema di "dove va il codice che esprime le regole del sistema?" Va negli oggetti che rappresentano le regole del sistema, non negli oggetti che rappresentano lo stato del gioco; la preoccupazione degli oggetti di stato è mantenere il loro stato coerente, non nel valutare le regole del gioco.

Armi, personaggi, mostri e altri oggetti di gioco non sono responsabili del controllo di ciò che possono o non possono fare. Il sistema di regole è responsabile di ciò. Anche l' Commandoggetto non sta facendo nulla con gli oggetti di gioco. Rappresenta solo il tentativo di fare qualcosa con loro. Il sistema di regole controlla quindi se il comando è possibile e quando è il sistema di regole esegue il comando chiamando i metodi appropriati sugli oggetti di gioco.

Se uno sviluppatore vuole creare un secondo sistema di regole che fa cose con personaggi e armi che il primo sistema di regole non consentirebbe, può farlo perché in C # non puoi (senza cattivi hack di riflessione) scoprire dove arriva una chiamata al metodo a partire dal.

Una soluzione alternativa che potrebbe funzionare in alcune situazioni consiste nel mettere gli oggetti di gioco (o le loro interfacce) in un assieme con il motore delle regole e contrassegnare tutti i metodi mutatore come internal. Tutti i sistemi che richiedono l'accesso in sola lettura agli oggetti di gioco si troverebbero in un assembly diverso, il che significa che sarebbero in grado di accedere solo ai publicmetodi. Questo lascia ancora la scappatoia degli oggetti di gioco che si chiamano reciprocamente i metodi interni. Ma farlo sarebbe evidente odore di codice, perché hai concordato che le classi di oggetti di gioco dovrebbero essere titolari di stato stupido.

L'ovvio problema del codice originale è che sta eseguendo la modellazione dei dati anziché la modellazione degli oggetti . Si prega di notare che non vi è assolutamente alcuna menzione dei requisiti aziendali reali nell'articolo collegato!

Vorrei iniziare cercando di ottenere effettivi requisiti funzionali. Ad esempio: "Qualsiasi giocatore può attaccare qualsiasi altro giocatore, ...". Qui:

interface Player {
    void Attack(Player enemy);
}

"I giocatori possono impugnare un'arma che viene utilizzata nell'attacco, i Maghi possono impugnare uno Staff, Warriors a Sword":

public class Wizard: Player {
    ...
    public void Wield(Staff weapon) { ... }
    ...
}
public class Warrior: Player {
    ...
    public void Wield(Sword sword) { ... }
    ...
}

"Ogni arma infligge danni al nemico attaccato". Ok, ora dobbiamo avere un'interfaccia comune per Weapon:

interface Weapon {
    void dealDamageTo(Player enemy);
}

E così via ... Perché non c'è Wield()in Player? Perché non era richiesto che nessun giocatore potesse maneggiare un'arma.

Posso immaginare che ci sarebbe un requisito che dice: "Qualcuno Playerpuò provare a maneggiarne uno Weapon". Questa sarebbe comunque una cosa completamente diversa. Lo modellerei forse in questo modo:

interface Player {
    void Attack(Player enemy);
    void TryWielding(Weapon weapon); // Throws UnwieldableException
}

Riepilogo: modellare i requisiti e solo i requisiti. Non eseguire la modellazione dei dati, che non è oo modellazione.

Un modo sarebbe quello di passare il Wieldcomando a Player. Il giocatore quindi esegue il Wieldcomando, che controlla le regole appropriate e restituisce il Weapon, con cui Playerquindi imposta il proprio campo Arma. In questo modo, il campo Arma può avere un setter privato ed è settabile solo passando un Wieldcomando al giocatore.

Nulla impedisce allo sviluppatore di farlo. In realtà Eric Lippert ha provato molte tecniche diverse ma tutte avevano punti deboli. Questo era il punto centrale di quella serie che impedire allo sviluppatore di farlo non è facile e tutto ciò che ha provato ha avuto degli svantaggi. Alla fine ha deciso che usare un Commandoggetto con regole è la strada da percorrere.

Con le regole, puoi impostare la Weaponproprietà di Wizarda come a Swordma quando chiedi Wizarddi impugnare l'arma (Spada) e attaccarla non avrà alcun effetto e quindi non cambierà alcuno stato. Come dice di seguito:

Abbiamo un'altra regola che rafforza la prima regola, che dice che gli effetti della prima regola non si applicano quando un mago tenta di impugnare una spada. Gli effetti per quella situazione sono “emettono un suono trombone triste, l'utente perde la sua azione in questo turno, nessuno stato del gioco è mutato

In altre parole, non possiamo applicare tale regola attraverso typerelazioni che ha provato in molti modi diversi, ma o non gli piaceva o non funzionava. Quindi l'unica cosa che ha detto che possiamo fare è fare qualcosa al momento dell'esecuzione. Lanciare un'eccezione non era un bene perché non la considera un'eccezione.

Alla fine ha scelto di andare con la soluzione di cui sopra. Questa soluzione in sostanza dice che puoi impostare qualsiasi arma ma quando la produci, se non l'arma giusta, sarebbe essenzialmente inutile. Ma nessuna eccezione sarebbe generata.

Penso che sia una buona soluzione. Anche se in alcuni casi andrei anche con lo schema try-set.

La prima soluzione scartata dall'autore era quella di rappresentare le regole dal sistema dei tipi. Il sistema di tipi viene valutato in fase di compilazione. Se si staccano le regole dal sistema di tipi, non vengono più verificate dal compilatore, quindi non c'è nulla che impedisca a uno sviluppatore di commettere un errore di per sé.

Ma questo problema è affrontato da ogni pezzo di logica / modellazione che non è verificato dal compilatore e la risposta generale a questo è il test (unitario). Pertanto, la soluzione proposta dall'autore richiede un forte cablaggio di prova per eludere gli errori degli sviluppatori. Per sottolineare questo punto di necessità di un forte cablaggio di prova per errori che possono essere rilevati solo in fase di esecuzione, guarda questo articolo di Bruce Eckel, che sostiene che è necessario scambiare la tipizzazione forte per test più forti in linguaggi dinamici.

In conclusione, l'unica cosa che può impedire agli sviluppatori di commettere errori è avere una serie di test (unit) per verificare che tutte le regole vengano rispettate.

Potrei aver perso una sottigliezza qui, ma non sono sicuro che il problema riguardi il sistema dei tipi. Forse è con convenzione in C #.

Ad esempio, è possibile rendere completamente sicuro questo tipo rendendo Weaponprotetto il setter Player. Quindi aggiungere setSword(Sword)e setStaff(Staff)ad Warriore Wizard, rispettivamente, quella chiamata il setter protetto.

In questo modo, la relazione Player/ Weaponviene controllata staticamente e il codice a cui non importa può semplicemente usare a Playerper ottenere a Weapon.

Quindi, cosa impedisce a uno sviluppatore di farlo? Devono solo ricordare di non farlo?

Questa domanda è effettivamente la stessa con l'argomento piuttosto di guerra santa chiamato " dove mettere la convalida " (molto probabilmente notando anche ddd).

Quindi, prima di rispondere a questa domanda, dovresti chiederti: qual è la natura delle regole che vuoi seguire? Sono scolpiti nella pietra e definiscono l'entità? La violazione di queste regole fa sì che un'entità smetta di essere quello che è? Se sì, insieme a mantenere queste regole nella convalida dei comandi , inseriscile anche in un'entità. Pertanto, se uno sviluppatore dimentica di convalidare il comando, le entità non si troveranno in uno stato non valido.

Se no - beh, implica intrinsecamente che queste regole sono specifiche del comando e non devono risiedere in entità di dominio. Pertanto, la violazione di queste regole comporta un'azione che non avrebbe dovuto essere consentita, ma non in uno stato di modello non valido.