Scribd
Upload
12 views

Design Patterns Overview

COE318 Design Pattern Notes

Uploaded by

Eric Joseph
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
12 views

Design Patterns Overview

COE318 Design Pattern Notes

Uploaded by

Eric Joseph
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
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