Design Patterns: Flyweight and Memento

Flyweight Pattern

• The Flyweight pattern aims to minimize memory usage by sharing common parts of objects.
• It addresses scenarios with many similar objects, preventing excessive memory consumption.
• It works by storing intrinsic state (data unique to each object instance) within the flyweight object and extrinsic state (data common to many objects) externally.
• This external data can be stored in an external context object.
• By sharing common attributes, the memory footprint can be drastically reduced, significantly optimizing performance.
• The pattern is effective when the number of objects are high and identical or nearly identical parts of these objects exist.

Memento Pattern

• The Memento Pattern provides a way to capture and restore the internal state of an object without revealing the object's internal representation.
• It decouples the saving and restoring of the state from the object itself.
• This is achieved by creating a separate 'Memento' object that stores the state.
• The 'Caretaker' object is responsible for storing and restoring the 'Memento' objects.
• The 'Originator' object is the object whose state is being saved and restored.
• This pattern is useful when a user wants to save and restore an object's state without understanding its internal structure.

Singleton Pattern

• The Singleton pattern ensures that a class has only one instance and provides a global point of access for it.
• This is beneficial when there needs to be a single point of control for resources like databases, configurations, etc.
• The instantiation of a Singleton class is generally handled by a private constructor.
• Often, a static method is used to return the sole instance of the class.
• This can lead to a global access point in the program, potentially impacting testability.

Proxy Pattern

• The Proxy Pattern acts as an intermediary between a client and an object, controlling access to the object.
• This can include adding functionalities or restrictions to the object interaction.
• Different types of Proxies exist, such as virtual proxies (loading objects only when needed), remote proxies (objects on a different server), protecting proxies (controlling access), etc.
• Controlling access can be crucial for security and resource management.
• A Proxy can add additional functionality that the original object might not provide (e.g., logging every interaction).

Composite Pattern

• The Composite Pattern lets clients treat individual objects and compositions of objects uniformly.
• It builds a tree-like structure of objects, allowing for both individual leaf components and complex composite objects.
• The pattern is beneficial for hierarchical relationships, such as a document structure (paragraphs, sentences, words), or organizational charts.
• Similar methods are used to operate on individual leaf and composite objects.

State Pattern

• The State Pattern allows an object to alter its behavior when its internal state changes.
• Different states are encapsulated as separate classes, and each class holds the behavior of the object while in a specific state.
• The object switches between different state classes, changing its behavior accordingly.
• Handling different states of an entity is efficiently managed.

Facade Pattern

• The Facade Pattern provides a simplified interface to a complex subsystem.
• It hides the complex interactions and internal workings of the subsystem behind a single, unified interface.
• This simplified interface improves usability, ease of understanding, and maintainability for clients.
• It decouples the clients from the internal complexities of the subsystem.

Adapter Pattern

• The Adapter Pattern allows objects with incompatible interfaces to collaborate.
• An adapter object acts as an intermediary between the two different interfaces.
• It converts the interface of one object to match the interface expected by another object.
• This is beneficial when integrating existing systems with varying interfaces.

Observer Pattern

• The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
• The subject (the object being observed) maintains a list of observers.
• When the subject's state changes, it notifies all observers. Often, the observer will be responsible for updating its own internal state to reflect the subject's state.
• This pattern is useful for managing dependencies and reacting to changes in data.

Decorator Pattern

• The Decorator Pattern dynamically adds responsibilities to objects without altering their structure.
• It uses a decorator class which wraps the original object, adding extra behaviors.
• This allows you to add or modify functionalities through composition, enhancing flexibility and extensibility of classes compared to inheritance.
• Components can be decorated with different combinations of behaviors without modifying the original components.

Explore the Flyweight and Memento design patterns, essential for optimizing memory usage and managing object state. Learn how the Flyweight pattern minimizes memory by sharing common object parts, while the Memento pattern provides a way to capture and restore an object’s internal state without exposing its representation.