Embed diagrams in README files

Badacadabra · Badacadabra · commit 37425afb6388 · 2017-01-09T00:16:03.000+01:00
diff --git a/GoF/classic/Behavioral/ChainOfResponsibility/README.md b/GoF/classic/Behavioral/ChainOfResponsibility/README.md
@@ -15,3 +15,5 @@ Everytime a request should be handled by multiple (and complementary) processing
   * An abstract representation of a racer (abstract class or interface)
   * Concrete racers (Walker, Runner, Swimmer)
   * Composition because each racer "class" must have a reference to the next relay (except for the last athlete who crosses the finish line)
+
+![Chain of Responsibility (classic)](ChainOfResponsibility.png)
diff --git a/GoF/classic/Behavioral/Command/README.md b/GoF/classic/Behavioral/Command/README.md
@@ -11,7 +11,7 @@ In computer science terms, it seems obvious that the restaurant has to handle a
 # Solution
 
 The Command pattern is a great help here. In this pattern terminology, we will say that:
-  ***
+  
   * The restaurant is the "invoker" who creates and handles new orders internally
   * The order is the "command", in other words the request which comes from a client
   * The customer is the "receiver" of the order
@@ -22,3 +22,5 @@ To implement this pattern, we then need:
   * An abstract representation of an order (abstract class or interface)
   * A concrete order that we will call "TexMex" (this one must have a reference to the customer)
   * A concrete customer whose action (pay) will be triggered from the order itself
+
+![Command (classic)](Command.png)
diff --git a/GoF/classic/Behavioral/Interpreter/README.md b/GoF/classic/Behavioral/Interpreter/README.md
@@ -15,3 +15,5 @@ The Interpreter pattern is exactly what we need to tell JavaScript how to interp
   * Concrete (terminal and nonterminal) expressions like Note or Arpeggio
 
 The distinction between terminal and nonterminal expressions in the Interpreter pattern is a bit like the distinction between simple and composed elements in the Composite pattern. A note is a terminal expression because it is an "elementary symbol" of the grammar. However, an arpeggio is a nonterminal expression because it can be considered as a group of notes.
+
+![Interpreter (classic)](Interpreter.png)
diff --git a/GoF/classic/Behavioral/Iterator/README.md b/GoF/classic/Behavioral/Iterator/README.md
@@ -18,3 +18,5 @@ Iterator is the design pattern we need for this. To implement this pattern, we c
   * A concrete catalog like a library catalog (which references all books)
 
 In this particular case, a collection is an iterable object whereas a catalog is an iterator object.
+
+![Iterator (classic)](Iterator.png)
diff --git a/GoF/classic/Behavioral/Mediator/README.md b/GoF/classic/Behavioral/Mediator/README.md
@@ -16,3 +16,5 @@ This is exactly the solution proposed by the Mediator pattern. To implement this
   * An abstract representation of a neighborhood mediator (abstract class or interface)
   * Concrete neighbors (Tom and Dick)
   * A concrete mediator (Harry)
+
+![Mediator (classic)](Mediator.png)
diff --git a/GoF/classic/Behavioral/Memento/README.md b/GoF/classic/Behavioral/Memento/README.md
@@ -13,3 +13,5 @@ Here we have to use bookmarks to save interesting webpages and the Memento patte
   * A concrete "originator" (the browser) which is responsible for the action
   * A concrete "memento" (a bookmark) which keeps the link to the interesting webpage
   * A concrete "caretaker" (the bookmarks manager) which keeps a list of bookmarks
+
+![Memento (classic)](Memento.png)
diff --git a/GoF/classic/Behavioral/Observer/README.md b/GoF/classic/Behavioral/Observer/README.md
@@ -16,3 +16,5 @@ The Observer design pattern helps a lot when we have to implement an event-drive
   * An abstract representation of predators which are observers (abstract class or interface)
   * A concrete prey (Gazelle)
   * Concrete predators (Lion & Crocodile)
