Structural Patterns  «Prev  Next»
Lesson 6 Flyweight: applicability
Objective Learn when and when not to use the Flyweight pattern.

Flyweight Suitability and Applicability

Navigating the labyrinthine intricacies of systems architecture often requires the judicious selection of design patterns, akin to a master painter choosing the appropriate brush strokes to bring a vision to life. The Flyweight Pattern is one such nuanced stroke in the artist's repertoire, one that may either add incredible detail to a landscape or, when misapplied, muddy the waters of your creation. Knowing when to employ this pattern is a matter of understanding the terrain of your architectural canvas and the hues of your operational needs.

When to Use the Flyweight Pattern

  1. A Sea of Similarity: If your system architecture resembles a vast ocean where droplets, akin to objects are numerous but share much in common, Flyweight becomes the raft that allows you to navigate this expanse without sinking into the depths of inefficiency. The pattern excels when dealing with a large number of almost identical objects by allowing you to externalize their common characteristics, thereby conserving resources.
  2. The Scale of the Universe: When you are constructing a digital universe that must scale to cosmic proportions, but your available resources are grounded in earthly limitations, Flyweight offers a telescope through which scalability can be observed and achieved. It allows your architecture to handle a growing number of objects without a commensurate increase in resource consumption.
  3. The Timekeeper's Concern: If your system is akin to a tightly wound clock where every tick and tock,, each instantiation and operation, must occur with flawless precision and speed, then Flyweight becomes the oil that reduces friction, enhancing performance by minimizing the overhead of object initialization.
  4. Changing Seasons, Unchanging Trees: In a forest of functionality where individual trees (objects) undergo seasonal changes (state modifications) but their intrinsic properties like species or type (shared states) remain constant, Flyweight serves as the enduring root system that supports each tree while economizing on the nutrients (resources) consumed.

When Not to Use the Flyweight Pattern

  1. A Palette of Uniqueness: If each object in your system is a distinct color in an artist's palette, with little to no shared state, employing Flyweight would be akin to mixing all the colors into an indistinguishable grey. The benefits of shared resources are lost, and you might introduce unnecessary complexity.
  2. The Open Prairie: In landscapes where resources are abundant like an open prairie, and the focus is not on economizing memory or computational power, introducing Flyweight could be akin to tilling soil where no crops are intended to be sown, an unnecessary labor.
  3. The Isolated Islands: If your objects do not interact with one another or share common operations, much like isolated islands in an archipelago, Flyweight may add a layer of abstraction that serves no purpose, effectively becoming a bridge that leads nowhere.
  4. The Constantly Changing Sky: In systems where object states are so dynamic that they resemble a sky with ever-changing cloud formations, the Flyweight Pattern could add a level of rigidity that hampers adaptability.
In summary, deploying the Flyweight Pattern is a nuanced endeavor, a precise brush stroke that must be applied with care, recognizing both its potential to bring out the best in your canvas of complexities and its pitfalls when applied indiscriminately. An architect must weigh the symphonic harmonies of efficiency, scalability, and performance against the dissonant chords of unnecessary complexity and rigidity to decide when the Flyweight Pattern is the perfect note to strike. It is neither a universal solvent nor a mere drop in the ocean but a specialized instrument in your orchestration of architectural excellence.
The Flyweight pattern is useful for systems in which all of the following four conditions apply.

Quantity of Objects used makes the system unwieldy

Poor environments also keel over when too many classes are used at once, but the Flyweight pattern does not solve this problem. When faced with this problem you may want to consider whether some of your different classes are really just instances of some common superclass.

The Number of Objects actually constructed is much smaller than the total Possible Objects

If the number of possible objects or the number of objects actually constructed is of the same order of magnitude or even larger than the actual number of objects, the Flyweight pattern does not help much. It only helps when there are many almost identical copies of the same small set of objects.

The objects can be made immutable

Since one object must stand in for many different objects, it should not change frequently. When a Flyweight object's state changes, the state of all the objects the Flyweight is representing changes. This is rarely what you want. If objects are not naturally immutable, you may be able to move the mutable parts outside of the object into the document or object that contains the Flyweights.

Objects do not need to be tested for identity

An identity test decides whether two objects are the same object. An equality test decides whether two objects have the same state.
For example, if a checking account and a savings account each have a $1000.00 balance, the balances are equal, but they are not the same balance. In Java == tests for identity while the equals() method tests for equality. However, Flyweights substitute the same identical object for objects that would otherwise be merely equal, so identity tests are not valid.