Work towards #56: Splitting up the README

I did the job and splitted up the readme, hopefully everything was
splitted correctly...

abstract-factory/index.md

@@ -0,0 +1,25 @@
+---
+layout: pattern
+title: Abstract Factory
+folder: abstract-factory
+categories:
+ - pattern_cat
+ - creational
+tags: pattern_tag
+---
+
+**Intent:** Provide an interface for creating families of related or dependent
+objects without specifying their concrete classes.
+
+![alt text](./etc/abstract-factory_1.png "Abstract Factory")
+
+**Applicability:** Use the Abstract Factory pattern when
+
+* a system should be independent of how its products are created, composed and represented
+* a system should be configured with one of multiple families of products
+* a family of related product objects is designed to be used together, and you need to enforce this constraint
+* you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations
+
+**Real world examples:**
+
+* [javax.xml.parsers.DocumentBuilderFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/parsers/DocumentBuilderFactory.html)

adapter/index.md

@@ -0,0 +1,23 @@
+---
+layout: pattern
+title: Adapter
+folder: adapter
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** Convert the interface of a class into another interface the clients
+expect. Adapter lets classes work together that couldn't otherwise because of
+incompatible interfaces.
+
+![alt text](./etc/adapter_1.png "Adapter")
+
+**Applicability:** Use the Adapter pattern when
+
+* you want to use an existing class, and its interface does not match the one you need
+* you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces
+* you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.
+
+**Real world examples:**
+
+* [java.util.Arrays#asList()](http://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#asList%28T...%29)

async-method-invocation/index.md

@@ -0,0 +1,26 @@
+---
+layout: pattern
+title: Async Method Invocation
+folder: async-method-invocation
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** Asynchronous method invocation is pattern where the calling thread
+is not blocked while waiting results of tasks. The pattern provides parallel
+processing of multiple independent tasks and retrieving the results via
+callbacks or waiting until everything is done. 
+
+![alt text](./etc/async-method-invocation.png "Async Method Invocation")
+
+**Applicability:** Use async method invocation pattern when
+
+* you have multiple independent tasks that can run in parallel
+* you need to improve the performance of a group of sequential tasks
+* you have limited amount of processing capacity or long running tasks and the
+  caller should not wait the tasks to be ready
+
+**Real world examples:**
+
+* [FutureTask](http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/FutureTask.html), [CompletableFuture](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html) and [ExecutorService](http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html) (Java)
+* [Task-based Asynchronous Pattern](https://msdn.microsoft.com/en-us/library/hh873175.aspx) (.NET)

bridge/index.md

@@ -0,0 +1,21 @@
+---
+layout: pattern
+title: Bridge
+folder: bridge
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** Decouple an abstraction from its implementation so that the two can
+vary independently.
+
+
+![alt text](./etc/bridge_1.png "Bridge")
+
+**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.

builder/index.md

@@ -0,0 +1,23 @@
+---
+layout: pattern
+title: Builder
+folder: builder
+categories: creational
+tags: pattern_tag
+---
+
+**Intent:** Separate the construction of a complex object from its
+representation so that the same construction process can create different
+representations.
+
+![alt text](./etc/builder_1.png "Builder")
+
+**Applicability:** Use the Builder pattern when
+
+* the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled
+* the construction process must allow different representations for the object that's constructed
+
+**Real world examples:**
+
+* [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)

business-delegate/index.md

@@ -0,0 +1,20 @@
+---
+layout: pattern
+title: Business Delegate
+folder: business-delegate
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** The Business Delegate pattern adds an abstraction layer between
+presentation and business tiers. By using the pattern we gain loose coupling
+between the tiers and encapsulate knowledge about how to locate, connect to,
+and interact with the business objects that make up the application.
+
+![alt text](./etc/business-delegate.png "Business Delegate")
+
+**Applicability:** Use the Business Delegate pattern when
+
+* you want loose coupling between presentation and business tiers
+* you want to orchestrate calls to multiple business services
+* you want to encapsulate service lookups and service calls

callback/index.md

@@ -0,0 +1,21 @@
+---
+layout: pattern
+title: Callback
+folder: callback
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** Callback is a piece of executable code that is passed as an
+argument to other code, which is expected to call back (execute) the argument
+at some convenient time.
+
+![alt text](./etc/callback.png "Callback")
+
+**Applicability:** Use the Callback pattern when
+
+* when some arbitrary synchronous or asynchronous action must be performed after execution of some defined activity.
+
+**Real world examples:**
+
+* [CyclicBarrier] (http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/CyclicBarrier.html#CyclicBarrier%28int,%20java.lang.Runnable%29) constructor can accept callback that will be triggered every time when barrier is tripped.

chain-of-responsibility/index.md

@@ -0,0 +1,24 @@
+---
+layout: pattern
+title: Chain of responsibility
+folder: chain-of-responsibility
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** Avoid coupling the sender of a request to its receiver by giving
+more than one object a chance to handle the request. Chain the receiving
+objects and pass the request along the chain until an object handles it.
+
+![alt text](./chain/etc/chain_1.png "Chain of Responsibility")
+
+**Applicability:** Use Chain of Responsibility when
+
+* more than one object may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically
+* you want to issue a request to one of several objects without specifying the receiver explicitly
+* the set of objects that can handle a request should be specified dynamically
+
+**Real world examples:**
+
+* [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)

command/index.md

@@ -0,0 +1,31 @@
+---
+layout: pattern
+title: Command
+folder: command
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** Encapsulate a request as an object, thereby letting you
+parameterize clients with different requests, queue or log requests, and
+support undoable operations.
+
+![alt text](./etc/command.png "Command")
+
+**Applicability:** Use the Command pattern when you want to
+
+* parameterize objects by an action to perform. You can express such parameterization in a procedural language with a callback function, that is, a function that's registered somewhere to be called at a later point. Commands are an object-oriented replacement for callbacks.
+* specify, queue, and execute requests at different times. A Command object can have a lifetime independent of the original request. If the receiver of a request can be represented in an address space-independent way, then you can transfer a command object for the request to a different process and fulfill the request there
+* support undo. The Command's execute operation can store state for reversing its effects in the command itself. The Command interface must have an added Unexecute operation that reverses the effects of a previous call to execute. Executed commands are stored in a history list. Unlimited-level undo and redo is achieved by traversing this list backwards and forwards calling unexecute and execute, respectively
+* support logging changes so that they can be reapplied in case of a system crash. By augmenting the Command interface with load and store operations, you can keep a persistent log of changes. Recovering from a crash involves reloading logged commands from disk and re-executing them with the execute operation
+* structure a system around high-level operations build on primitive operations. Such a structure is common in information systems that support transactions. A transaction encapsulates a set of changes to data. The Command pattern offers a way to model transactions. Commands have a common interface, letting you invoke all transactions the same way. The pattern also makes it easy to extend the system with new transactions
+
+**Typical Use Case:**
+
+* to keep a history of requests
+* implement callback functionality
+* implement the undo functionality
+
+**Real world examples:**
+
+* [java.lang.Runnable](http://docs.oracle.com/javase/8/docs/api/java/lang/Runnable.html)

composite/index.md

@@ -0,0 +1,23 @@
+---
+layout: pattern
+title: Composite
+folder: composite
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** Compose objects into tree structures to represent part-whole
+hierarchies. Composite lets clients treat individual objects and compositions
+of objects uniformly.
+
+![alt text](./etc/composite_1.png "Composite")
+
+**Applicability:** Use the Composite pattern when
+
+* you want to represent part-whole hierarchies of objects
+* you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly
+
+**Real world examples:**
+
+* [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)

dao/index.md

@@ -0,0 +1,17 @@
+---
+layout: pattern
+title: Data Access Object
+folder: dao
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** Object provides an abstract interface to some type of database or
+other persistence mechanism.
+
+![alt text](./etc/dao.png "Data Access Object")
+
+**Applicability:** Use the Data Access Object in any of the following situations
+
+* when you want to consolidate how the data layer is accessed
+* when you want to avoid writing multiple data retrieval/persistence layers

decorator/index.md

@@ -0,0 +1,19 @@
+---
+layout: pattern
+title: Decorator
+folder: decorator
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** Attach additional responsibilities to an object dynamically.
+Decorators provide a flexible alternative to subclassing for extending
+functionality.
+
+![alt text](./etc/decorator_1.png "Decorator")
+
+**Applicability:** Use Decorator
+
+* to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects
+* for responsibilities that can be withdrawn
+* when extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination. Or a class definition may be hidden or otherwise unavailable for subclassing

dependency-injection/index.md

@@ -0,0 +1,21 @@
+---
+layout: pattern
+title: Dependency Injection
+folder: dependency-injection
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** Dependency Injection is a software design pattern in which one or
+more dependencies (or services) are injected, or passed by reference, into a
+dependent object (or client) and are made part of the client's state. The
+pattern separates the creation of a client's dependencies from its own
+behavior, which allows program designs to be loosely coupled and to follow the
+inversion of control and single responsibility principles.
+
+![alt text](./etc/dependency-injection.png "Dependency Injection")
+
+**Applicability:** Use the Dependency Injection pattern when
+
+* when you need to remove knowledge of concrete implementation from object
+* to enable unit testing of classes in isolation using mock objects or stubs

double-checked-locking/index.md

@@ -0,0 +1,19 @@
+---
+layout: pattern
+title: Double Checked Locking
+folder: double-checked-locking
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** Reduce the overhead of acquiring a lock by first testing the
+locking criterion (the "lock hint") without actually acquiring the lock. Only
+if the locking criterion check indicates that locking is required does the
+actual locking logic proceed.
+
+![alt text](./etc/double_checked_locking_1.png "Double Checked Locking")
+
+**Applicability:** Use the Double Checked Locking pattern when
+
+* there is a concurrent access in object creation, e.g. singleton, where you want to create single instance of the same class and checking if it's null or not maybe not be enough when there are two or more threads that checks if instance is null or not.
+* there is a concurrent access on a method where method's behaviour changes according to the some constraints and these constraint change within this method.

double-dispatch/index.md

@@ -0,0 +1,20 @@
+---
+layout: pattern
+title: Double Dispatch
+folder: double-dispatch
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** Double Dispatch pattern is a way to create maintainable dynamic
+behavior based on receiver and parameter types.
+
+![alt text](./etc/double-dispatch.png "Double Dispatch")
+
+**Applicability:** Use the Double Dispatch pattern when
+
+* the dynamic behavior is not defined only based on receiving object's type but also on the receiving method's parameter type.
+
+**Real world examples:** 
+
+* [ObjectOutputStream](https://docs.oracle.com/javase/8/docs/api/java/io/ObjectOutputStream.html)

event-aggregator/index.md

@@ -0,0 +1,24 @@
+---
+layout: pattern
+title: Event Aggregator
+folder: event-aggregator
+categories: pattern_cat
+tags: pattern_tag
+---
+
+**Intent:** A system with lots of objects can lead to complexities when a
+client wants to subscribe to events. The client has to find and register for
+each object individually, if each object has multiple events then each event
+requires a separate subscription. An Event Aggregator acts as a single source
+of events for many objects. It registers for all the events of the many objects
+allowing clients to register with just the aggregator.
+
+![alt text](./etc/classes.png "Event Aggregator")
+
+**Applicability:** Use the Event Aggregator pattern when
+
+* Event Aggregator is a good choice when you have lots of objects that are
+  potential event sources. Rather than have the observer deal with registering
+  with them all, you can centralize the registration logic to the Event
+  Aggregator. As well as simplifying registration, a Event Aggregator also
+  simplifies the memory management issues in using observers.