+
+![Observer (classic)](Observer.png)
diff --git a/GoF/classic/Behavioral/State/README.md b/GoF/classic/Behavioral/State/README.md
@@ -15,3 +15,5 @@ The State design pattern is obviously what we should use here. Here we need:
   * Concrete states (on/off)
 
 Contrary to the Strategy pattern, we can access the context directly from the concrete states. This allows state changes from states themselves.
+
+![State (classic)](State.png)
diff --git a/GoF/classic/Behavioral/Strategy/README.md b/GoF/classic/Behavioral/Strategy/README.md
@@ -14,3 +14,5 @@ The Strategy design pattern is exactly what we need in this kind of situation. T
   * A concrete context (FightingGame) which contains a reference to a strategy
   * An abstract representation of a strategy (abstract class or interface)
   * Concrete strategies (Offense & Defense)
+
+![Strategy (classic)](Strategy.png)
diff --git a/GoF/classic/Behavioral/Template/README.md b/GoF/classic/Behavioral/Template/README.md
@@ -16,3 +16,5 @@ The Template design pattern is an ideal candidate to express with code this kind
   * Concrete constructions (House & Building)
 
 Most methods on the abstract class are abstract and are implemented in concrete constructions.
+
+![Template (classic)](Template.png)
diff --git a/GoF/classic/Behavioral/Visitor/README.md b/GoF/classic/Behavioral/Visitor/README.md
@@ -6,7 +6,7 @@ I love history and I would like to visit more old monuments. But these are treas
 
 If any individual can enter a historical monument and degrade it, we can say that the original structure is definitely lost. To preserve that structure, people should not be allowed to enter historical monuments without permission and supervision.
 
-Applied to JavaScript, we could say this is very easy to modify directly the structure of an object and we may be tempted to do so. *But this is not what we want...
+Applied to JavaScript, we could say this is very easy to modify directly the structure of an object and we may be tempted to do so. But this is not what we want...
 
 # Solution
 
@@ -18,3 +18,5 @@ To implement the Visitor design pattern, we need:
   * An abstract representation of a historical monument (abstract class or interface)
   * A concrete visitor (Tourist)
   * Concrete historical monuments (Castle & Abbey)
+
+![Visitor (classic)](Visitor.png)
diff --git a/GoF/classic/Creational/AbstractFactory/README.md b/GoF/classic/Creational/AbstractFactory/README.md
@@ -17,3 +17,5 @@ AbstractFactory is a great solution here. We could consider it as a superset of
   * Concrete implementations of these abstractions (e.g. Debian, Mac OS X, Windows XP)
   * A concrete factory for each OS family
   * An abstract factory delivering instances of the concrete factories
+
+![Abstract Factory (classic)](AbstractFactory.png)
diff --git a/GoF/classic/Creational/Builder/README.md b/GoF/classic/Creational/Builder/README.md
@@ -15,4 +15,6 @@ The Builder pattern allows us to build our PC step by step. This pattern require
   * A director (here a manufacturer, which will delegate the work to the geeks in the staff)
   * A product (PC), the entity to build
 
+![Builder (classic)](Builder.png)
+
 N.B. Building an object step by step is easy in JavaScript. It is in the language DNA (see object literals). In practice, the Builder design pattern is not really interesting in this language, at least in its "class" form. We could consider it when we need encapsulation, but most of the time, the "options object pattern" is a much better and convenient solution.
diff --git a/GoF/classic/Creational/Factory/README.md b/GoF/classic/Creational/Factory/README.md
@@ -16,3 +16,5 @@ Factory makes it possible to delegate the instantiation logic. To implement this
   * An abstract representation of a Linux distro (abstract class or interface)
   * Concrete implementations of this abstraction (Debian, RedHat, Slackware)
   * A "class" with a factory method which will be responsible for instantiation 
