Factory and Decorator Design Patterns

Factory Method Design Pattern

• A creational design pattern used in software development
• Provides an interface for creating objects in a superclass
• Allows subclasses to specify the types of objects they create
• Simplifies object creation by using a dedicated method, reducing dependencies
• Allows subclasses to create specific objects, improving flexibility and maintainability
• Simplifies object creation by using an interface or abstract class, hiding implementation details
• Provides flexibility to handle different product versions or new types by defining specific factory methods for each
• If your object creation process is complex or varies under different conditions, using a factory method can make your client code simpler and promote reusability
• Factories can also encapsulate configuration logic, allowing clients to customize the object creation process by providing parameters or options to the factory method
• Components: Creator, Concrete Creator, Product

Advantages of the Factory Method

• Separates creation logic from client code, improving flexibility.
• New product types can be added easily.
• Simplifies unit testing by allowing mock product creation.
• Centralizes object creation logic across the application.
• Hides specific product classes from clients, reducing dependency

Disadvantages of the Factory Method

• Adds more classes and interfaces, which can complicate maintenance.
• Slight performance impacts due to polymorphism.
• Concrete creators are linked to their products.
• Clients need knowledge of specific subclasses.
• May lead to unnecessary complexity if applied too broadly.
• Factory logic can be harder to test.

Abstract Factory Pattern

• A way of organizing how you create groups of things that are related to each other
• Provides a set of rules or instructions that let you create different types of things without knowing exactly what those things are
• Keeps everything organized and lets you switch between different types easily
• Components: Abstract Factory, Concrete Factories, Abstract Products, Concrete Products, Client

Flyweight Design Pattern

• A way to save memory in applications that create a large number of similar objects
• Instead of creating a new object for each instance, the Flyweight pattern reuses existing ones wherever possible, sharing common parts between objects
• Shared vs. Unique Data: Objects are split into shared (intrinsic) data and unique (extrinsic) data. The shared data is stored in a central place and reused, while the unique data is kept separately
• Example: Imagine a text editor displaying thousands of characters. Using Flyweight, the program can store each unique character style (like font or color) only once and reuse it, rather than duplicating it for every character
• Use when you need to create a large number of similar objects (buttons, icons) with different positions and other variable features
• Use when memory consumption is a concern

When Not to Use Flyweight

• When objects have unique intrinsic states (cannot be shared).
• When the overhead of implementing the pattern outweighs the benefits (small number of objects, minimal shared state).
• When mutable objects are involved (objects that change state frequently).
• When the application does not have performance or memory constraints.

Memento Design Pattern

• A behavioral pattern used to capture and restore an object's internal state without violating encapsulation
• Allows saving and restoring the state of an object to a previous state, providing the ability to undo or roll back changes
• Benefits: Encapsulation, Undo Functionality, Separation of Concerns
• Use when: Undo functionality, Snapshotting, Transaction rollbacks, Caching

When Not to Use Memento

• Large object state (complex, storing lots of data).
• Frequent state changes (unpredictable, hard to manage snapshots).
• Immutable objects (little benefit if the state is easily recreated).
• Overhead outweighs benefits (small number of objects, minimal shared state).

Adapter Design Pattern

• A structural design pattern that lets you connect incompatible interfaces or systems
• Serves as a bridge between two classes that would not otherwise be able to communicate
• Helpful when integrating third-party libraries or legacy code into a new system
• Types: Class Adapter (Inheritance-based), Object Adapter (Composition-based), Two-way Adapter, Interface Adapter
• Pros: Reuses existing code, separates interface adaptation, allows switching between different interfaces without altering the system
• Cons: Adds complexity, may introduce performance overhead, managing multiple adapters can be challenging

Observer Design Pattern

• A behavioral design pattern defining a one-to-many dependency between objects. When one object (the subject) changes state, all its dependents (observers) are notified and updated automatically
• Key points: Defines how observers react to Subject state changes; The subject doesn't need to know the exact class of its observers; Observers can be easily added or removed without affecting the subject
• Use when: One object needs to notify multiple others; For event systems where components need to interact without direct connections
• Cons: Performance concerns with too many observers; Tight coupling between subject and observers

Decorator Design Pattern

• A structural design pattern to add new behaviors or functionalities to individual objects dynamically without altering the objects' structures
• Benefits: Enhances functionality (modular and reusable), avoids subclassing (composing behaviors dynamically), clean and maintainable code
• Useful in scenarios: adding visual effects in UI components, extending the behavior of objects in a layered manner

Facade Design Pattern

• Provides a unified, higher-level interface to a set of interfaces in a subsystem
• Makes the subsystem easier to use by reducing the complexity and dependencies between clients and the subsystem
• Helps clarify the system's interface, thus allowing clients to interact with it in a simpler manner
• Simplifies the interface to the clients reduces the load on clients reducing dependence on implementation details
• Advantages: simplified interface, hides internal system details, reduces complexity, reduced coupling
• Disadvantages: increased complexity, potential reduction, potential over-engineering

Proxy Design Pattern

• A structural pattern that allows you to provide a substitute object for another object
• A proxy controls access to the original object, allowing you to perform actions before, after or even in place of the original object's actions
• Enables the replacement of an object with a proxy
• Typically used to manage access to an object that is expensive to create, or unavailable at the time
• Steps to implement: Define a service interface, create the proxy class, add a field in the proxy class to hold a reference to the service object, decide how the service object will be managed and implement proxy methods

Composite Design Pattern

• A structural pattern that lets you compose objects into tree structures
• Works with these structures as if they were individual objects
• Useful for representing part-whole hierarchies
• Use when: need to implement a tree-like object structure; treating simple and complex elements uniformly; avoid concrete class knowledge

State Design Pattern

• A behavioral pattern that lets an object alter its behavior when its internal state changes
• Useful when: an object's behavior depends on its current state; the number of states is large or frequently changes; reducing complex conditional statements
• Promotes flexibility, and ease in maintenance and extensibility, organized state behavior, and separation of state-specific logic

Singleton Design Pattern

• Ensures a class has only one instance and provides a global point of access to it
• Pros: Ensures a single instance, centralized access, efficient initialization (only initialized once when requested, avoids repeated creation).
• Cons: Violates the Single Responsibility Principle, Tight coupling, Potential for design problems due to the global access point, difficult to test

Bridge Design Pattern

• Separates abstraction from implementation in a class hierarchy
• Allows abstraction and implementation to be developed independently
• The abstraction part describes the interface, the implementation offers concrete implementations
• This pattern promotes the flexibility and reusability of the system components

Explore the Factory Method and Decorator Design Patterns in this quiz. Learn how these creational patterns simplify object creation and enhance flexibility. Understand their advantages, disadvantages, and common use cases in software development.