69: Design Patterns: Flyweight.

The flyweight structural pattern allows you to represent more items in your application as class instances without using up all your computer memory. It does this with four steps: Separate the data members in your classes that you’re considering for this pattern into intrinsic and extrinsic state. Intrinsic state is common for all instances and belongs with shared instances of the class. Extrinsic state is anything that’s unique to each instance and can’t be shared. Use either a factory or a modified singleton to create a pool of shared objects where there’s just one object of each type that’s participating in this pattern. There should only be one instance of each class with the same intrinsic state. Pass the extrinsic state to each class method that needs it. You’ll likely have several data members that need to be kept separate like this and they can all be bundled into a context that gets passed to each method. And try to calculate the extrinsic state as much as possible. This will lead to even more memory savings. This pattern shows you how to save a lot of memory when dealing with many instances of your classes. It’s likely to allow you to represent items as class instances that you wouldn’t have been able to consider before. Listen to the full episode or you can also read the full transcript below. Transcript The basic description says that this pattern allows you to share large numbers of objects efficiently. In the adventure game, there’s probably going to be lots of trees outside. And for that matter, there’ll be lots of rocks, boulders, and shrubs. What about in a town? There’s the obvious buildings. But what about all the windows and doors? What about all the tables and chairs? Almost everything in the game could be considered to be defined by a class. The problem with this is that if you try to instantiate all these objects, you’ll quickly run out of memory. Whenever you create a new instance of a class, you need dedicated memory to hold all that class’s member data. The methods are shared so at least that much is good. You don’t have to allocate memory for all the method instructions for each instance of a class. Just the member data. This pattern explains how you can do even better. That means it now becomes feasible to represent all the game elements with their own class and create an instance for each occurrence. Got a forest with a hundred thousand trees? With this pattern, you can now treat each one of those trees as if they were unique instances. Notice, I’m saying as if. No design pattern including this one, can magically give your computer unlimited resources. Even if the application itself deals with magic. It just doesn’t work that way. Design patterns will show you clever ways to think about solutions to problems that developers face all the time. What you need to do in order to use this pattern is first figure out if there’s any data in your classes that could be shared among many or all instances. Then for the data that has to be unique, is there any way it could be calculated instead of stored in memory. I hope you see the tradeoff we’re making here. Most engineering problems have multiple solutions that trade one aspect for another. Maybe weight gets traded for cost. What this pattern does is trade storage or memory requirements for some extra runtime calculations. This means your program will run a little slower but the benefit is that your user will appreciate the details that are now possible in that forest. I’ll explain exactly how the flyweight pattern works right after this message from our sponsor. ( Message from Sponsor ) Let’s take the specific example of how to represent all the doors in a town. Most games will have separate towns with a theme or a general appearance that’s common to all the buildings. This is another one of those things that mirrors real life. J