iluwatar · hugo-vrijswijk · Sep 22, 2015 · Sep 23, 2015 · Sep 23, 2015 · Sep 24, 2015
diff --git a/.travis.yml b/.travis.yml
@@ -1,20 +1,18 @@
 language: java
-
 jdk:
-  - oraclejdk8
+- oraclejdk8
 
 env:
   global:
   - GH_REF: github.com/iluwatar/java-design-patterns.git
-  - secure: "LxTDuNS/rBWIvKkaEqr79ImZAe48mCdoYCF41coxNXgNoippo4GIBArknqtv+XvdkiuRZ1yGyj6pn8GU33c/yn+krddTUkVCwTbVatbalW5jhQjDbHYym/JcxaK9ZS/3JTeGcWrBgiPqHEEDhCf26vPZsXoMSeVCEORVKTp1BSg="
-
-before_install:
-  - "export DISPLAY=:99.0"
-  - "sh -e /etc/init.d/xvfb start"
+  - secure: LxTDuNS/rBWIvKkaEqr79ImZAe48mCdoYCF41coxNXgNoippo4GIBArknqtv+XvdkiuRZ1yGyj6pn8GU33c/yn+krddTUkVCwTbVatbalW5jhQjDbHYym/JcxaK9ZS/3JTeGcWrBgiPqHEEDhCf26vPZsXoMSeVCEORVKTp1BSg=
 
+before_install:
+- export DISPLAY=:99.0
+- sh -e /etc/init.d/xvfb start
+
 after_success:
-  - mvn clean test jacoco:report coveralls:report
-  - bash update-ghpages.sh
+- mvn clean test jacoco:report coveralls:report
+- bash update-ghpages.sh
 
-# Migration to container-based infrastructure  
 sudo: false
diff --git a/README.md b/README.md
@@ -38,7 +38,6 @@ If you are willing to contribute to the project you will find the relevant infor
 
 # Credits
 
-* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
 * [Effective Java (2nd Edition)](http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683)
 * [Java Generics and Collections](http://www.amazon.com/Java-Generics-Collections-Maurice-Naftalin/dp/0596527756/)
 * [Let's Modify the Objects-First Approach into Design-Patterns-First](http://edu.pecinovsky.cz/papers/2006_ITiCSE_Design_Patterns_First.pdf)
@@ -48,7 +47,6 @@ If you are willing to contribute to the project you will find the relevant infor
 * [Patterns of Enterprise Application Architecture](http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420)
 * [Spring Data](http://www.amazon.com/Spring-Data-Mark-Pollack/dp/1449323952/ref=sr_1_1)
 * [J2EE Design Patterns](http://www.amazon.com/J2EE-Design-Patterns-William-Crawford/dp/0596004273/ref=sr_1_2)
-* [Pattern Oriented Software Architecture Vol I-V](http://www.amazon.com/Pattern-Oriented-Software-Architecture-Volume-Patterns/dp/0471958697)
 
 # License
 

diff --git a/abstract-factory/index.md b/abstract-factory/index.md
@@ -4,7 +4,9 @@ title: Abstract Factory
 folder: abstract-factory
 permalink: /patterns/abstract-factory/
 categories: Creational
-tags: Java
+tags: 
+ - Java
+ - Gang Of Four
 ---
 
 **Intent:** Provide an interface for creating families of related or dependent
@@ -22,3 +24,7 @@ objects without specifying their concrete classes.
 **Real world examples:**
 
 * [javax.xml.parsers.DocumentBuilderFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/parsers/DocumentBuilderFactory.html)
+
+**Credits**
+
+* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
diff --git a/abstract-factory/pom.xml b/abstract-factory/pom.xml
@@ -5,7 +5,7 @@
   <parent>
     <groupId>com.iluwatar</groupId>
     <artifactId>java-design-patterns</artifactId>
-    <version>1.6.0</version>
+    <version>1.7.0</version>
   </parent>
   <artifactId>abstract-factory</artifactId>
   <dependencies>

diff --git a/abstract-factory/src/main/java/com/iluwatar/abstractfactory/App.java b/abstract-factory/src/main/java/com/iluwatar/abstractfactory/App.java
@@ -3,12 +3,21 @@
 
 /**
  * 
+ * The Abstract Factory pattern provides a way to encapsulate a group of individual 
+ * factories that have a common theme without specifying their concrete classes. In 
+ * normal usage, the client software creates a concrete implementation of the abstract 
+ * factory and then uses the generic interface of the factory to create the concrete 
+ * objects that are part of the theme. The client does not know (or care) which 
+ * concrete objects it gets from each of these internal factories, since it uses only 
+ * the generic interfaces of their products. This pattern separates the details of 
+ * implementation of a set of objects from their general usage and relies on object 
+ * composition, as object creation is implemented in methods exposed in the factory 
+ * interface.
+ * <p>
  * The essence of the Abstract Factory pattern is a factory interface
  * ({@link KingdomFactory}) and its implementations ({@link ElfKingdomFactory},
- * {@link OrcKingdomFactory}).
- * <p>
- * The example uses both concrete implementations to create a king, a castle and
- * an army.
+ * {@link OrcKingdomFactory}). The example uses both concrete implementations to 
+ * create a king, a castle and an army.
  * 
  */
 public class App {

diff --git a/adapter/index.md b/adapter/index.md
@@ -4,7 +4,9 @@ title: Adapter
 folder: adapter
 permalink: /patterns/adapter/
 categories: Structural
-tags: Java
+tags:
+ - Java
+ - Gang Of Four
 ---
 
 **Intent:** Convert the interface of a class into another interface the clients
@@ -22,3 +24,7 @@ incompatible interfaces.
 **Real world examples:**
 
 * [java.util.Arrays#asList()](http://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#asList%28T...%29)
+
+**Credits**
+
+* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
diff --git a/adapter/pom.xml b/adapter/pom.xml
@@ -5,7 +5,7 @@
   <parent>
     <groupId>com.iluwatar</groupId>
     <artifactId>java-design-patterns</artifactId>
-    <version>1.6.0</version>
+    <version>1.7.0</version>
   </parent>
   <artifactId>adapter</artifactId>
   <dependencies>

diff --git a/adapter/src/main/java/com/iluwatar/adapter/App.java b/adapter/src/main/java/com/iluwatar/adapter/App.java
@@ -1,7 +1,13 @@
 package com.iluwatar.adapter;
 
 /**
- * 
+ *
+ * An adapter helps two incompatible interfaces to work together. This is the real 
+ * world definition for an adapter. Interfaces may be incompatible but the inner 
+ * functionality should suit the need. The Adapter design pattern allows otherwise 
+ * incompatible classes to work together by converting the interface of one class 
+ * into an interface expected by the clients.
+ * <p>
  * There are two variations of the Adapter pattern: The class adapter implements
  * the adaptee's interface whereas the object adapter uses composition to
  * contain the adaptee in the adapter object. This example uses the object

diff --git a/async-method-invocation/pom.xml b/async-method-invocation/pom.xml
@@ -5,7 +5,7 @@
   <parent>
     <groupId>com.iluwatar</groupId>
     <artifactId>java-design-patterns</artifactId>
-    <version>1.6.0</version>
+    <version>1.7.0</version>
   </parent>
   <artifactId>async-method-invocation</artifactId>
   <dependencies>

diff --git a/bridge/index.md b/bridge/index.md
@@ -4,7 +4,9 @@ title: Bridge
 folder: bridge
 permalink: /patterns/bridge/
 categories: Structural
-tags: Java
+tags:
+ - Java
+ - Gang Of Four
 ---
 
 **Intent:** Decouple an abstraction from its implementation so that the two can
@@ -20,3 +22,7 @@ vary 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.
+
+**Credits**
+
+* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
diff --git a/bridge/pom.xml b/bridge/pom.xml
@@ -5,7 +5,7 @@
   <parent>
     <groupId>com.iluwatar</groupId>
     <artifactId>java-design-patterns</artifactId>
-    <version>1.6.0</version>
+    <version>1.7.0</version>
   </parent>
   <artifactId>bridge</artifactId>
   <dependencies>

diff --git a/bridge/src/main/java/com/iluwatar/bridge/App.java b/bridge/src/main/java/com/iluwatar/bridge/App.java
@@ -2,6 +2,9 @@
 
 /**
  * 
+ * The Bridge pattern can also be thought of as two layers of abstraction. With Bridge, 
+ * you can decouple an abstraction from its implementation so that the two can vary independently.
+ * <p>
  * In Bridge pattern both abstraction ({@link MagicWeapon}) and implementation
  * ({@link MagicWeaponImpl}) have their own class hierarchies. The interface of the
  * implementations can be changed without affecting the clients.

diff --git a/builder/index.md b/builder/index.md
@@ -4,7 +4,9 @@ title: Builder
 folder: builder
 permalink: /patterns/builder/
 categories: Creational
-tags: Java
+tags:
+ - Java
+ - Gang Of Four
 ---
 
 **Intent:** Separate the construction of a complex object from its
@@ -22,3 +24,7 @@ representations.
 
 * [java.lang.StringBuilder](http://docs.oracle.com/javase/8/docs/api/java/lang/StringBuilder.html)
 * [Apache Camel builders](https://github.com/apache/camel/tree/0e195428ee04531be27a0b659005e3aa8d159d23/camel-core/src/main/java/org/apache/camel/builder)
+
+**Credits**
+
+* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
diff --git a/builder/pom.xml b/builder/pom.xml
@@ -5,7 +5,7 @@
   <parent>
     <groupId>com.iluwatar</groupId>
     <artifactId>java-design-patterns</artifactId>
-    <version>1.6.0</version>
+    <version>1.7.0</version>
   </parent>
   <artifactId>builder</artifactId>
   <dependencies>

diff --git a/builder/src/main/java/com/iluwatar/builder/App.java b/builder/src/main/java/com/iluwatar/builder/App.java
@@ -4,7 +4,20 @@
 
 /**
  * 
- * This is the Builder pattern variation as described by Joshua Bloch in
+ * The intention of the Builder pattern is to find a solution to the telescoping 
+ * constructor anti-pattern. The telescoping constructor anti-pattern occurs when the 
+ * increase of object constructor parameter combination leads to an exponential list 
+ * of constructors. Instead of using numerous constructors, the builder pattern uses 
+ * another object, a builder, that receives each initialization parameter step by step 
+ * and then returns the resulting constructed object at once.
+ * <p>
+ * The Builder pattern has another benefit. It can be used for objects that contain 
+ * flat data (html code, SQL query, X.509 certificate...), that is to say, data that 
+ * can't be easily edited. This type of data cannot be edited step by step and must 
+ * be edited at once. The best way to construct such an object is to use a builder 
+ * class.
+ * <p>
+ * In this example we have the Builder pattern variation as described by Joshua Bloch in
  * Effective Java 2nd Edition.
  * <p>
  * We want to build {@link Hero} objects, but its construction is complex because of the

diff --git a/business-delegate/pom.xml b/business-delegate/pom.xml
@@ -6,7 +6,7 @@
 	<parent>
 		<groupId>com.iluwatar</groupId>
 		<artifactId>java-design-patterns</artifactId>
-		<version>1.6.0</version>
+		<version>1.7.0</version>
 	</parent>
 	<artifactId>business-delegate</artifactId>
 	<dependencies>

diff --git a/callback/pom.xml b/callback/pom.xml
@@ -5,7 +5,7 @@
   <parent>
     <groupId>com.iluwatar</groupId>
     <artifactId>java-design-patterns</artifactId>
-    <version>1.6.0</version>
+    <version>1.7.0</version>
   </parent>
   <artifactId>callback</artifactId>
   <dependencies>

diff --git a/chain/index.md b/chain/index.md
@@ -4,7 +4,9 @@ title: Chain of responsibility
 folder: chain
 permalink: /patterns/chain/
 categories: Behavioral
-tags: Java
+tags:
+ - Java
+ - Gang Of Four
 ---
 
 **Intent:** Avoid coupling the sender of a request to its receiver by giving
@@ -23,3 +25,7 @@ objects and pass the request along the chain until an object handles it.
 
 * [java.util.logging.Logger#log()](http://docs.oracle.com/javase/8/docs/api/java/util/logging/Logger.html#log%28java.util.logging.Level,%20java.lang.String%29)
 * [Apache Commons Chain](https://commons.apache.org/proper/commons-chain/index.html)
+
+**Credits**
+
+* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
diff --git a/chain/pom.xml b/chain/pom.xml
@@ -5,7 +5,7 @@
   <parent>
     <groupId>com.iluwatar</groupId>
     <artifactId>java-design-patterns</artifactId>
-    <version>1.6.0</version>
+    <version>1.7.0</version>
   </parent>
   <artifactId>chain</artifactId>
   <dependencies>

diff --git a/chain/src/main/java/com/iluwatar/chain/App.java b/chain/src/main/java/com/iluwatar/chain/App.java
@@ -2,10 +2,16 @@
 
 /**
  * 
- * Chain of Responsibility organizes request handlers ({@link RequestHandler}) into a
- * chain where each handler has a chance to act on the request on its turn. In
- * this example the king ({@link OrcKing}) makes requests and the military orcs
- * ({@link OrcCommander}, {@link OrcOfficer}, {@link OrcSoldier}) form the handler chain.
+ * The Chain of Responsibility pattern is a design pattern consisting of command 
+ * objects and a series of processing objects. Each processing object contains 
+ * logic that defines the types of command objects that it can handle; the rest are 
+ * passed to the next processing object in the chain. A mechanism also exists for 
+ * adding new processing objects to the end of this chain.
+ * <p>
+ * In this example we organize the request handlers ({@link RequestHandler}) into a
+ * chain where each handler has a chance to act on the request on its turn. Here
+ * the king ({@link OrcKing}) makes requests and the military orcs ({@link OrcCommander}, 
+ * {@link OrcOfficer}, {@link OrcSoldier}) form the handler chain.
  * 
  */
 public class App {

diff --git a/command/index.md b/command/index.md
@@ -4,7 +4,9 @@ title: Command
 folder: command
 permalink: /patterns/command/
 categories: Behavioral
-tags: Java
+tags: 
+ - Java
+ - Gang Of Four
 ---
 
 **Intent:** Encapsulate a request as an object, thereby letting you
@@ -30,3 +32,7 @@ support undoable operations.
 **Real world examples:**
 
 * [java.lang.Runnable](http://docs.oracle.com/javase/8/docs/api/java/lang/Runnable.html)
+
+**Credits**
+
+* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
diff --git a/command/pom.xml b/command/pom.xml
@@ -5,7 +5,7 @@
   <parent>
     <groupId>com.iluwatar</groupId>
     <artifactId>java-design-patterns</artifactId>
-    <version>1.6.0</version>
+    <version>1.7.0</version>
   </parent>
   <artifactId>command</artifactId>
   <dependencies>

diff --git a/command/src/main/java/com/iluwatar/command/App.java b/command/src/main/java/com/iluwatar/command/App.java
@@ -2,7 +2,9 @@
 
 /**
  * 
- * In Command pattern actions are objects that can be executed and undone. 
+ * The Command pattern is a behavioral design pattern in which an object is used to encapsulate all information 
+ * needed to perform an action or trigger an event at a later time. This information includes the method name, 
+ * the object that owns the method and values for the method parameters.
  * <p>
  * Four terms always associated with the command pattern are command, receiver, invoker and client. A command 
  * object (spell) knows about the receiver (target) and invokes a method of the receiver. Values for parameters of 

diff --git a/composite/index.md b/composite/index.md
@@ -4,7 +4,9 @@ title: Composite
 folder: composite
 permalink: /patterns/composite/
 categories: Structural
-tags: Java
+tags:
+ - Java
+ - Gang Of Four
 ---
 
 **Intent:** Compose objects into tree structures to represent part-whole
@@ -22,3 +24,7 @@ of objects uniformly.
 
 * [java.awt.Container](http://docs.oracle.com/javase/8/docs/api/java/awt/Container.html) and [java.awt.Component](http://docs.oracle.com/javase/8/docs/api/java/awt/Component.html)
 * [Apache Wicket](https://github.com/apache/wicket) component tree, see [Component](https://github.com/apache/wicket/blob/91e154702ab1ff3481ef6cbb04c6044814b7e130/wicket-core/src/main/java/org/apache/wicket/Component.java) and [MarkupContainer](https://github.com/apache/wicket/blob/b60ec64d0b50a611a9549809c9ab216f0ffa3ae3/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java)
+
+**Credits**
+
+* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
diff --git a/composite/pom.xml b/composite/pom.xml
@@ -5,7 +5,7 @@
   <parent>
     <groupId>com.iluwatar</groupId>
     <artifactId>java-design-patterns</artifactId>
-    <version>1.6.0</version>
+    <version>1.7.0</version>
   </parent>
   <artifactId>composite</artifactId>
   <dependencies>

diff --git a/composite/src/main/java/com/iluwatar/composite/App.java b/composite/src/main/java/com/iluwatar/composite/App.java
@@ -1,10 +1,14 @@
 package com.iluwatar.composite;
 
 /**
- * 
- * With Composite we can treat tree hierarchies of objects with uniform
- * interface ({@link LetterComposite}). In this example we have sentences composed of
- * words composed of letters.
+ * The Composite pattern is a partitioning design pattern. The Composite pattern 
+ * describes that a group of objects is to be treated in the same way as a single 
+ * instance of an object. The intent of a composite is to "compose" objects into 
+ * tree structures to represent part-whole hierarchies. Implementing the Composite 
+ * pattern lets clients treat individual objects and compositions uniformly.
+ * <p>
+ * In this example we have sentences composed of words composed of letters. All of
+ * the objects can be treated through the same interface ({@link LetterComposite}).
  * 
  */
 public class App {