Steakeye · October 29, 2017 15:39 · Oct 20, 2016 · Oct 20, 2016 · Sep 26, 2014 · Sep 26, 2014
diff --git a/Design Patterns: Adapter vs Facade vs Bridge.md b/Design Patterns: Adapter vs Facade vs Bridge.md
@@ -36,7 +36,7 @@ Most DSL's are a facade of some form. The popular jQuery library consists of mul
 
 The primary function of a Bridge is to decouple an abstraction from its implementation.
 
-> Adapter makes things work _after_ they're designed
+> Adapter makes things work _after_ they're designed  
 > Bridge makes them work _before_ they are
 
 Imagine you have a function that abstracts the implementation detail of making an HTTP request to an external API endpoint. In a language like JavaScript you might tightly couple the abstraction with the consumer code.

diff --git a/Design Patterns: Adapter vs Facade vs Bridge.md b/Design Patterns: Adapter vs Facade vs Bridge.md
@@ -36,6 +36,9 @@ Most DSL's are a facade of some form. The popular jQuery library consists of mul
 
 The primary function of a Bridge is to decouple an abstraction from its implementation.
 
+> Adapter makes things work _after_ they're designed
+> Bridge makes them work _before_ they are
+
 Imagine you have a function that abstracts the implementation detail of making an HTTP request to an external API endpoint. In a language like JavaScript you might tightly couple the abstraction with the consumer code.
 
 For example:

diff --git a/Design Patterns: Adapter vs Facade vs Bridge.md b/Design Patterns: Adapter vs Facade vs Bridge.md
@@ -18,6 +18,12 @@ The `B` function cannot be changed and it is dependant on the interface that was
 
 An adapter can solve this by creating a new function `A2C` which contains the relevant logic for handling the interaction between `B` and `A`.
 
+```
+Current | Future
+----------------
+B(C)    | B(A2C(A))
+```
+
 ## Facade
 
 The primary function of a Facade is to simplify the interaction between a consumer and an interface.

diff --git a/Design Patterns: Adapter vs Facade vs Bridge.md b/Design Patterns: Adapter vs Facade vs Bridge.md
@@ -14,7 +14,7 @@ Current | Future
 B(C)    | B(A)
 ```
 
-The `B` function cannot be changed and it is dependant on the interface that was originally provided by `C`, but now we are passing in `A` which is has an incompatible interface.
+The `B` function cannot be changed and it is dependant on the interface that was originally provided by `C`, but now we are passing in `A` which has an incompatible interface.
 
 An adapter can solve this by creating a new function `A2C` which contains the relevant logic for handling the interaction between `B` and `A`.
 

diff --git a/Design Patterns: Adapter vs Facade vs Bridge.md b/Design Patterns: Adapter vs Facade vs Bridge.md
@@ -0,0 +1,65 @@
+The three design patterns (Adapter, Facade and Bridge) all produce the result of a clean public API. The difference between the patterns are usually due to a subtle context shift (and in some cases, a behavioural requirement).
+
+## Adapter
+
+The primary function of an Adapter is to produce a *unified* interface for a number of underlying and unrelated objects.
+
+You will notice this pattern being utilised in many applications. For example, ActiveRecord (the popular Ruby ORM; object-relational mapping) creates a unified interface as part of its API but the code underneath the interface is able to communicate with many different types of databases. Allowing the consumer of the API to not have to worry about specific database implementation details.
+
+The principle structure of this pattern is:
+
+```
+Current | Future
+----------------
+B(C)    | B(A)
+```
+
+The `B` function cannot be changed and it is dependant on the interface that was originally provided by `C`, but now we are passing in `A` which is has an incompatible interface.
+
+An adapter can solve this by creating a new function `A2C` which contains the relevant logic for handling the interaction between `B` and `A`.
+
+## Facade
+
+The primary function of a Facade is to simplify the interaction between a consumer and an interface.
+
+Most DSL's are a facade of some form. The popular jQuery library consists of multiple facades (one for each type of feature). For example, the jQuery `ajax` method makes it very easy to make an XHR (`XMLHttpRequest`).
+
+> The difference between a Facade and an Adapter is that the Facade makes a simple abstraction, where as an Adapter will handle complex interactions by taking incoming data and constructing it to work with the underlying objects.
+
+## Bridge
+
+The primary function of a Bridge is to decouple an abstraction from its implementation.
+
+Imagine you have a function that abstracts the implementation detail of making an HTTP request to an external API endpoint. In a language like JavaScript you might tightly couple the abstraction with the consumer code.
+
+For example:
+
+```js
+function get(e) {
+  return asyncRequest('foo?bar=' + this.id, function(response) {
+    console.log(response)
+  })
+}
+
+myTrigger.addEventListener('click', get, false)
+```
+
+The above abstraction (i.e. the `get` function) will only ever work within the context of a web browser. The abstraction has been tightly coupled to the consumer.
+
+Utilising a bridge will allow us to decouple this code:
+
+```js
+function get(id, callback) {
+  return asyncRequest('foo?bar=' + id, function(response) {
+    callback(response)
+  })
+}
+
+function getBridge(e) {
+  get(this.id, function(response) {
+    console.log(response)
+  })
+}
+
+myTrigger.addEventListener('click', getBridge, false)
+```