Here as much as I understand Operation takes in extrinsicState as argument, but it will not use it at all, as far as it has allState as member data.
Non penso che sia così. allState non sostituisce extrinsicState . È semplicemente lo stato non condivisibile che è differenziato dallo stato memorizzato esternamente.
Nel loro esempio:
-
Glyph è FlyweightBase e fornisce operazioni come Draw ,
-
Character è ConcreteFlyweight ,
- la
Character di intrinsicState è il suo codice carattere,
-
Row s e Column s sono UnsharedConcreteFlyweight s
-
Row e Columns allState contiene un insieme di Glyphs (che può essere Row s, Columns s o Character s. Non sono condivisi perché le collezioni sono tutte uniche (sebbene GOF dice che potrebbero essere successivamente realizzati per essere condivisi).
Il extrinsicState è il GlyphContext , che è la mappatura tra glifi e caratteri, e poiché questo stato è esterno ai pesi massimi, deve essere passato a entrambi i moschiconi concreti concreti e non condivisi.
Lo stato estrinseco appartiene logicamente ai pesi massimi ed è stato estratto come ornamento. Deve essere passato al peso mosca concreto Character in modo che lo stato possa essere recuperato, e deve essere passato a pesi volanti in calcestruzzo non condivisi ( Row e Column ), in parte in modo che possano passarlo a Character s a sua volta.
È ipotizzabile che Row s e Column s possano catturare un riferimento allo stato estrinseco (il GlyphContext ) e quindi non utilizzerebbero il loro parametro. Tuttavia, come menzionano, con questo design, i clienti non devono sapere se sono condivisibili o meno. (Questo stato extra sarebbe anche contrario al design del peso mosca, in quanto anche il riferimento non è realmente necessario.)
Is it a good design? To take arguments you don't use, and if you will use, then you will have data duplication. This may even be Liskov Substitution Principle violation?
Il modello del peso mosca è un'ottimizzazione, se vuoi, e, puoi pensare che è un refactoring di un design più semplice orientato agli oggetti che usa troppi oggetti.
L'ottimizzazione funziona separando lo stato intrinseco dallo stato estrinseco, con l'ipotesi che lo stato estrinseco possa essere rappresentato in modo più efficiente rispetto all'essere replicato in ogni oggetto e, che ora è separato, la maggior parte del resto (lo stato intrinseco) può essere essere condivisi e riutilizzati.
Dopo il refactoring, puoi ora richiamare tutti gli stessi metodi orientati agli oggetti che esistevano in precedenza, ma il costo è che devi passare lo stato estrinseco come parametro aggiuntivo ora.
Come ottimizzazione, se non ne hai assolutamente bisogno, non dovresti usarla solo perché è possibile. Rende il codice più difficile da usare, capire, mantenere, ecc.
Ma nell'informatica, ci sono dei costi, e quindi quando hai bisogno di ottimizzazione, ne hai bisogno!
Nota anche che non devi necessariamente implementare il peso mosca non condiviso, è solo che puoi farlo se ne hai bisogno.
