0

Here is the flyweight pattern structural diagram:

enter image description here

Here you see UnsharedConcreteFlyweight which GoF explains:

UnsharedConcreteFlyweight : Not all Flyweight subclasses need to be shared. The Flyweight interface enables sharing; it doesn't enforce it. It's common for UnsharedConcreteFlyweight objects to have ConcreteFlyweight objects as children at some level in the flyweight object structure (as the Row and Column classes have).

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.

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?

Narek
  • 38,779
  • 79
  • 233
  • 389
  • I doubt, you rarely find a pattern which conforms with all the SOLID principles for all the use cases. Isn't it? 'Convenience' plays a key-role here. If we rigidly follow some principle with immense hard-work, but only achieve all-most nothing rather than just happiness of following it, definitely makes no sense. :)) – Supun Wijerathne Oct 12 '16 at 03:27

1 Answers1

0

It is still good! The Liskov Substitution Principle (LSP) is all about Design By Contract. As long as the UnsharedConcreteFlyweight.Operation satisfies the contract of Flyweight.Operation, no problem!

Ignoring input parameters (extrinsic state in this case) is just an indication of LSP violation, not always.

Nghia Bui
  • 3,694
  • 14
  • 21