Flyweight pattern - What is the point of an unshared concrete instance?

Question

As we all know, in the UML diagram of the Flyweight Pattern there is an unshared concrete instance, and it implements the interface flyweight. My question is, why should it implement it if its extrinsic state is kind of pointless? I mean, for the shared concrete instances, the interface is needed so you must be sure that the extrinsic state can be passed, but what about the unshared? Can we not easily not implement the interface and achieve the same results?

Answer 1

Extending Flyweight interface gives the opportunity to decouple the client from the flyweight pattern implementation.

Example:

There's a Flyweight pattern implemented for 'Glyph'-s. According to the UML of the pattern, 'Glyph' represents the 'Flyweight' base class or interface. 'Client' works with a set of glyphs. FlyweightFactory (here GlyphFactory) can create glyphs (typically SharedFlyWeightGlyph object instances) using the flyweight pattern.

The Client probably stores a text as a set of glyphs.

Now let's say, next to the normal glyphs, you want to use a few custom glyphs which can't be created by FlyWeightFactory. By extending 'Glyph' interface (which is the UnsharedFlyweight according to the UML diagram of the pattern) you have the chance to use custom glyphs, though, in these cases the performance benefit of the flyweight pattern can't be utilized.

Answer 2

The unshared concrete instance has not intrinsic data to share, but it can consume the extrinsic "data" to produce its operation output, therefore it implements the same interface.

The main purpose of the this pattern is to save storage space, using efficiently a large number of objects.

Intrinsic state is invariant (context independent) and therefore can be shared. Extrinsic state is variant (context dependent) and therefore can not be shared and must be passed in.

Example from the cards. We have to track a large number of hands and theirs scores; the context is the hand, the shared instances are standard cards, and the unshared objects are the jokers. The output of a method points() of a standard card depends on its intrinsic data (suite and rank) and on the hand. The points() of a joker depends on the the hand and on a particular choice that it's not intrinsic, neither extrinsic.