+
+![Factory (classic)](Factory.png)
diff --git a/GoF/classic/Creational/Prototype/README.md b/GoF/classic/Creational/Prototype/README.md
@@ -27,3 +27,5 @@ In the clone method, we can:
   * Get the prototype of the original object separately with Object.getPrototypeOf()
   * Create a new object from this prototype with Object.create()
   * Merge the own properties of the original object with the inherited properties of the newly created object
+
+![Prototype (classic)](Prototype.png)
diff --git a/GoF/classic/Creational/Singleton/README.md b/GoF/classic/Creational/Singleton/README.md
@@ -19,3 +19,5 @@ Singleton is the key! To implement this pattern, we can:
   * Create a "class" with a private constructor
   * Create a static attribute that will contain the unique instance of our class
   * Create a static method that will check if the instance is unique and return it
+
+![Singleton (classic)](Singleton.png)
diff --git a/GoF/classic/Structural/Adapter/README.md b/GoF/classic/Structural/Adapter/README.md
@@ -12,3 +12,5 @@ Adapter is a well-known solution in this kind of situation. We need:
     
   * Abstract representations (generally interfaces) of the problem. Here we easily see that a digital interface is not compatible with an analog one.
   * Concrete implementations of these abstractions: e.g. HDMIToVGAAdapter & VGA. Here the adapter should be able to delegate some work to the adapted entity.
+
+![Adapter (classic)](Adapter.png)
diff --git a/GoF/classic/Structural/Bridge/README.md b/GoF/classic/Structural/Bridge/README.md
@@ -16,3 +16,5 @@ Here we need to split the hierarchy of classes and prefer composition over inher
   * Concrete implementations of both abstractions
   
 Of course, methods defined in the main abstract class delegate operations to the methods of the other abstraction.
+
+![Bridge (classic)](Bridge.png)
diff --git a/GoF/classic/Structural/Composite/README.md b/GoF/classic/Structural/Composite/README.md
@@ -15,3 +15,5 @@ The Composite design pattern is useful in this kind of situation. To implement t
   * An abstract representation of a toy (abstract class or interface)
   * Concrete toys, especially a simple one (ball) and a complex one (toy box)
   * Methods for the complex toy to manage (simple and complex) toys inside of it
+
+![Composite (classic)](Composite.png)
diff --git a/GoF/classic/Structural/Decorator/README.md b/GoF/classic/Structural/Decorator/README.md
@@ -17,4 +17,6 @@ To make this working, we need:
   * An abstract representation of a custom pizza (abstract class which is actually the abstract decorator)
   * Concrete decorators (ingredients) that will be used to add new flavors to a more basic pizza
 
+![Decorator (classic)](Decorator.png)
+
 N.B. JavaScript is a very flexible language. Whenever we need to build something step by step or add new functionalities dynamically to an object, we can do it more easily using the idiomatic mechanisms of JavaScript (which is not a class-based language). Class-style programming is a matter of taste here and may be useful when we need more encapsulation. However, the best solution is often the simplest one...
diff --git a/GoF/classic/Structural/Facade/README.md b/GoF/classic/Structural/Facade/README.md
@@ -13,3 +13,5 @@ Facade is often used to hide the underlying complexity of a system. To implement
   * Create an abstract representation of an Animal (abstract class or interface)
   * Create concrete implementations of this abstraction (Dog & Rabbit)
   * Create a "class" that will make it easy to use the concrete implementations (HowToFeedAnimals)
+
+![Facade (classic)](Facade.png)
diff --git a/GoF/classic/Structural/Flyweight/README.md b/GoF/classic/Structural/Flyweight/README.md
@@ -13,3 +13,5 @@ We can use Flyweight here, which is actually tied to Factory. A Factory handles
   * An abstract representation of a Linux distro (abstract class or interface)
   * Concrete implementations of this abstraction (Debian, RedHat, Slackware)
   * A "class" with a factory method which will be responsible for instantiation (contrary to a simple Factory method, some extra code is required to test if the wanted instance already exists or not)
