Scribd
Upload
5 views13 pages

SDA Assignmnent 1

The document discusses the Bridge Design Pattern, emphasizing its ability to decouple abstraction from implementation, allowing both to evolve independently. It outlines best practices and pitfalls in using the pattern, as well as when to avoid it based on system complexity and performance concerns. Additionally, it compares the Bridge Pattern with Adapter and Strategy Patterns, highlighting their respective trade-offs and use cases.

Uploaded by

ahmadxaidi2004
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
5 views13 pages

SDA Assignmnent 1

The document discusses the Bridge Design Pattern, emphasizing its ability to decouple abstraction from implementation, allowing both to evolve independently. It outlines best practices and pitfalls in using the pattern, as well as when to avoid it based on system complexity and performance concerns. Additionally, it compares the Bridge Pattern with Adapter and Strategy Patterns, highlighting their respective trade-offs and use cases.

Uploaded by

ahmadxaidi2004
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 13

SDA

ASSIGNME
NT 01
MUHAMMAD AHMAD RAZA

RIDA WAHEED

DAUD SHAFI KHAN

ANAS REHMAN

MUHAMMAD HASSAN ALI


Introduction
Bridge Pattern
Main idea is that there is a
"bridge" that decouples the
abstraction from the
implementation so that both can

Introducti
vary independently.
[geekforgeeks.com]

on
Example: Shapes and color
classes
• Identify Independent Dimensions :
Apply for systems with multiple
orthogonal extensions. [2]
• Favor Composition Over
Do’s of Inheritance : Use composition to
reduce coupling. [2]
Bridge • Define Clear Abstractions : Ensure
Design well-structured abstraction and
implementation hierarchies.[1]
Pattern • Keep Interfaces Focused : Adhere
to Interface Segregation Principle. [1]
• Document Code : Maintain clarity
and ease of maintenance. [1]
• Avoid Unnecessary Abstractions :
Don’t overcomplicate without clear
benefits. [1]
• Prevent Interface Overload : Keep
Don’ts of methods relevant and minimal. [1]
• Use Clear Naming : Avoid vague
Bridge class/method names. [1]
Design • Handle Variability Properly : Ensure
implementations remain flexible. [1]
Pattern • Leverage the Pattern Fully : Maintain
abstraction-implementation separation.[2]

[1] Java Nexus


[2] Refactoring Guru
Usability
Analysis
[1
]

Enables Shared
Decouples
Implementations
Abstraction &
– Useful for
Implementation –
reference counting
Allows changing
and object sharing.
implementations at
runtime.

Supports

When to Reduces Class


Explosion – Helps
manage complex
Independent
Extensibility –
Both abstraction
and implementation

use :
hierarchies.
can evolve
separately.

Encapsulates
Improves
Implementation –
Maintainability –
Hides
Changes in
implementation
implementation
details from clients
don’t affect clients.
(useful in C++).

-[1]Design Patterns: Elements of Reusable


Object-Oriented Software (p. 153)
If you don’t have multiple
dimensions of variation, a
simple class hierarchy is
enough.[1]
When performance is a major
When to concern, as introducing
abstraction layers may add
avoid: overhead. [2]
If the system is small and
unlikely to change, Bridge may
introduce unnecessary
complexity. [1]
[1]Design Patterns: Elements of Reusable Object-
Oriented Software
Comparison with
Alternative Approaches
Adapter Pattern

“Convert the interface of a class into


another interface clients expect” [1].

Intent:
• Make incompatible things work
together.
• Wrap an existing class to fit new needs.
Example:
• A `USBCharger` needs to work with a
`TypeC` device. An adapter makes the
- [1] Design Patterns:
USB look Elements
like Type-C of Reusable
to the device. It
Object-Oriented Software
translates requests (p. 139)
so they match.
Strategy Pattern

Defines a family of algorithms and makes them


interchangeable. [2]
Intent:
• Switch between different methods at runtime.
• Keep behavior separate from the main class.
Example:
• A `PaymentProcessor` uses `CreditCard`,
`PayPal`, or `Crypto`. Each payment type is a
strategy you can swap. Add or change
- [2]methods
Design Patterns: Elements of Reusable Object-
without altering the processor.
Oriented Software (p. 315)
Flexible behavior through swappable strategies.
Trade-offs
Bridge Pattern:
• Flexibility but complex.
• You get a system that can change and
adapt easily, but it takes more effort
to set up.
• "Lets you vary the abstraction and
implementation independently".[3]
• "Introduces an extra level of
- indirection", [4] which increases
[3] Design Patterns: Elements of Reusable Object-
complexity.
Oriented Software by Gamma et al. (p. 151)
- [4] Design Patterns: Elements of Reusable Object-
Oriented Software by Gamma et al. (p. 157)
-Adapter Pattern:
- Simple adaptation but limited to interface
conversion.
- It’s a simple way to make things match up, but it
doesn’t make them more powerful.
- "Adapter makes things work after they’re
designed". [5]

-Strategy Pattern:
- Dynamic behavior but with increased object count.
- You can change how things work whenever you
want, but you might end up with more stuff to
manage.
- "Strategy lets the algorithm vary independently
from clients".[6]
- "Each strategy is a separate class". [7] potentially
leading to more objects in the system.

- Design Patterns: Elements of Reusable


Object-Oriented Software by Gamma et al.
[5] (p. 139),
[6] (p. 315)
[7] (p. 319)

You might also like