* Control access to another object

* Lazy initialization

* When network hits are expensive and time consuming

* When we want some objects to perform a common action and don't want to define this action as a method in every class.

* You want to avoid explicit null checks and keep the algorithm elegant and easy to read.

* 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.

* When some arbitrary synchronous or asynchronous action must be performed after execution of some defined activity.

* You use an API that requires methods to be called in pairs such as open/close or allocate/deallocate.

* You need to select a subset of objects based on some criteria, and to refresh the selection at various times

* You need to check that only suitable objects are used for a certain role (validation)

* The communication schema can evolve and change and yet the receiving side should not break

* You want to focus on creating explicit and understandable update paths for your application's data, which makes tracing changes during development simpler and makes bugs easier to track down and fix.

* The dynamic behavior is not defined only based on receiving object's type but also on the receiving method's parameter type.

* You have a large number of short-lived tasks to be executed in parallel

* You have multiple independent tasks that can run in parallel

* You need to improve performance of running a group of sequential tasks

* You have limited number of processing capacity or long running tasks and the caller cannot wait the tasks to be ready

* You want to prevent write access to class data members

* The objects are expensive to create (allocation cost)

* You need a large number of short-lived objects (memory fragmentation)

* When you need to remove knowledge of concrete implementation from object

* To enable unit testing of classes in isolation using mock objects or stubs

* You are prototyping and need fast development cycle

* An autogenerated user interface is good enough

* You want to automatically publish the domain as REST services

* A system possesses following characteristics:

* System must perform tasks in response to external events that occur asynchronously, like hardware interrupts in OS

* It is inefficient to dedicate separate thread of control to perform synchronous I/O for each external source of event

* The higher level tasks in the system can be simplified significantly if I/O is performed synchronously.

* One or more tasks in a system must run in a single thread of control, while other tasks may benefit from multi-threading.

1. If there is no issue for the new pattern yet, raise new issue. Comment on the issue that you are working on it so that others don't start work on the same thing.

3. Implement the code changes in your fork. Remember to add sufficient comments documenting the implementation. Reference the issue id e.g. #52 in your commit messages.

4. Implement the code changes in your fork. Remember to add sufficient comments documenting the implementation. Reference the issue id e.g. #52 in your commit messages.