- Protecting Valuable Resources
- Interfaces: Action-Packed Entities
- Configuring IP Addresses
- Solution Introduction and the Flyweight Pattern
- A Generic Network Link
- A Generic Network Link Context
- A Real Network Link
- The GenericLink Implementation
- The GenericLinkContext Implementation
- The RealLink Implementation
- Bringing the Code Together
- Conclusion
- Additional Reading
Conclusion
The flyweight design pattern in some ways reminds me of programming in the early 1990s. Back then, every byte of RAM and disk space counted! Nowadays, for non-embedded systems we appear to be awash with computing resources. The reality is somewhere in the middle. As software designers and programmers, we all have a duty to make our work as resource-friendly as possible. You never know what type of software technology is around the corner—the next wave of technology might just soak up all our computing resources and then some. Having looked at some of the early offerings in the areas of service-oriented architecture and workflow solutions, I think these will be hungry technologies!
The flyweight pattern offers a tradeoff in terms of storage versus processing. The flyweight stores generic, multi-object data that the clients can retrieve at the expense of some processing. An unexpected benefit of this scheme is the separation between generic data and client code. The flyweight facilitates separation of multi-object systems from the extrinsic data that describes them. This is good practice at the best of times! However, the flyweight gives us more in that we can also use it to manipulate complex, sparse data, such as IP addresses. This fruitful area is worthy of further study—I’ve only scratched the surface.
The complete working source code for this article consists of four C++ header files and five accompanying C++ implementation files. As usual, if you’d like to build this code and try it for yourself, just create a Visual C++ console project, drop the files in, switch off precompiled headers, build, and away you go!