13. Flyweight enjoyment mode of object performance mode

1. Motivation

• The problem with using pure object solutions in software systems is that a large number of fine-grained objects will quickly flood the system, resulting in high runtime costs: mainly in terms of memory requirements.
• How can external clients still operate transparently in an object-oriented manner while avoiding the problem of a large number of fine-grained objects?

        It may not be visible under normal circumstances, but if the number of classes reaches tens of thousands, or even hundreds of thousands, the above problems will be exposed.

        In the mid-to-late 1980s, there was a trend of thought: everything is an object, and it was a bit unrealistic to realize it later, such as an int. There is no need to use objects for this type, but in business scenarios, there are also some small things that look very Fine-grained, but it may also be considered as an object in design. And if the amount used is particularly large, memory overhead will be incurred. How to do it?

In fact, the idea is, can you use the sharing method (the origin of the name of Xiangyuan)

2. Schema definition

        Efficiently support large numbers of fine-grained objects using sharing techniques

                                                                                                       ---《Design Patterns》GOF

3. Structure

 Originally fine-grained objects may be directly new, but here a flyweight factory is used to judge whether the object exists through a key. If it exists, there is no need to re-new.

The two in the lower right corner (you can ignore this part) indicate that some support Flyweight, and some do not support Flyweight

4. Code example

        For example, when designing a character processing system, assume that the font is designed as an object. The font object is in great demand in the system. Strictly speaking, each character has a font. But if you read a lot of articles, you will find that there are only a few fonts they use, and most of them say that the fonts of the characters are the same. It is unreasonable to create an object for each character indiscriminately.

class Font{
private:
    string key;
    
    //
    // ...
public:
    Font(const string& key){
        //...
    }
};

class FontFactory{
private:
    map<string, Font*> fontPool;
public:
    Font* GetFont(const string &key){
        auto iter = fontPool.find(key);
        if (iter != fontPool.end()){
            return fontPool[key];
        }
        else{
            Font *font = new Font(key);
            fontPool[key] = font;
            return font;
        }
    }
};

5. Summary

• Object-oriented solves the problem of abstraction very well, but as a program entity running in the machine, we need to consider the cost of objects. Flyweight mainly solves the cost problem in object-oriented, and generally does not touch the abstract problem of object-oriented.
• Flyweight uses object sharing to reduce the number of objects in the system, thereby reducing the memory pressure brought by fine-grained objects to the system. In terms of specific implementation, we should pay attention to the processing of the object state (because after we create the object, the state of the object cannot be changed under normal circumstances, and often such objects are created as read-only)