sottoclasse di oggetto immutabile non immutabile, può funzionare?

Question

sottoclasse di oggetto immutabile non immutabile, può funzionare?

#1 da (6 voti)
#2 da (0 voti)

3

Quindi sto finendo di refactoring del codice per rimuovere un numero di oggetti precedentemente modificabili e aggiungere un'elaborazione generica migliore per tutte le classi nel dominio. Proprio mentre pensavo di finire mi sono reso conto che esiste una sottoclasse con uno stato aggiuntivo.

Lo stato aggiuntivo è un collegamento ad altre classi che vengono utilizzate come parte della logica per sapere quando verranno creati, cancellati o modificati nuovi oggetti di dominio. Tuttavia, questa sottoclasse viene creata solo all'avvio o quando qualcuno esegue un comando per rileggere e aggiornare i nuovi file di configurazione. So che questo oggetto always deve essere creato prima che uno qualsiasi degli altri oggetti nel mio dominio dipendano da esso, in modo tale che chiunque indichi questo oggetto sia tutto gaurenteed per puntare alla stessa istanza. Ho effettivamente il pattern di Memorizzazione per un incidente di come viene creata la struttura.

Potrei rifattorizzare la mutabilità; ma richiederebbe un po 'di lavoro modificando la logica di avvio che preferirei evitare. Oppure potrei cambiare i metodi has and equals per ignorare questo insieme di valori mutabili così il mio modello tratterà questo oggetto esattamente come se fosse un genitore immutabile e confido che la mia conoscenza del metodo che è stato costruito mi impedisca di creare problemi di aliasing quando cerco di usa i suoi tratti mutabili.

Quindi come 'sbagliato' è piegare il mio contratto per la classe in questo modo essere?

design mutable

posta dsollen 10.05.2013 - 01:08

fonte

2 risposte

0

È legittimo, ea volte utile, avere un sottotipo di un tipo mutabile che include informazioni aggiuntive immutabili non presenti nella base. È anche legittimo che un sottotipo aggiunga membri mutabili a un tipo i cui membri di base siano immutabili, a condizione che il tipo di base non dia alcuna promessa circa l'immutabilità di qualsiasi membro diverso dal proprio. È generalmente illegittimo per sottotipi di un tipo che promette l'immutabilità di aggiungere uno stato visibilmente mutevole, indipendentemente dal fatto che lo stato possa essere osservato attraverso un riferimento di tipo .

Il problema è che una garanzia di immutabilità implica generalmente una garanzia che la persistenza di un riferimento a un oggetto è equivalente al persistere dello stato dell'oggetto e che i riferimenti all'oggetto possono essere liberamente condivisi come mezzo per condividere lo stato corrente. Tali garanzie non saranno valide se l'oggetto ha uno stato mutabile, indipendentemente dal fatto che tale stato sia visibile attraverso un riferimento di classe base.

Quello che suggerirei come approccio è avere un tipo ReadableFoo astratto, con MutableFoo e ImmutableFoo sottotipi. Potrebbe essere utile avere AsMutable , AsNewMutable e AsImmutable metodi astratti nel tipo base in modo che un oggetto che ha ricevuto ReadableFoo possa utilizzarlo come previsto.

risposta data 17.01.2014 - 20:19

fonte

Leggi altre domande sui tag design mutable

Gestione di innovazioni rivoluzionarie in un sistema di produzione - Inserisci oggetto di gestione di livello intermedio setSoftInputMode rispetto a InputMethodManager

score 6 · Accepted Answer

Non c'è nulla di intrinsecamente sbagliato nelle sottoclassi mutabili, a condizione che non si facciano ipotesi sulla mutabilità in altre parti del codice.

Ad esempio, il framework Foundation che fa parte dei framework Cocoa e Cocoa Touch (rispettivamente MacOS X e iOS) ha un numero di contenitori di dati immutabili con sottoclassi mutabili. NSMutableArray è una sottoclasse mutabile di% co_de immutabile, NSArray è una sottoclasse mutabile di% co_de immutabile, ecc.

Funziona bene se pensi alla mutabilità come a una caratteristica aggiunta piuttosto che a qualcosa che deve essere rimosso dalla superclasse. Ancora più importante, il codice client non dovrebbe mai provare a apportare modifiche a un oggetto pubblicizzato come immutabile, anche se l'oggetto sembra essere un'istanza di una sottoclasse mutabile.

Quindi, se un metodo restituisce un NSMutableDictionary , potresti effettivamente recuperare un'istanza di NSDictionary , ma dovresti sempre considerarlo comunque immutabile.