+
+![Flyweight (classic)](Flyweight.png)
diff --git a/GoF/classic/Structural/Proxy/README.md b/GoF/classic/Structural/Proxy/README.md
@@ -15,3 +15,5 @@ We could consider an ATM as a proxy whose aim is to verify access to a bank acco
   * An abstract representation of a financial entity (abstract class or interface)
   * A concrete bank account which allows some operations
   * A proxy (ATM) which secures these operations and delegates when necessary
+
+![Proxy (classic)](Proxy.png)
diff --git a/GoF/idiomatic/Behavioral/ChainOfResponsibility/README.md b/GoF/idiomatic/Behavioral/ChainOfResponsibility/README.md
@@ -18,4 +18,6 @@ Everytime a request should be handled by multiple (and complementary) processing
 
 Each of these objects should have at least their own method ("go") whose action will be specific to the associated sport. But each of these particular "go" methods will also transfer some work to the next relay, chosen by the client code.
 
+![Chain of Responsibility (idiomatic)](ChainOfResponsibility.png)
+
 N.B. This design pattern should not be confused with simple method chaining in JavaScript.
diff --git a/GoF/idiomatic/Behavioral/Command/README.md b/GoF/idiomatic/Behavioral/Command/README.md
@@ -11,7 +11,7 @@ In computer science terms, it seems obvious that the restaurant has to handle a
 # Solution
 
 The Command pattern is a great help here. In this pattern terminology, we will say that:
-  ***
+ 
   * The restaurant is the "invoker" who creates and handles new orders internally.
   * The order is the "command", in other words the request which comes from a client.
   * The customer is the "receiver" of the order.
@@ -22,3 +22,4 @@ To implement this pattern, we then need three object literals to represent each
   * The order has a reference to a given customer and makes him pay using its "deliver" method.
   * The restaurant is a more complex object with a collection (array) of orders and an essential method ("prepareOrders") that start the delivery of each order.
 
+![Command (idiomatic)](Command.png)
diff --git a/GoF/idiomatic/Behavioral/Interpreter/README.md b/GoF/idiomatic/Behavioral/Interpreter/README.md
@@ -14,3 +14,5 @@ The Interpreter pattern is exactly what we need to tell JavaScript how to interp
   * A basic object literal to represent the context (the sonata)
 
 The distinction between terminal and nonterminal expressions in the Interpreter pattern is a bit like the distinction between simple and composed elements in the Composite pattern. A note is a terminal expression because it is an "elementary symbol" of the grammar. However, an arpeggio is a nonterminal expression because it can be considered as a group of notes.
+
+![Interpreter (idiomatic)](Interpreter.png)
diff --git a/GoF/idiomatic/Behavioral/Iterator/README.md b/GoF/idiomatic/Behavioral/Iterator/README.md
@@ -16,3 +16,5 @@ Iterator is the design pattern we need for this. To implement this pattern, we c
   * A very basic object literal representing a library (which is a collection of books) 
 
 In this particular case, a collection is an iterable object whereas a catalog is an iterator object.
+
+![Iterator (idiomatic)](Iterator.png)
diff --git a/GoF/idiomatic/Behavioral/Mediator/README.md b/GoF/idiomatic/Behavioral/Mediator/README.md
@@ -16,3 +16,5 @@ This is exactly the solution proposed by the Mediator pattern. To implement this
   * An object literal to represent Harry (who is the mediator)
 
 Tom and Dick have both a "send" and "receive" methods, but they do not communicate directly. They communicate through the mediator who acts a bit like a router. Thus, Harry must have a reference to both neighbor objects and, depending on the sender, he will know the receiver... 
+
+![Mediator (idiomatic)](Mediator.png)
diff --git a/GoF/idiomatic/Behavioral/Memento/README.md b/GoF/idiomatic/Behavioral/Memento/README.md
@@ -14,3 +14,5 @@ Here we have to use bookmarks to save interesting webpages and the Memento patte
   * An object literal containing a collection (array) of bookmarks (this is the "caretaker")
 
 When the "saveCurrentPage" method is called, a new bookmark (memento) is created and this one can be stored by the bookmarks manager.
