Esiste un modello di fabbrica per prevenire istanze multiple per lo stesso oggetto (istanza uguale a Equal)?

3

Ho un numero di oggetti che memorizzano lo stato. Esistono essenzialmente due tipi di campi. Quelli che definiscono in modo univoco cos'è l'oggetto (quale nodo, quale spigolo ecc.) E gli altri che memorizzano lo stato descrivendo come queste cose sono connesse (questo nodo è connesso a questi bordi, questo margine è parte di questi percorsi) ecc. Il mio modello sta aggiornando le variabili di stato usando i metodi del pacchetto, quindi tutti questi oggetti agiscono come immutabili per chiunque non sia nell'ambito del modello. Tutti gli oggetti estendono un tipo di base.

Mi sono divertito con l'idea di un approccio Factory che accetta un oggetto Builder e costruisce l'oggetto applicabile. Tuttavia, se un'istanza dell'oggetto esiste già (cioè restituisce true se ho creato l'oggetto definito dal builder e l'ho passato al metodo uguale per l'istanza esistente) la fabbrica restituisce l'oggetto corrente invece di creare una nuova istanza. Poiché il metodo Equal confronta solo ciò che definisce in modo univoco il tipo di oggetto (questo è il nodo A al nodo B) ma non controlla lo stato dinamico (il nodo A è attualmente connesso ai nodi C ed E) questo sarebbe un modo di garantendo a chiunque voglia che il mio nodo A conosca automaticamente le sue connessioni di stato. Ancora più importante, impedirebbe l'aliasing degli incubi di qualcuno che tentasse di passare un'istanza del nodo A con uno stato diverso da quello del nodo A del mio modello.

Non ne ho mai sentito parlare prima, ed è un po 'strano. Dovrei fare un po 'di override dei metodi di serializzazione per farlo funzionare (assicurati che quando leggo in un oggetto serigrafato lo aggiungo alla mia lista di facotry di istanze conosciute e / o restituisca una fabbrica esistente al suo posto), così come usando una weakHashMap come se fosse un weakHashSet per sapere se esiste un'istanza senza preoccuparsi di una perdita di quasi-memoria che si verifica. Non so se questo è troppo confuso o incline ai propri bug oscuri.

Una cosa che so è che i plugin si interfacciano con l'hardware di livello più basso. I plugin devono essere in grado di restituire uno stato diverso dalla mia memoria; per dire alla mia memoria quando il suo stato è incoerente. Credo che questo sia possibile nonostante i loro oggetti vagabondi che esistono nella mia memoria; permettiamo la costruzione di oggetti senza verificare la loro coerenza con il modello fino a quando l'addToModel viene chiamato comunque; e il design dei plug-in esistenti è stato scritto prima che tutto questo stato extra esistesse e funzionasse bene senza esserne mai a conoscenza.

Dovrei usare qualche altro disegno per evitare questa follia? (Ho un'altra domanda su quell'affetto che sto postando).

    
posta dsollen 29.04.2013 - 17:06
fonte

1 risposta

2

Il modello che stai concettualizzando è chiamato memoization ed è molto più comune nella programmazione funzionale, ma è anche usato pesantemente nella programmazione di giochi.

Finché incapsuli la tua implementazione e non hai casi particolari che faranno impazzire altri programmatori, dovresti essere in chiaro.

link

    
risposta data 29.04.2013 - 19:44
fonte

Leggi altre domande sui tag