Flyweight Pattern

The pattern suggests a mechanism by which you can avoid creating a large number of object instances which have similar content.

The Flyweight pattern suggests separating all the intrinsic common data into a separate object referred to as a Flyweight object. The group of objects being created can share the Flyweight object. This eliminates the need for storing the same invariant, intrinsic information in every object.

To decide if some part of your program is a candidate for using Flyweights, consider whether it is possible to remove some data from the class and make it extrinsic.

Every object can be viewed as consisting of one or both of the following two sets of information:

• Intrinsic (Internal) Information: The intrinsic information of an object is independent of the object context. That means the intrinsic information is the common information that remains constant among different instances of a given class. For example, the company information on a visiting card is the same for all employees.

• Extrinsic (External) Information: The extrinsic information of an object is dependent upon and varies with the object context. That means the extrinsic information is unique for every instance of a given class. For example, the employee name and title are extrinsic and unique on a visiting card

There are different types of flyweight implementations.

• In simple cases we can design it as a singleton or a HashMap or similar:

public final class ComplexObject {
    //simple flyweight
    private static final WeakHashMap<x,y> flyweightData = new...
 
    // private constructor
    private ComplexObject(...) {
        ....
        }
 
    //simple factory
    public static ComplexObject(...) {
        ....
        if (!flyweightData.containsKey(data)) {
            flyweightData.put(data);
        }
    return flyweightData.get(data).get();
    ....

• In more complicated cases, flyweights can have types and so factories come to picture.

We should make sure that there exists only one object of a given flyweight type and is shared by all the other appropriate objects also clients should not be allowed to create flyweight instances directly.

public class FlyweightFactory {
 
    private HashMap lstFlyweight;
    private static FlyweightFactory factory =  new FlyweightFactory();
 
    private FlyweightFactory() {
        lstFlyweight = new HashMap();
    }
 
    public synchronized FlyweightInterface getFlyweight(type) {
        if (! lstFlyweight.contains(type)) {
            //create and return it
        } else {
            return (FlyweightInterface) lstFlyweight.get(type);
        }
    }
    public static FlyweightFactory getInstance() {
            return factory;
    }
 
    //Flyweight class as inner class
    private class Flyweight implements FlyweightInterface {
        ....
    }

In this picture:
ConcreteFlyweight adds storage for intrinsic state, if any. A ConcreteFlyweight object must be sharable. Any state it stores must be intrinsic.

UnsharedConcreteFlyweight is not sharable. It's common for UnsharedConcreteFlyweight objects to have ConcreteFlyweight objects as children at some level in the flyweight object structure