Scribd
Upload
4 views

Design Patterns Overview

COE318 Design Pattern Notes

Uploaded by

Eric Joseph
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
4 views

Design Patterns Overview

COE318 Design Pattern Notes

Uploaded by

Eric Joseph
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Design Patterns Overview

Tuesday, April 16, 2024 12:46 AM

Creational Patterns: These patterns provide various object creation mechanisms, making the design more flexible and reusable.

• Singleton:
○ Intent: Ensure a class has only one instance and provide a global access point.
○ Applicability: When a single instance is needed throughout the application (e.g., logging, configuration).
○ Consequences: Controlled access, but can be difficult to test and can hide dependencies.
• Factory Method:
○ Intent: Define an interface for creating objects, but let subclasses decide which class to instantiate.
○ Applicability: When the type of object to create depends on runtime conditions or user input.
○ Consequences: Promotes loose coupling and allows for easier extension, but might require subclassing.
• Abstract Factory:
○ Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
○ Applicability: When working with multiple families of related objects and you need to ensure they are compatible.
○ Consequences: Isolates concrete classes and makes it easy to switch between families, but can be complex to implement.

Structural Patterns: These patterns focus on the composition of classes and objects, promoting flexibility and code reuse.

• Façade:
○ Intent: Provides a simplified interface to a complex subsystem.
○ Applicability: When you need to provide a more user-friendly interface to a complex system or hide internal implementation details.
○ Consequences: Improves usability and reduces coupling, but can become a bottleneck if not designed carefully.
• Adapter:
○ Intent: Convert the interface of a class into another interface clients expect.
○ Applicability: When you need to use an existing class with an incompatible interface.
○ Consequences: Allows incompatible classes to work together, but can increase complexity.
• Composite:
○ Intent: Compose objects into tree structures to represent part-whole hierarchies.
○ Applicability: When you need to treat individual objects and compositions of objects uniformly.
○ Consequences: Simplifies client code and allows for easier addition of new components, but can make the design overly general.
• Bridge:
○ Intent: Decouple an abstraction from its implementation so they can vary independently.
○ Applicability: When you need to avoid permanent binding between an abstraction and its implementation and allow for future extensions.
○ Consequences: Improves flexibility and extensibility, but can increase the number of classes.

Behavioral Patterns: These patterns address communication and responsibilities between objects, promoting loose coupling and flexibility.

• Observer:
○ Intent: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
○ Applicability: When changes in one object require changes in others and the number of dependent objects is unknown or can vary.
○ Consequences: Promotes loose coupling and allows for flexibility, but can be difficult to debug if dependencies become complex.
• State:
○ Intent: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
○ Applicability: When an object's behavior depends on its state and needs to change dynamically.
○ Consequences: Localizes state-specific behavior, improves maintainability, but can increase the number of classes.
• Strategy:
○ Intent: Define a family of algorithms, encapsulate each one, and make them interchangeable.
○ Applicability: When you need different variants of an algorithm or want to allow for future algorithm changes without affecting clients.
○ Consequences: Improves flexibility and allows for easier algorithm switching, but can increase the number of classes.

You might also like