gaspersic/java-design-patterns
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
Ilkka Seppälä 2020-08-23 18:53:57 +03:00
parent 015b418114
commit 6d83ceba28
1 changed files with 19 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
bridge/README.md
View File

@ -9,20 +9,26 @@ tags:
---
## Also known as
Handle/Body
## Intent
Decouple an abstraction from its implementation so that the two can vary independently.
## Explanation
Real world example
> Consider you have a weapon with different enchantments and you are supposed to allow mixing different weapons with different enchantments. What would you do? Create multiple copies of each of the weapons for each of the enchantments or would you just create separate enchantment and set it for the weapon as needed? Bridge pattern allows you to do the second.
> Consider you have a weapon with different enchantments, and you are supposed to allow mixing
> different weapons with different enchantments. What would you do? Create multiple copies of each
> of the weapons for each of the enchantments or would you just create separate enchantment and set
> it for the weapon as needed? Bridge pattern allows you to do the second.
In Plain Words
> Bridge pattern is about preferring composition over inheritance. Implementation details are pushed from a hierarchy to another object with a separate hierarchy.
> Bridge pattern is about preferring composition over inheritance. Implementation details are pushed
> from a hierarchy to another object with a separate hierarchy.
Wikipedia says
@ -30,7 +36,7 @@ Wikipedia says
**Programmatic Example**
Translating our weapon example from above. Here we have the `Weapon` hierarchy
Translating our weapon example from above. Here we have the `Weapon` hierarchy:
```java
public interface Weapon {
@ -105,7 +111,7 @@ public class Hammer implements Weapon {
}
```
And the separate enchantment hierarchy
Here's the separate enchantment hierarchy:
```java
public interface Enchantment {
@ -151,7 +157,7 @@ public class SoulEatingEnchantment implements Enchantment {
}
```
And both the hierarchies in action
Here are both hierarchies in action:
```java
var enchantedSword = new Sword(new SoulEatingEnchantment());
@ -178,18 +184,21 @@ hammer.unwield();
```
## Class diagram
![alt text](./etc/bridge.urm.png "Bridge class diagram")
## Applicability
Use the Bridge pattern when
* you want to avoid a permanent binding between an abstraction and its implementation. This might be the case, for example, when the implementation must be selected or switched at run-time.
* both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently
* changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled.
* you have a proliferation of classes. Such a class hierarchy indicates the need for splitting an object into two parts. Rumbaugh uses the term "nested generalizations" to refer to such class hierarchies
* you want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be hidden from the client. A simple example is Coplien's String class, in which multiple objects can share the same string representation.
* You want to avoid a permanent binding between an abstraction and its implementation. This might be the case, for example, when the implementation must be selected or switched at run-time.
* Both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently.
* Changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled.
* You have a proliferation of classes. Such a class hierarchy indicates the need for splitting an object into two parts. Rumbaugh uses the term "nested generalizations" to refer to such class hierarchies.
* You want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be hidden from the client. A simple example is Coplien's String class, in which multiple objects can share the same string representation.
## Tutorial
* [Bridge Pattern Tutorial](https://www.journaldev.com/1491/bridge-design-pattern-java)
## Credits