+
+![Memento (idiomatic)](Memento.png)
diff --git a/GoF/idiomatic/Behavioral/Observer/README.md b/GoF/idiomatic/Behavioral/Observer/README.md
@@ -16,3 +16,5 @@ The Observer design pattern helps a lot when we have to implement an event-drive
   * An object literal to represent the observable entity 
 
 The observable object (gazelle) maintains a list (array) of predators. Then, depending on its actions (determined by the client code), its "notifyPredators" method may be called. This method would iterate through the array of predators and make them attack.
+
+![Observer (idiomatic)](Observer.png)
diff --git a/GoF/idiomatic/Behavioral/State/README.md b/GoF/idiomatic/Behavioral/State/README.md
@@ -14,3 +14,5 @@ The State design pattern is obviously what we should use here. We need:
   * Object literals to represent available states (on/off)
 
 Contrary to the Strategy pattern, we can access the context directly from available states (our PC is used as a parameter of the main method of both states). This allows state changes from states themselves.
+
+![State (idiomatic)](State.png)
diff --git a/GoF/idiomatic/Behavioral/Strategy/README.md b/GoF/idiomatic/Behavioral/Strategy/README.md
@@ -15,3 +15,5 @@ The Strategy design pattern is exactly what we need in this kind of situation. T
   * Object literals to represent available strategies (offense and defense)
 
 Offensive and defensive strategies seem to share a "fight" method, but the performed action is obviously different. Moreover, the context (fighting game) must have a reference to the current strategy because its main method ("play") is directly influenced by the selected strategy in the client code.
+
+![Strategy (idiomatic)](Strategy.png)
diff --git a/GoF/idiomatic/Behavioral/Template/README.md b/GoF/idiomatic/Behavioral/Template/README.md
@@ -16,3 +16,5 @@ The Template design pattern is an ideal candidate to express with code this kind
   * A general function that can be used as a template
 
 Constructions expressed with object literals should have common methods like "foundations", "walls" or "roof" that symbolize key steps in every construction project. Then the template function can be used in the client code, passing it a construction as argument. This template function will create a house or a building by calling each method of the given construction in the right order.
+
+![Template (idiomatic)](Template.png)
diff --git a/GoF/idiomatic/Behavioral/Visitor/README.md b/GoF/idiomatic/Behavioral/Visitor/README.md
@@ -6,7 +6,7 @@ I love history and I would like to visit more old monuments. But these are treas
 
 If any individual can enter a historical monument and degrade it, we can say that the original structure is definitely lost. To preserve that structure, people should not be allowed to enter historical monuments without permission and supervision.
 
-Applied to JavaScript, we could say this is very easy to modify directly the structure of an object and we may be tempted to do so. *But this is not what we want...
+Applied to JavaScript, we could say this is very easy to modify directly the structure of an object and we may be tempted to do so. But this is not what we want...
 
 # Solution
 
@@ -18,3 +18,5 @@ To implement the Visitor design pattern, we can have:
   * An object literal to represent a tourist (visitor)
 
 Each monument has an "accept" method which takes a visitor object as parameter. The role of this method is to call the "visit" method of the visitor with a reference to the monument on which the "accept" method was called (using "this"). 
+
+![Visitor (idiomatic)](Visitor.png)
diff --git a/GoF/idiomatic/Creational/AbstractFactory/README.md b/GoF/idiomatic/Creational/AbstractFactory/README.md
@@ -12,3 +12,5 @@ As a system administrator, you only want to know how to get an instance of a spe
 # Solution
 
 AbstractFactory is a great solution here. We could consider it as a superset of the Factory pattern, but there is significantly more work to do. Indeed, we need a factory function for each OS family and of course a factory of factories that will be the entry point of the associated module.
