Questi tipi di domande sono difficili da rispondere senza conoscere l'intero contesto, ma dalla tua descrizione vedo che Robot è un oggetto mutabile. Hai un robot che si muove attraverso la griglia, non hai un robot che appare in una certa posizione e viene distrutto su quello vecchio.

Il Robot ha un position . Questa può essere una tupla (immutabile) o solo due proprietà del numero sul robot. La posizione può essere modificata con un metodo moveTo sul robot. Il robot ha un direction . Quindi questi sono stati del robot.

Apart from the obvious performance issues and any language-specific considerations, what factors should I consider when deciding whether to make Robot instances mutable (methods modify state) or immutable.

L'unica cosa da considerare è se nelle simulazioni eseguite, il robot viene utilizzato da più thread. Se è necessario sincronizzare l'accesso al suo stato o pensa di renderlo immutabile.

It only has two methods (apart from constructor): it can move one step in its direction, or rotate by 90, 180 or 270 degrees.

Questa è una svolta. Urla immutabile. Perché? Perché il tempo può essere rimosso.

On the other hand, when I think of a robot, the natural picture in my mind is a movable thing, which would correspond to a mutable object.

Quando guardiamo film vediamo cose mobili dappertutto. Eppure ogni immagine è una cosa immobile immobile. Ciò che sembra e come funziona non deve essere la stessa cosa.

Essere immutabili ha benefici oltre la concorrenza. Inoltre ha un costo. Questa scelta ha implicazioni per lo scambio di spazi temporali, la memorizzazione nella cache e la convalida dello stato.

Senza conoscere i dettagli della tua simulazione, ne so abbastanza dei benefici degli oggetti immutabili per incoraggiarti ad usarne il più possibile. Quando sarai andato lontano, lo saprai. È quando non sei andato abbastanza lontano da essere trattato con brutte sorprese.

when I think of a robot, the natural picture in my mind is a movable thing, which would correspond to a mutable object ... it's not hard for me to overcome this mental association

Sembra che tu stia cercando di forzare l'immutabilità, piuttosto che usarla come strumento per risolvere un problema.

Tipi immutabili con metodi "mutabili"

Un tipo immutabile con metodi "mutabili" alza una bandiera, e ci sono pochissime situazioni in cui effettivamente serve a scopi benefici. A parte queste poche situazioni, di solito causa problemi / confusioni ( String è un buon esempio, con i principianti che non capiscono che toLowercase() crea effettivamente un nuovo oggetto).

La tua idea che Position sia immutabile a causa della sua natura statica è una buona idea, ma ciò non significa che dovrebbe avere metodi che restituiscono nuove istanze di Position .

Suddivisione logica della tua situazione

Position oggetti dovrebbero esistere composti da un qualche tipo di Grid . Quando una Robot si sposta in una nuova posizione sulla griglia, il robot dovrebbe avere un riferimento a quella posizione.

Se per qualche motivo vuoi che Robot abbia la propria posizione indipendente che è soggetta a modifiche, non dovresti considerarla immutabile, dato che il robot non sta creando posizioni, ma semplicemente regolando la sua posizione in modo che corrisponda alla posizione target.

Pensa sempre ai "pro" e ai "contro"

Apart from the obvious performance issues

Se sei consapevole che ci saranno problemi di prestazioni, dovresti assolutamente capire e valutare i benefici ottenuti dalla tua decisione. Sembra che tu non riesca a trovarlo, l'unico ragionamento è "Non è difficile immaginare questo scenario nella mia testa". Probabilmente è meglio concentrarsi sui pro e contro di un determinato design, piuttosto che su quello che meglio replica il mondo reale.

" Non pensarci da una prospettiva del mondo reale " era una brutta scelta di parole. Quello che intendevo era " Non lasciare che i tentativi di replica del mondo reale influenzino la gestibilità e le prestazioni del tuo software ". Solo perché puoi immaginarlo non significa che sia il migliore per un ambiente software.

(Questo è originariamente inteso per introdurre l'immutabilità ai lettori di fantascienza, quindi è scritto in modo non rigoroso.)

Puoi utilizzare l'oggetto immutabile se hai bisogno di pianificazione del movimento basata sulla ricerca.

In questo disegno, quanto segue è immutabile:

• A tempo T ,
• Il robot è in posizione X , Y ,
• Direzione del fronte D .

Ci saranno molte istanze di oggetti immutabili nell'albero di ricerca. Ma per ogni tempo T fino ad oggi (vale a dire passato o presente), ci sarà esattamente una di queste istanze che riflette il percorso della storia del movimento del robot. Tutte le altre istanze saranno contemplazione di ciò che accadrebbe se il robot avesse scelto di spostarsi in modi diversi in diversi punti temporali.

Il tempo presente è T , quindi ogni istanza che ha un tempo maggiore di T è una contemplazione, poiché quel tempo futuro non è ancora successo.

Questo ti dà un universo parallelo , parlando in senso fantascientifico.

Un'istanza al tempo T+1 avrà bisogno di un link principale che si riferisce a un'istanza preesistente al tempo T . Questo link spiega come il robot potrebbe arrivare al suo stato a T+1 facendo uno spostamento da una posizione precedente a T .

Puoi usarlo come ricerca per il grafico o per lo scopo di trovare il percorso.