+
+![Abstract Factory (idiomatic)](AbstractFactory.png)
diff --git a/GoF/idiomatic/Creational/Builder/README.md b/GoF/idiomatic/Creational/Builder/README.md
@@ -16,4 +16,6 @@ The Builder pattern allows us to build our PC step by step with only three objec
 
 When the manufacturer will receive an order, it will ask its workforce to build the custom PC step by step through its "manufacture" method.
 
+![Builder (idiomatic)](Builder.png)
+
 N.B. Since we do not use constructor functions in the idiomatic style, this version of the Builder pattern is not a solution to the telescoping constructor problem. But you might be interested in the "Object Specifier" pattern...
diff --git a/GoF/idiomatic/Creational/Factory/README.md b/GoF/idiomatic/Creational/Factory/README.md
@@ -14,3 +14,5 @@ For the sake of clarity and performance, it may be nice to delegate the instanti
 Factory makes it possible to do so. To implement this design pattern, we only need to create a function that will return objects.
 
 In JavaScript, a function or method that returns objects is generally considered as a factory. It is a well-known idiomatic alternative to the use of the "new" keyword along with constructor functions.
+
+![Factory (idiomatic)](Factory.png)
diff --git a/GoF/idiomatic/Creational/Prototype/README.md b/GoF/idiomatic/Creational/Prototype/README.md
@@ -21,4 +21,6 @@ We need only two things in this situation:
   * An object (literal) that we want to clone (e.g. invoice)
   * A custom cloning function that will take the object to clone as a parameter
 
+![Prototype (idiomatic)](Prototype.png)
+
 N.B. Most of the time, it is not even useful to have an exact copy of an object in JavaScript. The important thing is often to be able to use the same properties on several objects, and for that purpose, a simple Object.create() is generally good enough.
diff --git a/GoF/idiomatic/Creational/Singleton/README.md b/GoF/idiomatic/Creational/Singleton/README.md
@@ -17,3 +17,5 @@ Therefore, I cannot be sure that there will not be other instances of myself in
 Singleton is the key!
 
 But due to the nature of JavaScript, an object literal is already a sort of Singleton. Each object literal is unique and is built from the prototype of Object. In a way, we could see an object literal as a an anonymous class whose instance is delivered immediately. However, we could also argue that an object literal is nothing more than an instance of Object, which is actually true. With this in mind, it is quite obvious that an object literal is not a pure Singleton, but if flexibility matters, it is quite reasonable to consider it as a Singleton.
+
+![Singleton (idiomatic)](Singleton.png)
diff --git a/GoF/idiomatic/Structural/Adapter/README.md b/GoF/idiomatic/Structural/Adapter/README.md
@@ -14,3 +14,5 @@ Adapter is a well-known solution in this kind of situation. Here we need very fe
   * An object (literal) that represents the HDMI to VGA adapter
 
 The latter must have a reference to the first one and must be the entry point of the module. Then the main method of the adapter will delegate some work to the main method of the VGA connection.
+
+![Adapter (idiomatic)](Adapter.png)
diff --git a/GoF/idiomatic/Structural/Bridge/README.md b/GoF/idiomatic/Structural/Bridge/README.md
@@ -16,3 +16,5 @@ The best solution is to use a "Bridge" between a simple recipe and a sauce. This
   * Object (literals) to describe available sauces
 
 In the client code, the instance of sauce passed to the recipe function will give us the final meal.
+
+![Bridge (idiomatic)](Bridge.png)
diff --git a/GoF/idiomatic/Structural/Composite/README.md b/GoF/idiomatic/Structural/Composite/README.md
diff --git a/GoF/idiomatic/Structural/Decorator/README.md b/GoF/idiomatic/Structural/Decorator/README.md
diff --git a/GoF/idiomatic/Structural/Facade/README.md b/GoF/idiomatic/Structural/Facade/README.md
diff --git a/GoF/idiomatic/Structural/Flyweight/README.md b/GoF/idiomatic/Structural/Flyweight/README.md
diff --git a/GoF/idiomatic/Structural/Proxy/README.md b/GoF/idiomatic/Structural/Proxy/README.md
