#354 Add maven model for feature toggle design pattern
This commit is contained in:
parent
cf10bd1d05
commit
d7526fc7c0
@ -10,24 +10,27 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Also known as:** Kit
|
||||
## Also known as
|
||||
Kit
|
||||
|
||||
**Intent:** Provide an interface for creating families of related or dependent
|
||||
## Intent
|
||||
Provide an interface for creating families of related or dependent
|
||||
objects without specifying their concrete classes.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Abstract Factory pattern when
|
||||
## 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:**
|
||||
## Real world examples
|
||||
|
||||
* [javax.xml.parsers.DocumentBuilderFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/parsers/DocumentBuilderFactory.html)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,24 +10,27 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Also known as:** Wrapper
|
||||
## Also known as
|
||||
Wrapper
|
||||
|
||||
**Intent:** Convert the interface of a class into another interface the clients
|
||||
## 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.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Adapter pattern when
|
||||
## 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:**
|
||||
## Real world examples
|
||||
|
||||
* [java.util.Arrays#asList()](http://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#asList%28T...%29)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,21 +10,23 @@ tags:
|
||||
- Functional
|
||||
---
|
||||
|
||||
**Intent:** Asynchronous method invocation is pattern where the calling thread
|
||||
## 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.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use async method invocation pattern when
|
||||
## 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:**
|
||||
## 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)
|
||||
|
@ -10,15 +10,17 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Also known as:** Handle/Body
|
||||
## Also known as
|
||||
Handle/Body
|
||||
|
||||
**Intent:** Decouple an abstraction from its implementation so that the two can
|
||||
## Intent
|
||||
Decouple an abstraction from its implementation so that the two can
|
||||
vary independently.
|
||||
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Bridge pattern when
|
||||
## 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
|
||||
@ -26,6 +28,6 @@ vary independently.
|
||||
* 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**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,22 +10,24 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Separate the construction of a complex object from its
|
||||
## Intent
|
||||
Separate the construction of a complex object from its
|
||||
representation so that the same construction process can create different
|
||||
representations.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Builder pattern when
|
||||
## 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:**
|
||||
## 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)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -9,14 +9,16 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** The Business Delegate pattern adds an abstraction layer between
|
||||
## 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.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Business Delegate pattern when
|
||||
## 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
|
||||
|
@ -10,17 +10,19 @@ tags:
|
||||
- Performance
|
||||
---
|
||||
|
||||
**Intent:** To avoid expensive re-acquisition of resources by not releasing
|
||||
## Intent
|
||||
To avoid expensive re-acquisition of resources by not releasing
|
||||
the resources immediately after their use. The resources retain their identity, are kept in some
|
||||
fast-access storage, and are re-used to avoid having to acquire them again.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Caching pattern(s) when
|
||||
## Applicability
|
||||
Use the Caching pattern(s) when
|
||||
|
||||
* Repetitious acquisition, initialization, and release of the same resource causes unnecessary performance overhead.
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Write-through, write-around, write-back: Cache explained](http://www.computerweekly.com/feature/Write-through-write-around-write-back-Cache-explained)
|
||||
* [Read-Through, Write-Through, Write-Behind, and Refresh-Ahead Caching](https://docs.oracle.com/cd/E15357_01/coh.360/e15723/cache_rtwtwbra.htm#COHDG5177)
|
||||
|
@ -11,16 +11,18 @@ tags:
|
||||
- Idiom
|
||||
---
|
||||
|
||||
**Intent:** Callback is a piece of executable code that is passed as an
|
||||
## 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.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Callback pattern when
|
||||
## 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:**
|
||||
## 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.
|
||||
|
@ -10,23 +10,25 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Avoid coupling the sender of a request to its receiver by giving
|
||||
## 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.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use Chain of Responsibility when
|
||||
## 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:**
|
||||
## 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)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,15 +10,18 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Also known as:** Action, Transaction
|
||||
## Also known as
|
||||
Action, Transaction
|
||||
|
||||
**Intent:** Encapsulate a request as an object, thereby letting you
|
||||
## Intent
|
||||
Encapsulate a request as an object, thereby letting you
|
||||
parameterize clients with different requests, queue or log requests, and
|
||||
support undoable operations.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Command pattern when you want to
|
||||
## 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
|
||||
@ -26,16 +29,16 @@ support undoable operations.
|
||||
* 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:**
|
||||
## Typical Use Case
|
||||
|
||||
* to keep a history of requests
|
||||
* implement callback functionality
|
||||
* implement the undo functionality
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [java.lang.Runnable](http://docs.oracle.com/javase/8/docs/api/java/lang/Runnable.html)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,22 +10,24 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Compose objects into tree structures to represent part-whole
|
||||
## Intent
|
||||
Compose objects into tree structures to represent part-whole
|
||||
hierarchies. Composite lets clients treat individual objects and compositions
|
||||
of objects uniformly.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Composite pattern when
|
||||
## 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:**
|
||||
## 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)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -9,16 +9,18 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** Object provides an abstract interface to some type of database or
|
||||
## Intent
|
||||
Object provides an abstract interface to some type of database or
|
||||
other persistence mechanism.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Data Access Object in any of the following situations
|
||||
## 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
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [J2EE Design Patterns](http://www.amazon.com/J2EE-Design-Patterns-William-Crawford/dp/0596004273/ref=sr_1_2)
|
||||
|
Binary file not shown.
Before Width: | Height: | Size: 7.9 KiB After Width: | Height: | Size: 29 KiB |
@ -1,18 +1,18 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<class-diagram version="1.1.8" icons="true" automaticImage="PNG" always-add-relationships="false" generalizations="true"
|
||||
realizations="true" associations="true" dependencies="false" nesting-relationships="true">
|
||||
<class-diagram version="1.1.9" icons="true" always-add-relationships="false" generalizations="true" realizations="true"
|
||||
associations="true" dependencies="false" nesting-relationships="true" router="FAN">
|
||||
<interface id="1" language="java" name="com.iluwatar.decorator.Hostile" project="decorator"
|
||||
file="/decorator/src/main/java/com/iluwatar/decorator/Hostile.java" binary="false" corner="BOTTOM_RIGHT">
|
||||
<position height="106" width="134" x="116" y="408"/>
|
||||
<position height="-1" width="-1" x="554" y="188"/>
|
||||
<display autosize="true" stereotype="true" package="true" initial-value="false" signature="true"
|
||||
sort-features="false" accessors="true" visibility="true">
|
||||
<attributes public="true" package="true" protected="true" private="true" static="true"/>
|
||||
<operations public="true" package="true" protected="true" private="true" static="true"/>
|
||||
</display>
|
||||
</interface>
|
||||
<class id="2" language="java" name="com.iluwatar.decorator.SmartTroll" project="decorator"
|
||||
file="/decorator/src/main/java/com/iluwatar/decorator/SmartTroll.java" binary="false" corner="BOTTOM_RIGHT">
|
||||
<position height="124" width="134" x="116" y="244"/>
|
||||
<class id="2" language="java" name="com.iluwatar.decorator.App" project="decorator"
|
||||
file="/decorator/src/main/java/com/iluwatar/decorator/App.java" binary="false" corner="BOTTOM_RIGHT">
|
||||
<position height="-1" width="-1" x="117" y="202"/>
|
||||
<display autosize="true" stereotype="true" package="true" initial-value="false" signature="true"
|
||||
sort-features="false" accessors="true" visibility="true">
|
||||
<attributes public="true" package="true" protected="true" private="true" static="true"/>
|
||||
@ -21,29 +21,46 @@
|
||||
</class>
|
||||
<class id="3" language="java" name="com.iluwatar.decorator.Troll" project="decorator"
|
||||
file="/decorator/src/main/java/com/iluwatar/decorator/Troll.java" binary="false" corner="BOTTOM_RIGHT">
|
||||
<position height="124" width="134" x="290" y="244"/>
|
||||
<position height="-1" width="-1" x="315" y="100"/>
|
||||
<display autosize="true" stereotype="true" package="true" initial-value="false" signature="true"
|
||||
sort-features="false" accessors="true" visibility="true">
|
||||
<attributes public="true" package="true" protected="true" private="true" static="true"/>
|
||||
<operations public="true" package="true" protected="true" private="true" static="true"/>
|
||||
</display>
|
||||
</class>
|
||||
<realization id="4">
|
||||
<class id="4" language="java" name="com.iluwatar.decorator.SmartHostile" project="decorator"
|
||||
file="/decorator/src/main/java/com/iluwatar/decorator/SmartHostile.java" binary="false" corner="BOTTOM_RIGHT">
|
||||
<position height="-1" width="-1" x="318" y="315"/>
|
||||
<display autosize="true" stereotype="true" package="true" initial-value="false" signature="true"
|
||||
sort-features="false" accessors="true" visibility="true">
|
||||
<attributes public="true" package="true" protected="true" private="true" static="true"/>
|
||||
<operations public="true" package="true" protected="true" private="true" static="true"/>
|
||||
</display>
|
||||
</class>
|
||||
<dependency id="5">
|
||||
<end type="SOURCE" refId="2"/>
|
||||
<end type="TARGET" refId="4"/>
|
||||
</dependency>
|
||||
<realization id="6">
|
||||
<end type="SOURCE" refId="3"/>
|
||||
<end type="TARGET" refId="1"/>
|
||||
</realization>
|
||||
<association id="5">
|
||||
<end type="SOURCE" refId="2" navigable="false">
|
||||
<attribute id="6" name="decorated"/>
|
||||
<multiplicity id="7" minimum="0" maximum="1"/>
|
||||
<association id="7">
|
||||
<end type="SOURCE" refId="4" navigable="false">
|
||||
<attribute id="8" name="decorated"/>
|
||||
<multiplicity id="9" minimum="0" maximum="1"/>
|
||||
</end>
|
||||
<end type="TARGET" refId="1" navigable="true"/>
|
||||
<display labels="true" multiplicity="true"/>
|
||||
</association>
|
||||
<realization id="8">
|
||||
<end type="SOURCE" refId="3"/>
|
||||
<realization id="10">
|
||||
<end type="SOURCE" refId="4"/>
|
||||
<end type="TARGET" refId="1"/>
|
||||
</realization>
|
||||
<dependency id="11">
|
||||
<end type="SOURCE" refId="2"/>
|
||||
<end type="TARGET" refId="3"/>
|
||||
</dependency>
|
||||
<classifier-display autosize="true" stereotype="true" package="true" initial-value="false" signature="true"
|
||||
sort-features="false" accessors="true" visibility="true">
|
||||
<attributes public="true" package="true" protected="true" private="true" static="true"/>
|
||||
|
Binary file not shown.
Before Width: | Height: | Size: 24 KiB |
@ -10,20 +10,23 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Also known as:** Wrapper
|
||||
## Also known as
|
||||
Wrapper
|
||||
|
||||
**Intent:** Attach additional responsibilities to an object dynamically.
|
||||
## Intent
|
||||
Attach additional responsibilities to an object dynamically.
|
||||
Decorators provide a flexible alternative to subclassing for extending
|
||||
functionality.
|
||||
|
||||

|
||||

|
||||
|
||||
**Applicability:** Use 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
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -8,7 +8,7 @@ package com.iluwatar.decorator;
|
||||
* runtime.
|
||||
* <p>
|
||||
* In this example we show how the simple {@link Troll} first attacks and then flees the battle.
|
||||
* Then we decorate the {@link Troll} with a {@link SmartTroll} and perform the attack again. You
|
||||
* Then we decorate the {@link Troll} with a {@link SmartHostile} and perform the attack again. You
|
||||
* can see how the behavior changes after the decoration.
|
||||
*
|
||||
*/
|
||||
@ -30,7 +30,7 @@ public class App {
|
||||
|
||||
// change the behavior of the simple troll by adding a decorator
|
||||
System.out.println("\nA smart looking troll surprises you.");
|
||||
Hostile smart = new SmartTroll(troll);
|
||||
Hostile smart = new SmartHostile(troll);
|
||||
smart.attack();
|
||||
smart.fleeBattle();
|
||||
System.out.printf("Smart troll power %d.\n", smart.getAttackPower());
|
||||
|
@ -1,34 +1,34 @@
|
||||
package com.iluwatar.decorator;
|
||||
|
||||
/**
|
||||
* SmartTroll is a decorator for {@link Hostile} objects. The calls to the {@link Hostile} interface
|
||||
* SmartHostile is a decorator for {@link Hostile} objects. The calls to the {@link Hostile} interface
|
||||
* are intercepted and decorated. Finally the calls are delegated to the decorated {@link Hostile}
|
||||
* object.
|
||||
*
|
||||
*/
|
||||
public class SmartTroll implements Hostile {
|
||||
public class SmartHostile implements Hostile {
|
||||
|
||||
private Hostile decorated;
|
||||
|
||||
public SmartTroll(Hostile decorated) {
|
||||
public SmartHostile(Hostile decorated) {
|
||||
this.decorated = decorated;
|
||||
}
|
||||
|
||||
@Override
|
||||
public void attack() {
|
||||
System.out.println("The troll throws a rock at you!");
|
||||
System.out.println("It throws a rock at you!");
|
||||
decorated.attack();
|
||||
}
|
||||
|
||||
@Override
|
||||
public int getAttackPower() {
|
||||
// decorated troll power + 20 because it is smart
|
||||
// decorated hostile's power + 20 because it is smart
|
||||
return decorated.getAttackPower() + 20;
|
||||
}
|
||||
|
||||
@Override
|
||||
public void fleeBattle() {
|
||||
System.out.println("The troll calls for help!");
|
||||
System.out.println("It calls for help!");
|
||||
decorated.fleeBattle();
|
||||
}
|
||||
}
|
@ -11,15 +11,15 @@ import static org.mockito.internal.verification.VerificationModeFactory.times;
|
||||
*
|
||||
* @author Jeroen Meulemeester
|
||||
*/
|
||||
public class SmartTrollTest {
|
||||
public class SmartHostileTest {
|
||||
|
||||
@Test
|
||||
public void testSmartTroll() throws Exception {
|
||||
public void testSmartHostile() throws Exception {
|
||||
// Create a normal troll first, but make sure we can spy on it later on.
|
||||
final Hostile simpleTroll = spy(new Troll());
|
||||
|
||||
// Now we want to decorate the troll to make it smarter ...
|
||||
final Hostile smartTroll = new SmartTroll(simpleTroll);
|
||||
final Hostile smartTroll = new SmartHostile(simpleTroll);
|
||||
assertEquals(30, smartTroll.getAttackPower());
|
||||
verify(simpleTroll, times(1)).getAttackPower();
|
||||
|
@ -9,19 +9,22 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Also known as:** Proxy Pattern
|
||||
## Also known as
|
||||
Proxy Pattern
|
||||
|
||||
**Intent:** It is a technique where an object expresses certain behavior to the outside but in
|
||||
## Intent
|
||||
It is a technique where an object expresses certain behavior to the outside but in
|
||||
reality delegates responsibility for implementing that behaviour to an associated object.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Delegate pattern in order to achieve the following
|
||||
## Applicability
|
||||
Use the Delegate pattern in order to achieve the following
|
||||
|
||||
* Reduce the coupling of methods to their class
|
||||
* Components that behave identically, but realize that this situation can change in the future.
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Delegate Pattern: Wikipedia ](https://en.wikipedia.org/wiki/Delegation_pattern)
|
||||
* [Proxy Pattern: Wikipedia ](https://en.wikipedia.org/wiki/Proxy_pattern)
|
||||
* [Proxy Pattern: Wikipedia ](https://en.wikipedia.org/wiki/Proxy_pattern)
|
||||
|
@ -9,7 +9,8 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** Dependency Injection is a software design pattern in which one or
|
||||
## 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
|
||||
@ -18,7 +19,8 @@ inversion of control and single responsibility principles.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Dependency Injection pattern when
|
||||
## 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
|
||||
|
@ -10,14 +10,16 @@ tags:
|
||||
- Idiom
|
||||
---
|
||||
|
||||
**Intent:** Reduce the overhead of acquiring a lock by first testing the
|
||||
## 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.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Double Checked Locking pattern when
|
||||
## 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.
|
||||
|
@ -10,15 +10,17 @@ tags:
|
||||
- Idiom
|
||||
---
|
||||
|
||||
**Intent:** Double Dispatch pattern is a way to create maintainable dynamic
|
||||
## Intent
|
||||
Double Dispatch pattern is a way to create maintainable dynamic
|
||||
behavior based on receiver and parameter types.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Double Dispatch pattern when
|
||||
## 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:**
|
||||
## Real world examples
|
||||
|
||||
* [ObjectOutputStream](https://docs.oracle.com/javase/8/docs/api/java/io/ObjectOutputStream.html)
|
||||
|
@ -9,7 +9,8 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** A system with lots of objects can lead to complexities when a
|
||||
## 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
|
||||
@ -18,7 +19,8 @@ allowing clients to register with just the aggregator.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Event Aggregator pattern when
|
||||
## 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
|
||||
@ -26,6 +28,6 @@ allowing clients to register with just the aggregator.
|
||||
Aggregator. As well as simplifying registration, a Event Aggregator also
|
||||
simplifies the memory management issues in using observers.
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Martin Fowler - Event Aggregator](http://martinfowler.com/eaaDev/EventAggregator.html)
|
||||
|
@ -3,25 +3,26 @@ title: Event Driven Architecture
|
||||
folder: event-driven-architecture
|
||||
permalink: /patterns/event-driven-architecture
|
||||
|
||||
|
||||
**Intent:** Send and notify state changes of your objects to other applications using an Event-driven Architecture.
|
||||
## Intent
|
||||
Send and notify state changes of your objects to other applications using an Event-driven Architecture.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use an Event-driven architecture when
|
||||
## Applicability
|
||||
Use an Event-driven architecture when
|
||||
|
||||
* you want to create a loosely coupled system
|
||||
* you want to build a more responsive system
|
||||
* you want a system that is easier to extend
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* SendGrid, an email API, sends events whenever an email is processed, delivered, opened etc... (https://sendgrid.com/docs/API_Reference/Webhooks/event.html)
|
||||
* Chargify, a billing API, exposes payment activity through various events (https://docs.chargify.com/api-events)
|
||||
* Amazon's AWS Lambda, lets you execute code in response to events such as changes to Amazon S3 buckets, updates to an Amazon DynamoDB table, or custom events generated by your applications or devices. (https://aws.amazon.com/lambda)
|
||||
* MySQL runs triggers based on events such as inserts and update events happening on database tables.
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Event-driven architecture - Wikipedia](http://www.computerweekly.com/feature/Write-through-write-around-write-back-Cache-explained)
|
||||
* [Fundamental Components of an Event-Driven Architecture](http://giocc.com/fundamental-components-of-an-event-driven-architecture.html)
|
||||
|
@ -10,13 +10,15 @@ tags:
|
||||
- Idiom
|
||||
---
|
||||
|
||||
**Intent:** Execute Around idiom frees the user from certain actions that
|
||||
## Intent
|
||||
Execute Around idiom frees the user from certain actions that
|
||||
should always be executed before and after the business method. A good example
|
||||
of this is resource allocation and deallocation leaving the user to specify
|
||||
only what to do with the resource.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Execute Around idiom when
|
||||
## Applicability
|
||||
Use the Execute Around idiom when
|
||||
|
||||
* you use an API that requires methods to be called in pairs such as open/close or allocate/deallocate.
|
||||
|
@ -10,17 +10,19 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** Provide a unified interface to a set of interfaces in a subsystem.
|
||||
## Intent
|
||||
Provide a unified interface to a set of interfaces in a subsystem.
|
||||
Facade defines a higher-level interface that makes the subsystem easier to use.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Facade pattern when
|
||||
## Applicability
|
||||
Use the Facade pattern when
|
||||
|
||||
* you want to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, result in more and smaller classes. This makes the subsystem more reusable and easier to customize, but it also becomes harder to use for clients that don't need to customize it. A facade can provide a simple default view of the subsystem that is good enough for most clients. Only clients needing more customizability will need to look beyond the facade.
|
||||
* there are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability.
|
||||
* you want to layer your subsystems. Use a facade to define an entry point to each subsystem level. If subsystems are dependent, the you can simplify the dependencies between them by making them communicate with each other solely through their facades
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,20 +10,23 @@ tags:
|
||||
- Gang Of Four
|
||||
---
|
||||
|
||||
**Also known as:** Virtual Constructor
|
||||
## Also known as
|
||||
Virtual Constructor
|
||||
|
||||
**Intent:** Define an interface for creating an object, but let subclasses
|
||||
## Intent
|
||||
Define an interface for creating an object, but let subclasses
|
||||
decide which class to instantiate. Factory Method lets a class defer
|
||||
instantiation to subclasses.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Factory Method pattern when
|
||||
## Applicability
|
||||
Use the Factory Method pattern when
|
||||
|
||||
* a class can't anticipate the class of objects it must create
|
||||
* a class wants its subclasses to specify the objects it creates
|
||||
* classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,9 +10,10 @@ tags:
|
||||
- Functional
|
||||
---
|
||||
|
||||
**Intent:** A fluent interface provides an easy-readable, flowing interface, that often mimics a domain specific language. Using this pattern results in code that can be read nearly as human language.
|
||||
## Intent
|
||||
A fluent interface provides an easy-readable, flowing interface, that often mimics a domain specific language. Using this pattern results in code that can be read nearly as human language.
|
||||
|
||||
**Implementation:**
|
||||
## Implementation
|
||||
|
||||
A fluent interface can be implemented using any of
|
||||
|
||||
@ -22,13 +23,13 @@ A fluent interface can be implemented using any of
|
||||
|
||||

|
||||
|
||||
|
||||
**Applicability:** Use the Fluent Interface pattern when
|
||||
## Applicability
|
||||
Use the Fluent Interface pattern when
|
||||
|
||||
* you provide an API that would benefit from a DSL-like usage
|
||||
* you have objects that are difficult to configure or use
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [Java 8 Stream API](http://www.oracle.com/technetwork/articles/java/ma14-java-se-8-streams-2177646.html)
|
||||
* [Google Guava FluentInterable](https://github.com/google/guava/wiki/FunctionalExplained)
|
||||
@ -36,7 +37,7 @@ A fluent interface can be implemented using any of
|
||||
* [Mockito](http://mockito.org/)
|
||||
* [Java Hamcrest](http://code.google.com/p/hamcrest/wiki/Tutorial)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Fluent Interface - Martin Fowler](http://www.martinfowler.com/bliki/FluentInterface.html)
|
||||
* [Evolutionary architecture and emergent design: Fluent interfaces - Neal Ford](http://www.ibm.com/developerworks/library/j-eaed14/)
|
||||
|
@ -9,17 +9,19 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Flux eschews MVC in favor of a unidirectional data flow. When a
|
||||
## Intent
|
||||
Flux eschews MVC in favor of a unidirectional data flow. When a
|
||||
user interacts with a view, the view propagates an action through a central
|
||||
dispatcher, to the various stores that hold the application's data and business
|
||||
logic, which updates all of the views that are affected.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Flux pattern when
|
||||
## Applicability
|
||||
Use the Flux pattern when
|
||||
|
||||
* 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.
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Flux - Application architecture for building user interfaces](http://facebook.github.io/flux/)
|
||||
|
@ -11,12 +11,14 @@ tags:
|
||||
- Performance
|
||||
---
|
||||
|
||||
**Intent:** Use sharing to support large numbers of fine-grained objects
|
||||
## Intent
|
||||
Use sharing to support large numbers of fine-grained objects
|
||||
efficiently.
|
||||
|
||||

|
||||
|
||||
**Applicability:** The Flyweight pattern's effectiveness depends heavily on how
|
||||
## Applicability
|
||||
The Flyweight pattern's effectiveness depends heavily on how
|
||||
and where it's used. Apply the Flyweight pattern when all of the following are
|
||||
true
|
||||
|
||||
@ -26,10 +28,10 @@ true
|
||||
* many groups of objects may be replaced by relatively few shared objects once extrinsic state is removed
|
||||
* the application doesn't depend on object identity. Since flyweight objects may be shared, identity tests will return true for conceptually distinct objects.
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [java.lang.Integer#valueOf(int)](http://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#valueOf%28int%29)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -9,23 +9,25 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Introduce a common handler for all requests for a web site. This
|
||||
## Intent
|
||||
Introduce a common handler for all requests for a web site. This
|
||||
way we can encapsulate common functionality such as security,
|
||||
internationalization, routing and logging in a single place.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Front Controller pattern when
|
||||
## Applicability
|
||||
Use the Front Controller pattern when
|
||||
|
||||
* you want to encapsulate common request handling functionality in single place
|
||||
* you want to implements dynamic request handling i.e. change routing without modifying code
|
||||
* make web server configuration portable, you only need to register the handler web server specific way
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [Apache Struts](https://struts.apache.org/)
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [J2EE Design Patterns](http://www.amazon.com/J2EE-Design-Patterns-William-Crawford/dp/0596004273/ref=sr_1_2)
|
||||
* [Presentation Tier Patterns](http://www.javagyan.com/tutorials/corej2eepatterns/presentation-tier-patterns)
|
||||
|
@ -9,13 +9,15 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** The Half-Sync/Half-Async pattern decouples synchronous I/O from
|
||||
## Intent
|
||||
The Half-Sync/Half-Async pattern decouples synchronous I/O from
|
||||
asynchronous I/O in a system to simplify concurrent programming effort without
|
||||
degrading execution efficiency.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use Half-Sync/Half-Async pattern when
|
||||
## Applicability
|
||||
Use Half-Sync/Half-Async pattern when
|
||||
|
||||
* a system possesses following characteristics:
|
||||
* the system must perform tasks in response to external events that occur asynchronously, like hardware interrupts in OS
|
||||
@ -23,13 +25,13 @@ degrading execution efficiency.
|
||||
* 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.
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [BSD Unix networking subsystem](http://www.cs.wustl.edu/~schmidt/PDF/PLoP-95.pdf)
|
||||
* [Real Time CORBA](http://www.omg.org/news/meetings/workshops/presentations/realtime2001/4-3_Pyarali_thread-pool.pdf)
|
||||
* [Android AsyncTask framework](http://developer.android.com/reference/android/os/AsyncTask.html)
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Douglas C. Schmidt and Charles D. Cranor - Half Sync/Half Async](http://www.cs.wustl.edu/~schmidt/PDF/PLoP-95.pdf)
|
||||
* [Pattern Oriented Software Architecture Vol I-V](http://www.amazon.com/Pattern-Oriented-Software-Architecture-Volume-Patterns/dp/0471958697)
|
||||
|
@ -9,22 +9,24 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Provide pluggable filters to conduct necessary pre-processing and
|
||||
## Intent
|
||||
Provide pluggable filters to conduct necessary pre-processing and
|
||||
post-processing to requests from a client to a target
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Intercepting Filter pattern when
|
||||
## Applicability
|
||||
Use the Intercepting Filter pattern when
|
||||
|
||||
* a system uses pre-processing or post-processing requests
|
||||
* a system should do the authentication/ authorization/ logging or tracking of request and then pass the requests to corresponding handlers
|
||||
* you want a modular approach to configuring pre-processing and post-processing schemes
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [Struts 2 - Interceptors](https://struts.apache.org/docs/interceptors.html)
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [TutorialsPoint - Intercepting Filter](http://www.tutorialspoint.com/design_pattern/intercepting_filter_pattern.htm)
|
||||
* [Presentation Tier Patterns](http://www.javagyan.com/tutorials/corej2eepatterns/presentation-tier-patterns)
|
||||
|
@ -10,19 +10,21 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Given a language, define a representation for its grammar along
|
||||
## Intent
|
||||
Given a language, define a representation for its grammar along
|
||||
with an interpreter that uses the representation to interpret sentences in the
|
||||
language.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Interpreter pattern when there is a language to
|
||||
## Applicability
|
||||
Use the Interpreter pattern when there is a language to
|
||||
interpret, and you can represent statements in the language as abstract syntax
|
||||
trees. The Interpreter pattern works best when
|
||||
|
||||
* the grammar is simple. For complex grammars, the class hierarchy for the grammar becomes large and unmanageable. Tools such as parser generators are a better alternative in such cases. They can interpret expressions without building abstract syntax trees, which can save space and possibly time
|
||||
* efficiency is not a critical concern. The most efficient interpreters are usually not implemented by interpreting parse trees directly but by first translating them into another form. For example, regular expressions are often transformed into state machines. But even then, the translator can be implemented by the Interpreter pattern, so the pattern is still applicable
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,23 +10,26 @@ tags:
|
||||
- Gang Of Four
|
||||
---
|
||||
|
||||
**Also known as:** Cursor
|
||||
## Also known as
|
||||
Cursor
|
||||
|
||||
**Intent:** Provide a way to access the elements of an aggregate object
|
||||
## Intent
|
||||
Provide a way to access the elements of an aggregate object
|
||||
sequentially without exposing its underlying representation.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Iterator pattern
|
||||
## Applicability
|
||||
Use the Iterator pattern
|
||||
|
||||
* to access an aggregate object's contents without exposing its internal representation
|
||||
* to support multiple traversals of aggregate objects
|
||||
* to provide a uniform interface for traversing different aggregate structures
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [java.util.Iterator](http://docs.oracle.com/javase/8/docs/api/java/util/Iterator.html)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,18 +10,19 @@ tags:
|
||||
- Spring
|
||||
---
|
||||
|
||||
**Intent:** Layers is an architectural style where software responsibilities are
|
||||
## Intent
|
||||
Layers is an architectural style where software responsibilities are
|
||||
divided among the different layers of the application.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Layers architecture when
|
||||
## Applicability
|
||||
Use the Layers architecture when
|
||||
|
||||
* you want clearly divide software responsibilities into differents parts of the program
|
||||
* you want to prevent a change from propagating throughout the application
|
||||
* you want to make your application more maintainable and testable
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Pattern Oriented Software Architecture Vol I-V](http://www.amazon.com/Pattern-Oriented-Software-Architecture-Volume-Patterns/dp/0471958697)
|
||||
|
||||
|
@ -11,17 +11,19 @@ tags:
|
||||
- Performance
|
||||
---
|
||||
|
||||
**Intent:** Lazy loading is a design pattern commonly used to defer
|
||||
## Intent
|
||||
Lazy loading is a design pattern commonly used to defer
|
||||
initialization of an object until the point at which it is needed. It can
|
||||
contribute to efficiency in the program's operation if properly and
|
||||
appropriately used.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Lazy Loading idiom when
|
||||
## Applicability
|
||||
Use the Lazy Loading idiom when
|
||||
|
||||
* eager loading is expensive or the object to be loaded might not be needed at all
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* JPA annotations @OneToOne, @OneToMany, @ManyToOne, @ManyToMany and fetch = FetchType.LAZY
|
||||
|
@ -10,18 +10,20 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Define an object that encapsulates how a set of objects interact.
|
||||
## Intent
|
||||
Define an object that encapsulates how a set of objects interact.
|
||||
Mediator promotes loose coupling by keeping objects from referring to each
|
||||
other explicitly, and it lets you vary their interaction independently.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Mediator pattern when
|
||||
## Applicability
|
||||
Use the Mediator pattern when
|
||||
|
||||
* a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand
|
||||
* reusing an object is difficult because it refers to and communicates with many other objects
|
||||
* a behavior that's distributed between several classes should be customizable without a lot of subclassing
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,22 +10,25 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Also known as:** Token
|
||||
## Also known as
|
||||
Token
|
||||
|
||||
**Intent:** Without violating encapsulation, capture and externalize an
|
||||
## Intent
|
||||
Without violating encapsulation, capture and externalize an
|
||||
object's internal state so that the object can be restored to this state later.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Memento pattern when
|
||||
## Applicability
|
||||
Use the Memento pattern when
|
||||
|
||||
* a snapshot of an object's state must be saved so that it can be restored to that state later, and
|
||||
* a direct interface to obtaining the state would expose implementation details and break the object's encapsulation
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [java.util.Date](http://docs.oracle.com/javase/8/docs/api/java/util/Date.html)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -7,18 +7,20 @@ categories: Integration
|
||||
tags:
|
||||
- Java
|
||||
- EIP
|
||||
- Camel
|
||||
- Apache Camel™
|
||||
---
|
||||
|
||||
**Intent:** When two applications communicate using a messaging system they do it by using logical addresses
|
||||
## Intent
|
||||
When two applications communicate using a messaging system they do it by using logical addresses
|
||||
of the system, so called Message Channels.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Message Channel pattern when
|
||||
## Applicability
|
||||
Use the Message Channel pattern when
|
||||
|
||||
* two or more applications need to communicate using a messaging system
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [akka-camel](http://doc.akka.io/docs/akka/snapshot/scala/camel.html)
|
||||
* [akka-camel](http://doc.akka.io/docs/akka/snapshot/scala/camel.html)
|
@ -9,18 +9,20 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Separate the user interface into three interconnected components:
|
||||
## Intent
|
||||
Separate the user interface into three interconnected components:
|
||||
the model, the view and the controller. Let the model manage the data, the view
|
||||
display the data and the controller mediate updating the data and redrawing the
|
||||
display.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Model-View-Controller pattern when
|
||||
## Applicability
|
||||
Use the Model-View-Controller pattern when
|
||||
|
||||
* you want to clearly separate the domain data from its user interface representation
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Trygve Reenskaug - Model-view-controller](http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller)
|
||||
* [J2EE Design Patterns](http://www.amazon.com/J2EE-Design-Patterns-William-Crawford/dp/0596004273/ref=sr_1_2)
|
||||
|
@ -9,17 +9,19 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Apply a "Separation of Concerns" principle in a way that allows
|
||||
## Intent
|
||||
Apply a "Separation of Concerns" principle in a way that allows
|
||||
developers to build and test user interfaces.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Model-View-Presenter in any of the following
|
||||
## Applicability
|
||||
Use the Model-View-Presenter in any of the following
|
||||
situations
|
||||
|
||||
* when you want to improve the "Separation of Concerns" principle in presentation logic
|
||||
* when a user interface development and testing is necessary.
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [MVP4J](https://github.com/amineoualialami/mvp4j)
|
||||
|
@ -9,22 +9,24 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** Enforces a behaviour like sharing the same state amongst all instances.
|
||||
## Intent
|
||||
Enforces a behaviour like sharing the same state amongst all instances.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Monostate pattern when
|
||||
## Applicability
|
||||
Use the Monostate pattern when
|
||||
|
||||
* The same state must be shared across all instances of a class.
|
||||
* Typically this pattern might be used everywhere a Singleton might be used. Singleton usage however is not transparent, Monostate usage is.
|
||||
* Monostate has one major advantage over singleton. The subclasses might decorate the shared state as they wish and hence can provide dynamically different behaviour than the base class.
|
||||
|
||||
**Typical Use Case:**
|
||||
## Typical Use Case
|
||||
|
||||
* the logging class
|
||||
* managing a connection to a database
|
||||
* file manager
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
Yet to see this.
|
||||
|
@ -9,11 +9,13 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** Ensure a class only has limited number of instances, and provide a
|
||||
## Intent
|
||||
Ensure a class only has limited number of instances, and provide a
|
||||
global point of access to them.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Multiton pattern when
|
||||
## Applicability
|
||||
Use the Multiton pattern when
|
||||
|
||||
* there must be specific number of instances of a class, and they must be accessible to clients from a well-known access point
|
||||
|
@ -9,22 +9,24 @@ tags:
|
||||
- Difficulty-Expert
|
||||
---
|
||||
|
||||
**Intent:** The Naked Objects architectural pattern is well suited for rapid
|
||||
## Intent
|
||||
The Naked Objects architectural pattern is well suited for rapid
|
||||
prototyping. Using the pattern, you only need to write the domain objects,
|
||||
everything else is autogenerated by the framework.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Naked Objects pattern when
|
||||
## Applicability
|
||||
Use the Naked Objects pattern when
|
||||
|
||||
* 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
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [Apache Isis](https://isis.apache.org/)
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Richard Pawson - Naked Objects](http://downloads.nakedobjects.net/resources/Pawson%20thesis.pdf)
|
||||
|
@ -9,7 +9,8 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** In most object-oriented languages, such as Java or C#, references
|
||||
## Intent
|
||||
In most object-oriented languages, such as Java or C#, references
|
||||
may be null. These references need to be checked to ensure they are not null
|
||||
before invoking any methods, because methods typically cannot be invoked on
|
||||
null references. Instead of using a null reference to convey absence of an
|
||||
@ -20,6 +21,7 @@ Object is very predictable and has no side effects: it does nothing.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Null Object pattern when
|
||||
## Applicability
|
||||
Use the Null Object pattern when
|
||||
|
||||
* you want to avoid explicit null checks and keep the algorithm elegant and easy to read.
|
||||
|
@ -10,14 +10,16 @@ tags:
|
||||
- Performance
|
||||
---
|
||||
|
||||
**Intent:** When objects are expensive to create and they are needed only for
|
||||
## Intent
|
||||
When objects are expensive to create and they are needed only for
|
||||
short periods of time it is advantageous to utilize the Object Pool pattern.
|
||||
The Object Pool provides a cache for instantiated objects tracking which ones
|
||||
are in use and which are available.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Object Pool pattern when
|
||||
## Applicability
|
||||
Use the Object Pool pattern when
|
||||
|
||||
* the objects are expensive to create (allocation cost)
|
||||
* you need a large number of short-lived objects (memory fragmentation)
|
||||
|
@ -10,28 +10,31 @@ tags:
|
||||
- Gang Of Four
|
||||
---
|
||||
|
||||
**Also known as:** Dependents, Publish-Subscribe
|
||||
## Also known as
|
||||
Dependents, Publish-Subscribe
|
||||
|
||||
**Intent:** Define a one-to-many dependency between objects so that when one
|
||||
## Intent
|
||||
Define a one-to-many dependency between objects so that when one
|
||||
object changes state, all its dependents are notified and updated
|
||||
automatically.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Observer pattern in any of the following situations
|
||||
## Applicability
|
||||
Use the Observer pattern in any of the following situations
|
||||
|
||||
* when an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently
|
||||
* when a change to one object requires changing others, and you don't know how many objects need to be changed
|
||||
* when an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don't want these objects tightly coupled
|
||||
|
||||
**Typical Use Case:**
|
||||
## Typical Use Case
|
||||
|
||||
* changing in one object leads to a change in other objects
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [java.util.Observer](http://docs.oracle.com/javase/8/docs/api/java/util/Observer.html)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -9,15 +9,17 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Poison Pill is known predefined data item that allows to provide
|
||||
## Intent
|
||||
Poison Pill is known predefined data item that allows to provide
|
||||
graceful shutdown for separate distributed consumption process.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Poison Pill idiom when
|
||||
## Applicability
|
||||
Use the Poison Pill idiom when
|
||||
|
||||
* need to send signal from one thread/process to another to terminate
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [akka.actor.PoisonPill](http://doc.akka.io/docs/akka/2.1.4/java/untyped-actors.html)
|
||||
|
16
pom.xml
16
pom.xml
@ -11,18 +11,19 @@
|
||||
<properties>
|
||||
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
|
||||
<hibernate.version>5.0.1.Final</hibernate.version>
|
||||
<spring.version>4.1.7.RELEASE</spring.version>
|
||||
<spring-data.version>1.9.0.RELEASE</spring-data.version>
|
||||
<h2.version>1.4.188</h2.version>
|
||||
<spring.version>4.2.4.RELEASE</spring.version>
|
||||
<spring-data.version>1.9.2.RELEASE</spring-data.version>
|
||||
<h2.version>1.4.190</h2.version>
|
||||
<junit.version>4.12</junit.version>
|
||||
<compiler.version>3.0</compiler.version>
|
||||
<coveralls.version>4.0.0</coveralls.version>
|
||||
<jacoco.version>0.7.2.201409121644</jacoco.version>
|
||||
<commons-dbcp.version>1.4</commons-dbcp.version>
|
||||
<camel.version>2.15.3</camel.version>
|
||||
<camel.version>2.16.1</camel.version>
|
||||
<log4j.version>1.2.17</log4j.version>
|
||||
<guava.version>18.0</guava.version>
|
||||
<systemrules.version>1.14.0</systemrules.version>
|
||||
<guava.version>19.0</guava.version>
|
||||
<systemrules.version>1.15.1</systemrules.version>
|
||||
<mockito.version>1.10.19</mockito.version>
|
||||
</properties>
|
||||
<modules>
|
||||
<module>abstract-factory</module>
|
||||
@ -61,6 +62,7 @@
|
||||
<module>intercepting-filter</module>
|
||||
<module>producer-consumer</module>
|
||||
<module>poison-pill</module>
|
||||
<module>reader-writer-lock</module>
|
||||
<module>lazy-loading</module>
|
||||
<module>service-layer</module>
|
||||
<module>specification</module>
|
||||
@ -145,7 +147,7 @@
|
||||
<dependency>
|
||||
<groupId>org.mockito</groupId>
|
||||
<artifactId>mockito-core</artifactId>
|
||||
<version>1.10.19</version>
|
||||
<version>${mockito.version}</version>
|
||||
<scope>test</scope>
|
||||
</dependency>
|
||||
<dependency>
|
||||
|
@ -10,12 +10,14 @@ tags:
|
||||
- Idiom
|
||||
---
|
||||
|
||||
**Intent:** Private Class Data design pattern seeks to reduce exposure of
|
||||
## Intent
|
||||
Private Class Data design pattern seeks to reduce exposure of
|
||||
attributes by limiting their visibility. It reduces the number of class
|
||||
attributes by encapsulating them in single Data object.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Private Class Data pattern when
|
||||
## Applicability
|
||||
Use the Private Class Data pattern when
|
||||
|
||||
* you want to prevent write access to class data members
|
||||
|
@ -10,13 +10,15 @@ tags:
|
||||
- I/O
|
||||
---
|
||||
|
||||
**Intent:** Producer Consumer Design pattern is a classic concurrency pattern which reduces
|
||||
## Intent
|
||||
Producer Consumer Design pattern is a classic concurrency pattern which reduces
|
||||
coupling between Producer and Consumer by separating Identification of work with Execution of
|
||||
Work.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Producer Consumer idiom when
|
||||
## Applicability
|
||||
Use the Producer Consumer idiom when
|
||||
|
||||
* decouple system by separate work in two process produce and consume.
|
||||
* addresses the issue of different timing require to produce work or consuming work
|
||||
|
@ -9,15 +9,17 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** Create hierarchy of objects and new objects using already existing
|
||||
## Intent
|
||||
Create hierarchy of objects and new objects using already existing
|
||||
objects as parents.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Property pattern when
|
||||
## Applicability
|
||||
Use the Property pattern when
|
||||
|
||||
* when you like to have objects with dynamic set of fields and prototype inheritance
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain) prototype inheritance
|
||||
|
@ -10,21 +10,23 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** Specify the kinds of objects to create using a prototypical
|
||||
## Intent
|
||||
Specify the kinds of objects to create using a prototypical
|
||||
instance, and create new objects by copying this prototype.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Prototype pattern when a system should be independent of how its products are created, composed and represented; and
|
||||
## Applicability
|
||||
Use the Prototype pattern when a system should be independent of how its products are created, composed and represented; and
|
||||
|
||||
* when the classes to instantiate are specified at run-time, for example, by dynamic loading; or
|
||||
* to avoid building a class hierarchy of factories that parallels the class hierarchy of products; or
|
||||
* when instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [java.lang.Object#clone()](http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#clone%28%29)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,14 +10,17 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Also known as:** Surrogate
|
||||
## Also known as
|
||||
Surrogate
|
||||
|
||||
**Intent:** Provide a surrogate or placeholder for another object to control
|
||||
## Intent
|
||||
Provide a surrogate or placeholder for another object to control
|
||||
access to it.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Proxy is applicable whenever there is a need for a more
|
||||
## Applicability
|
||||
Proxy is applicable whenever there is a need for a more
|
||||
versatile or sophisticated reference to an object than a simple pointer. Here
|
||||
are several common situations in which the Proxy pattern is applicable
|
||||
|
||||
@ -25,7 +28,7 @@ are several common situations in which the Proxy pattern is applicable
|
||||
* a virtual proxy creates expensive objects on demand.
|
||||
* a protection proxy controls access to the original object. Protection proxies are useful when objects should have different access rights.
|
||||
|
||||
**Typical Use Case:**
|
||||
## Typical Use Case
|
||||
|
||||
* control access to another object
|
||||
* lazy initialization
|
||||
@ -33,11 +36,11 @@ are several common situations in which the Proxy pattern is applicable
|
||||
* facilitate network connection
|
||||
* to count references to an object
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [java.lang.reflect.Proxy](http://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Proxy.html)
|
||||
* [Apache Commons Proxy](https://commons.apache.org/proper/commons-proxy/)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -7,13 +7,15 @@ categories: Integration
|
||||
tags:
|
||||
- Java
|
||||
- EIP
|
||||
- Camel
|
||||
- Apache Camel™
|
||||
---
|
||||
|
||||
**Intent:** Broadcast messages from sender to all the interested receivers.
|
||||
## Intent
|
||||
Broadcast messages from sender to all the interested receivers.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Publish Subscribe Channel pattern when
|
||||
## Applicability
|
||||
Use the Publish Subscribe Channel pattern when
|
||||
|
||||
* two or more applications need to communicate using a messaging system for broadcasts.
|
||||
* two or more applications need to communicate using a messaging system for broadcasts.
|
@ -10,21 +10,23 @@ tags:
|
||||
- I/O
|
||||
---
|
||||
|
||||
**Intent:** The Reactor design pattern handles service requests that are delivered concurrently to an application by one or more clients. The application can register specific handlers for processing which are called by reactor on specific events. Dispatching of event handlers is performed by an initiation dispatcher, which manages the registered event handlers. Demultiplexing of service requests is performed by a synchronous event demultiplexer.
|
||||
## Intent
|
||||
The Reactor design pattern handles service requests that are delivered concurrently to an application by one or more clients. The application can register specific handlers for processing which are called by reactor on specific events. Dispatching of event handlers is performed by an initiation dispatcher, which manages the registered event handlers. Demultiplexing of service requests is performed by a synchronous event demultiplexer.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use Reactor pattern when
|
||||
## Applicability
|
||||
Use Reactor pattern when
|
||||
|
||||
* a server application needs to handle concurrent service requests from multiple clients.
|
||||
* a server application needs to be available for receiving requests from new clients even when handling older client requests.
|
||||
* a server must maximize throughput, minimize latency and use CPU efficiently without blocking.
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [Spring Reactor](http://projectreactor.io/)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Douglas C. Schmidt - Reactor](https://www.dre.vanderbilt.edu/~schmidt/PDF/Reactor.pdf)
|
||||
* [Pattern Oriented Software Architecture Vol I-V](http://www.amazon.com/Pattern-Oriented-Software-Architecture-Volume-Patterns/dp/0471958697)
|
||||
|
BIN
reader-writer-lock/etc/reader-writer-lock.png
Normal file
BIN
reader-writer-lock/etc/reader-writer-lock.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 39 KiB |
86
reader-writer-lock/etc/reader-writer-lock.ucls
Normal file
86
reader-writer-lock/etc/reader-writer-lock.ucls
Normal file
@ -0,0 +1,86 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<class-diagram version="1.1.8" icons="true" automaticImage="PNG" always-add-relationships="false" generalizations="true"
|
||||
realizations="true" associations="true" dependencies="false" nesting-relationships="true">
|
||||
<class id="1" language="java" name="com.iluwatar.reader.writer.lock.Writer" project="reader-writer-lock"
|
||||
file="/reader-writer-lock/src/main/java/com/iluwatar/reader/writer/lock/Writer.java" binary="false"
|
||||
corner="BOTTOM_RIGHT">
|
||||
<position height="-1" width="-1" x="487" y="105"/>
|
||||
<display autosize="true" stereotype="true" package="true" initial-value="false" signature="true"
|
||||
sort-features="false" accessors="true" visibility="true">
|
||||
<attributes public="true" package="true" protected="true" private="true" static="true"/>
|
||||
<operations public="true" package="true" protected="true" private="true" static="true"/>
|
||||
</display>
|
||||
</class>
|
||||
<class id="2" language="java" name="com.iluwatar.reader.writer.lock.ReaderWriterLock.WriteLock"
|
||||
project="reader-writer-lock"
|
||||
file="/reader-writer-lock/src/main/java/com/iluwatar/reader/writer/lock/ReaderWriterLock.java" binary="false"
|
||||
corner="BOTTOM_RIGHT">
|
||||
<position height="191" width="197" x="488" y="313"/>
|
||||
<display autosize="true" stereotype="true" package="true" initial-value="false" signature="true"
|
||||
sort-features="false" accessors="true" visibility="true">
|
||||
<attributes public="true" package="true" protected="true" private="true" static="true"/>
|
||||
<operations public="true" package="true" protected="true" private="true" static="true"/>
|
||||
</display>
|
||||
</class>
|
||||
<class id="3" language="java" name="com.iluwatar.reader.writer.lock.ReaderWriterLock" project="reader-writer-lock"
|
||||
file="/reader-writer-lock/src/main/java/com/iluwatar/reader/writer/lock/ReaderWriterLock.java" binary="false"
|
||||
corner="BOTTOM_RIGHT">
|
||||
<position height="245" width="224" x="606" y="28"/>
|
||||
<display autosize="true" stereotype="true" package="true" initial-value="false" signature="true"
|
||||
sort-features="false" accessors="true" visibility="true">
|
||||
<attributes public="true" package="true" protected="true" private="true" static="true"/>
|
||||
<operations public="true" package="true" protected="true" private="true" static="true"/>
|
||||
</display>
|
||||
</class>
|
||||
<class id="4" language="java" name="com.iluwatar.reader.writer.lock.Reader" project="reader-writer-lock"
|
||||
file="/reader-writer-lock/src/main/java/com/iluwatar/reader/writer/lock/Reader.java" binary="false"
|
||||
corner="BOTTOM_RIGHT">
|
||||
<position height="-1" width="-1" x="944" y="109"/>
|
||||
<display autosize="true" stereotype="true" package="true" initial-value="false" signature="true"
|
||||
sort-features="false" accessors="true" visibility="true">
|
||||
<attributes public="true" package="true" protected="true" private="true" static="true"/>
|
||||
<operations public="true" package="true" protected="true" private="true" static="true"/>
|
||||
</display>
|
||||
</class>
|
||||
<class id="5" language="java" name="com.iluwatar.reader.writer.lock.ReaderWriterLock.ReadLock"
|
||||
project="reader-writer-lock"
|
||||
file="/reader-writer-lock/src/main/java/com/iluwatar/reader/writer/lock/ReaderWriterLock.java" binary="false"
|
||||
corner="BOTTOM_RIGHT">
|
||||
<position height="191" width="197" x="725" y="313"/>
|
||||
<display autosize="true" stereotype="true" package="true" initial-value="false" signature="true"
|
||||
sort-features="false" accessors="true" visibility="true">
|
||||
<attributes public="true" package="true" protected="true" private="true" static="true"/>
|
||||
<operations public="true" package="true" protected="true" private="true" static="true"/>
|
||||
</display>
|
||||
</class>
|
||||
<nesting id="6">
|
||||
<end type="SOURCE" refId="3"/>
|
||||
<end type="TARGET" refId="2"/>
|
||||
</nesting>
|
||||
<association id="7">
|
||||
<end type="SOURCE" refId="3" navigable="false">
|
||||
<attribute id="8" name="writerLock"/>
|
||||
<multiplicity id="9" minimum="0" maximum="1"/>
|
||||
</end>
|
||||
<end type="TARGET" refId="2" navigable="true"/>
|
||||
<display labels="true" multiplicity="true"/>
|
||||
</association>
|
||||
<association id="10">
|
||||
<end type="SOURCE" refId="3" navigable="false">
|
||||
<attribute id="11" name="readerLock"/>
|
||||
<multiplicity id="12" minimum="0" maximum="1"/>
|
||||
</end>
|
||||
<end type="TARGET" refId="5" navigable="true"/>
|
||||
<display labels="true" multiplicity="true"/>
|
||||
</association>
|
||||
<nesting id="13">
|
||||
<end type="SOURCE" refId="3"/>
|
||||
<end type="TARGET" refId="5"/>
|
||||
</nesting>
|
||||
<classifier-display autosize="true" stereotype="true" package="true" initial-value="false" signature="true"
|
||||
sort-features="false" accessors="true" visibility="true">
|
||||
<attributes public="true" package="true" protected="true" private="true" static="true"/>
|
||||
<operations public="true" package="true" protected="true" private="true" static="true"/>
|
||||
</classifier-display>
|
||||
<association-display labels="true" multiplicity="true"/>
|
||||
</class-diagram>
|
29
reader-writer-lock/index.md
Normal file
29
reader-writer-lock/index.md
Normal file
@ -0,0 +1,29 @@
|
||||
---
|
||||
layout: pattern
|
||||
title: Reader Writer Lock
|
||||
folder: reader-writer-lock
|
||||
permalink: /patterns/reader-writer-lock/
|
||||
categories: Concurrent
|
||||
tags:
|
||||
- Java
|
||||
---
|
||||
|
||||
**Intent:**
|
||||
|
||||
Suppose we have a shared memory area with the basic constraints detailed above. It is possible to protect the shared data behind a mutual exclusion mutex, in which case no two threads can access the data at the same time. However, this solution is suboptimal, because it is possible that a reader R1 might have the lock, and then another reader R2 requests access. It would be foolish for R2 to wait until R1 was done before starting its own read operation; instead, R2 should start right away. This is the motivation for the Reader Writer Lock pattern.
|
||||
|
||||

|
||||
|
||||
**Applicability:**
|
||||
|
||||
Application need to increase the performance of resource synchronize for multiple thread, in particularly there are mixed read/write operations.
|
||||
|
||||
**Real world examples:**
|
||||
|
||||
* [Java Reader Writer Lock](https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReadWriteLock.html)
|
||||
|
||||
**Credits**
|
||||
|
||||
* [Readers–writer lock](https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock)
|
||||
|
||||
* [Readers–writers_problem](https://en.wikipedia.org/wiki/Readers%E2%80%93writers_problem)
|
24
reader-writer-lock/pom.xml
Normal file
24
reader-writer-lock/pom.xml
Normal file
@ -0,0 +1,24 @@
|
||||
<?xml version="1.0"?>
|
||||
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"
|
||||
xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<parent>
|
||||
<groupId>com.iluwatar</groupId>
|
||||
<artifactId>java-design-patterns</artifactId>
|
||||
<version>1.10.0-SNAPSHOT</version>
|
||||
</parent>
|
||||
<artifactId>reader-writer-lock</artifactId>
|
||||
<dependencies>
|
||||
<dependency>
|
||||
<groupId>junit</groupId>
|
||||
<artifactId>junit</artifactId>
|
||||
<scope>test</scope>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.mockito</groupId>
|
||||
<artifactId>mockito-core</artifactId>
|
||||
<scope>test</scope>
|
||||
</dependency>
|
||||
|
||||
</dependencies>
|
||||
</project>
|
@ -0,0 +1,56 @@
|
||||
package com.iluwatar.reader.writer.lock;
|
||||
|
||||
import java.util.concurrent.ExecutorService;
|
||||
import java.util.concurrent.Executors;
|
||||
import java.util.concurrent.TimeUnit;
|
||||
import java.util.stream.IntStream;
|
||||
|
||||
/**
|
||||
*
|
||||
* In a multiple thread applications, the threads may try to synchronize the shared resources
|
||||
* regardless of read or write operation. It leads to a low performance especially in a "read more
|
||||
* write less" system as indeed the read operations are thread-safe to another read operation.
|
||||
* <p>
|
||||
* Reader writer lock is a synchronization primitive that try to resolve this problem. This pattern
|
||||
* allows concurrent access for read-only operations, while write operations require exclusive
|
||||
* access. This means that multiple threads can read the data in parallel but an exclusive lock is
|
||||
* needed for writing or modifying data. When a writer is writing the data, all other writers or
|
||||
* readers will be blocked until the writer is finished writing.
|
||||
*
|
||||
* <p>
|
||||
* This example use two mutex to demonstrate the concurrent access of multiple readers and writers.
|
||||
*
|
||||
*
|
||||
* @author hongshuwei@gmail.com
|
||||
*/
|
||||
public class App {
|
||||
|
||||
/**
|
||||
* Program entry point
|
||||
*
|
||||
* @param args command line args
|
||||
*/
|
||||
public static void main(String[] args) {
|
||||
|
||||
ExecutorService executeService = Executors.newFixedThreadPool(10);
|
||||
ReaderWriterLock lock = new ReaderWriterLock();
|
||||
|
||||
// Start 5 readers
|
||||
IntStream.range(0, 5)
|
||||
.forEach(i -> executeService.submit(new Reader("Reader " + i, lock.readLock())));
|
||||
|
||||
// Start 5 writers
|
||||
IntStream.range(0, 5)
|
||||
.forEach(i -> executeService.submit(new Writer("Writer " + i, lock.writeLock())));
|
||||
// In the system console, it can see that the read operations are executed concurrently while
|
||||
// write operations are exclusive.
|
||||
executeService.shutdown();
|
||||
try {
|
||||
executeService.awaitTermination(5, TimeUnit.SECONDS);
|
||||
} catch (InterruptedException e) {
|
||||
System.out.println("Error waiting for ExecutorService shutdown");
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
}
|
@ -0,0 +1,40 @@
|
||||
package com.iluwatar.reader.writer.lock;
|
||||
|
||||
import java.util.concurrent.locks.Lock;
|
||||
|
||||
/**
|
||||
* Reader class, read when it acquired the read lock
|
||||
*/
|
||||
public class Reader implements Runnable {
|
||||
|
||||
private Lock readLock;
|
||||
|
||||
private String name;
|
||||
|
||||
public Reader(String name, Lock readLock) {
|
||||
this.name = name;
|
||||
this.readLock = readLock;
|
||||
}
|
||||
|
||||
@Override
|
||||
public void run() {
|
||||
readLock.lock();
|
||||
try {
|
||||
read();
|
||||
} catch (InterruptedException e) {
|
||||
e.printStackTrace();
|
||||
} finally {
|
||||
readLock.unlock();
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Simulate the read operation
|
||||
*
|
||||
*/
|
||||
public void read() throws InterruptedException {
|
||||
System.out.println(name + " begin");
|
||||
Thread.sleep(250);
|
||||
System.out.println(name + " finish");
|
||||
}
|
||||
}
|
@ -0,0 +1,211 @@
|
||||
package com.iluwatar.reader.writer.lock;
|
||||
|
||||
import java.util.HashSet;
|
||||
import java.util.Set;
|
||||
import java.util.concurrent.TimeUnit;
|
||||
import java.util.concurrent.locks.Condition;
|
||||
import java.util.concurrent.locks.Lock;
|
||||
import java.util.concurrent.locks.ReadWriteLock;
|
||||
|
||||
/**
|
||||
* Class responsible for control the access for reader or writer
|
||||
*
|
||||
* Allows multiple readers to hold the lock at same time, but if any writer holds the lock then
|
||||
* readers wait. If reader holds the lock then writer waits. This lock is not fair.
|
||||
*/
|
||||
public class ReaderWriterLock implements ReadWriteLock {
|
||||
|
||||
|
||||
private Object readerMutex = new Object();
|
||||
|
||||
private int currentReaderCount = 0;
|
||||
|
||||
/**
|
||||
* Global mutex is used to indicate that whether reader or writer gets the lock in the moment.
|
||||
* <p>
|
||||
* 1. When it contains the reference of {@link readerLock}, it means that the lock is acquired by
|
||||
* the reader, another reader can also do the read operation concurrently. <br>
|
||||
* 2. When it contains the reference of reference of {@link writerLock}, it means that the lock is
|
||||
* acquired by the writer exclusively, no more reader or writer can get the lock.
|
||||
* <p>
|
||||
* This is the most important field in this class to control the access for reader/writer.
|
||||
*/
|
||||
private Set<Object> globalMutex = new HashSet<>();
|
||||
|
||||
private ReadLock readerLock = new ReadLock();
|
||||
private WriteLock writerLock = new WriteLock();
|
||||
|
||||
@Override
|
||||
public Lock readLock() {
|
||||
return readerLock;
|
||||
}
|
||||
|
||||
@Override
|
||||
public Lock writeLock() {
|
||||
return writerLock;
|
||||
}
|
||||
|
||||
/**
|
||||
* return true when globalMutex hold the reference of writerLock
|
||||
*/
|
||||
private boolean doesWriterOwnThisLock() {
|
||||
return globalMutex.contains(writerLock);
|
||||
}
|
||||
|
||||
/**
|
||||
* return true when globalMutex hold the reference of readerLock
|
||||
*/
|
||||
private boolean doesReaderOwnThisLock() {
|
||||
return globalMutex.contains(readerLock);
|
||||
}
|
||||
|
||||
/**
|
||||
* Nobody get the lock when globalMutex contains nothing
|
||||
*
|
||||
*/
|
||||
private boolean isLockFree() {
|
||||
return globalMutex.isEmpty();
|
||||
}
|
||||
|
||||
private void waitUninterruptibly(Object o) {
|
||||
try {
|
||||
o.wait();
|
||||
} catch (InterruptedException e) {
|
||||
e.printStackTrace();
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Reader Lock, can be access for more than one reader concurrently if no writer get the lock
|
||||
*/
|
||||
private class ReadLock implements Lock {
|
||||
|
||||
@Override
|
||||
public void lock() {
|
||||
|
||||
synchronized (readerMutex) {
|
||||
|
||||
currentReaderCount++;
|
||||
if (currentReaderCount == 1) {
|
||||
// Try to get the globalMutex lock for the first reader
|
||||
synchronized (globalMutex) {
|
||||
while (true) {
|
||||
// If the no one get the lock or the lock is locked by reader, just set the reference
|
||||
// to the globalMutex to indicate that the lock is locked by Reader.
|
||||
if (isLockFree() || doesReaderOwnThisLock()) {
|
||||
globalMutex.add(this);
|
||||
break;
|
||||
} else {
|
||||
// If lock is acquired by the write, let the thread wait until the writer release
|
||||
// the lock
|
||||
waitUninterruptibly(globalMutex);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@Override
|
||||
public void unlock() {
|
||||
|
||||
synchronized (readerMutex) {
|
||||
currentReaderCount--;
|
||||
// Release the lock only when it is the last reader, it is ensure that the lock is released
|
||||
// when all reader is completely.
|
||||
if (currentReaderCount == 0) {
|
||||
synchronized (globalMutex) {
|
||||
// Notify the waiter, mostly the writer
|
||||
globalMutex.remove(this);
|
||||
globalMutex.notifyAll();
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
@Override
|
||||
public void lockInterruptibly() throws InterruptedException {
|
||||
throw new UnsupportedOperationException();
|
||||
}
|
||||
|
||||
@Override
|
||||
public boolean tryLock() {
|
||||
throw new UnsupportedOperationException();
|
||||
}
|
||||
|
||||
@Override
|
||||
public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {
|
||||
throw new UnsupportedOperationException();
|
||||
}
|
||||
|
||||
@Override
|
||||
public Condition newCondition() {
|
||||
throw new UnsupportedOperationException();
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
/**
|
||||
* Writer Lock, can only be accessed by one writer concurrently
|
||||
*/
|
||||
private class WriteLock implements Lock {
|
||||
|
||||
@Override
|
||||
public void lock() {
|
||||
|
||||
synchronized (globalMutex) {
|
||||
|
||||
while (true) {
|
||||
// When there is no one acquired the lock, just put the writeLock reference to the
|
||||
// globalMutex to indicate that the lock is acquired by one writer.
|
||||
// It is ensure that writer can only get the lock when no reader/writer acquired the lock.
|
||||
if (isLockFree()) {
|
||||
globalMutex.add(this);
|
||||
break;
|
||||
} else if (doesWriterOwnThisLock()) {
|
||||
// Wait when other writer get the lock
|
||||
waitUninterruptibly(globalMutex);
|
||||
} else if (doesReaderOwnThisLock()) {
|
||||
// Wait when other reader get the lock
|
||||
waitUninterruptibly(globalMutex);
|
||||
} else {
|
||||
throw new AssertionError("it should never reach here");
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@Override
|
||||
public void unlock() {
|
||||
|
||||
synchronized (globalMutex) {
|
||||
globalMutex.remove(this);
|
||||
// Notify the waiter, other writer or reader
|
||||
globalMutex.notifyAll();
|
||||
}
|
||||
}
|
||||
|
||||
@Override
|
||||
public void lockInterruptibly() throws InterruptedException {
|
||||
throw new UnsupportedOperationException();
|
||||
}
|
||||
|
||||
@Override
|
||||
public boolean tryLock() {
|
||||
throw new UnsupportedOperationException();
|
||||
}
|
||||
|
||||
@Override
|
||||
public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {
|
||||
throw new UnsupportedOperationException();
|
||||
}
|
||||
|
||||
@Override
|
||||
public Condition newCondition() {
|
||||
throw new UnsupportedOperationException();
|
||||
}
|
||||
}
|
||||
|
||||
}
|
@ -0,0 +1,40 @@
|
||||
package com.iluwatar.reader.writer.lock;
|
||||
|
||||
import java.util.concurrent.locks.Lock;
|
||||
|
||||
/**
|
||||
* Writer class, write when it acquired the write lock
|
||||
*/
|
||||
public class Writer implements Runnable {
|
||||
|
||||
private Lock writeLock = null;
|
||||
|
||||
private String name;
|
||||
|
||||
public Writer(String name, Lock writeLock) {
|
||||
this.name = name;
|
||||
this.writeLock = writeLock;
|
||||
}
|
||||
|
||||
|
||||
@Override
|
||||
public void run() {
|
||||
writeLock.lock();
|
||||
try {
|
||||
write();
|
||||
} catch (InterruptedException e) {
|
||||
e.printStackTrace();
|
||||
} finally {
|
||||
writeLock.unlock();
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Simulate the write operation
|
||||
*/
|
||||
public void write() throws InterruptedException {
|
||||
System.out.println(name + " begin");
|
||||
Thread.sleep(250);
|
||||
System.out.println(name + " finish");
|
||||
}
|
||||
}
|
@ -0,0 +1,16 @@
|
||||
package com.iluwatar.reader.writer.lock;
|
||||
|
||||
import org.junit.Test;
|
||||
|
||||
/**
|
||||
* Application test
|
||||
*/
|
||||
public class AppTest {
|
||||
|
||||
@Test
|
||||
public void test() throws Exception {
|
||||
String[] args = {};
|
||||
App.main(args);
|
||||
|
||||
}
|
||||
}
|
@ -0,0 +1,81 @@
|
||||
package com.iluwatar.reader.writer.lock;
|
||||
|
||||
import static org.mockito.Mockito.inOrder;
|
||||
|
||||
import java.util.concurrent.ExecutorService;
|
||||
import java.util.concurrent.Executors;
|
||||
import java.util.concurrent.TimeUnit;
|
||||
|
||||
import org.junit.Test;
|
||||
import org.mockito.InOrder;
|
||||
|
||||
/**
|
||||
* @author hongshuwei@gmail.com
|
||||
*/
|
||||
public class ReaderAndWriterTest extends StdOutTest {
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* Verify reader and writer can only get the lock to read and write orderly
|
||||
*/
|
||||
@Test
|
||||
public void testReadAndWrite() throws Exception {
|
||||
|
||||
ReaderWriterLock lock = new ReaderWriterLock();
|
||||
|
||||
Reader reader1 = new Reader("Reader 1", lock.readLock());
|
||||
Writer writer1 = new Writer("Writer 1", lock.writeLock());
|
||||
|
||||
ExecutorService executeService = Executors.newFixedThreadPool(2);
|
||||
executeService.submit(reader1);
|
||||
// Let reader1 execute first
|
||||
Thread.sleep(150);
|
||||
executeService.submit(writer1);
|
||||
|
||||
executeService.shutdown();
|
||||
try {
|
||||
executeService.awaitTermination(10, TimeUnit.SECONDS);
|
||||
} catch (InterruptedException e) {
|
||||
System.out.println("Error waiting for ExecutorService shutdown");
|
||||
}
|
||||
|
||||
final InOrder inOrder = inOrder(getStdOutMock());
|
||||
inOrder.verify(getStdOutMock()).println("Reader 1 begin");
|
||||
inOrder.verify(getStdOutMock()).println("Reader 1 finish");
|
||||
inOrder.verify(getStdOutMock()).println("Writer 1 begin");
|
||||
inOrder.verify(getStdOutMock()).println("Writer 1 finish");
|
||||
}
|
||||
|
||||
/**
|
||||
* Verify reader and writer can only get the lock to read and write orderly
|
||||
*/
|
||||
@Test
|
||||
public void testWriteAndRead() throws Exception {
|
||||
|
||||
ExecutorService executeService = Executors.newFixedThreadPool(2);
|
||||
ReaderWriterLock lock = new ReaderWriterLock();
|
||||
|
||||
Reader reader1 = new Reader("Reader 1", lock.readLock());
|
||||
Writer writer1 = new Writer("Writer 1", lock.writeLock());
|
||||
|
||||
executeService.submit(writer1);
|
||||
// Let writer1 execute first
|
||||
Thread.sleep(150);
|
||||
executeService.submit(reader1);
|
||||
|
||||
executeService.shutdown();
|
||||
try {
|
||||
executeService.awaitTermination(10, TimeUnit.SECONDS);
|
||||
} catch (InterruptedException e) {
|
||||
System.out.println("Error waiting for ExecutorService shutdown");
|
||||
}
|
||||
|
||||
final InOrder inOrder = inOrder(getStdOutMock());
|
||||
inOrder.verify(getStdOutMock()).println("Writer 1 begin");
|
||||
inOrder.verify(getStdOutMock()).println("Writer 1 finish");
|
||||
inOrder.verify(getStdOutMock()).println("Reader 1 begin");
|
||||
inOrder.verify(getStdOutMock()).println("Reader 1 finish");
|
||||
}
|
||||
}
|
||||
|
@ -0,0 +1,50 @@
|
||||
package com.iluwatar.reader.writer.lock;
|
||||
|
||||
import static org.mockito.Mockito.inOrder;
|
||||
import static org.mockito.Mockito.spy;
|
||||
|
||||
import java.util.concurrent.ExecutorService;
|
||||
import java.util.concurrent.Executors;
|
||||
import java.util.concurrent.TimeUnit;
|
||||
|
||||
import org.junit.Test;
|
||||
import org.mockito.InOrder;
|
||||
|
||||
/**
|
||||
* @author hongshuwei@gmail.com
|
||||
*/
|
||||
public class ReaderTest extends StdOutTest {
|
||||
|
||||
/**
|
||||
* Verify that multiple readers can get the read lock concurrently
|
||||
*/
|
||||
@Test
|
||||
public void testRead() throws Exception {
|
||||
|
||||
ExecutorService executeService = Executors.newFixedThreadPool(2);
|
||||
ReaderWriterLock lock = new ReaderWriterLock();
|
||||
|
||||
Reader reader1 = spy(new Reader("Reader 1", lock.readLock()));
|
||||
Reader reader2 = spy(new Reader("Reader 2", lock.readLock()));
|
||||
|
||||
executeService.submit(reader1);
|
||||
Thread.sleep(150);
|
||||
executeService.submit(reader2);
|
||||
|
||||
executeService.shutdown();
|
||||
try {
|
||||
executeService.awaitTermination(10, TimeUnit.SECONDS);
|
||||
} catch (InterruptedException e) {
|
||||
System.out.println("Error waiting for ExecutorService shutdown");
|
||||
}
|
||||
|
||||
// Read operation will hold the read lock 250 milliseconds, so here we prove that multiple reads
|
||||
// can be performed in the same time.
|
||||
final InOrder inOrder = inOrder(getStdOutMock());
|
||||
inOrder.verify(getStdOutMock()).println("Reader 1 begin");
|
||||
inOrder.verify(getStdOutMock()).println("Reader 2 begin");
|
||||
inOrder.verify(getStdOutMock()).println("Reader 1 finish");
|
||||
inOrder.verify(getStdOutMock()).println("Reader 2 finish");
|
||||
|
||||
}
|
||||
}
|
@ -0,0 +1,53 @@
|
||||
package com.iluwatar.reader.writer.lock;
|
||||
|
||||
import org.junit.After;
|
||||
import org.junit.Before;
|
||||
|
||||
import java.io.PrintStream;
|
||||
|
||||
import static org.mockito.Mockito.mock;
|
||||
|
||||
/**
|
||||
* Date: 12/10/15 - 8:37 PM
|
||||
*
|
||||
* @author Jeroen Meulemeester
|
||||
*/
|
||||
public abstract class StdOutTest {
|
||||
|
||||
/**
|
||||
* The mocked standard out {@link PrintStream}, required since some actions don't have any
|
||||
* influence on accessible objects, except for writing to std-out using {@link System#out}
|
||||
*/
|
||||
private final PrintStream stdOutMock = mock(PrintStream.class);
|
||||
|
||||
/**
|
||||
* Keep the original std-out so it can be restored after the test
|
||||
*/
|
||||
private final PrintStream stdOutOrig = System.out;
|
||||
|
||||
/**
|
||||
* Inject the mocked std-out {@link PrintStream} into the {@link System} class before each test
|
||||
*/
|
||||
@Before
|
||||
public void setUp() {
|
||||
System.setOut(this.stdOutMock);
|
||||
}
|
||||
|
||||
/**
|
||||
* Removed the mocked std-out {@link PrintStream} again from the {@link System} class
|
||||
*/
|
||||
@After
|
||||
public void tearDown() {
|
||||
System.setOut(this.stdOutOrig);
|
||||
}
|
||||
|
||||
/**
|
||||
* Get the mocked stdOut {@link PrintStream}
|
||||
*
|
||||
* @return The stdOut print stream mock, renewed before each test
|
||||
*/
|
||||
final PrintStream getStdOutMock() {
|
||||
return this.stdOutMock;
|
||||
}
|
||||
|
||||
}
|
@ -0,0 +1,50 @@
|
||||
package com.iluwatar.reader.writer.lock;
|
||||
|
||||
import static org.mockito.Mockito.inOrder;
|
||||
import static org.mockito.Mockito.spy;
|
||||
|
||||
import java.util.concurrent.ExecutorService;
|
||||
import java.util.concurrent.Executors;
|
||||
import java.util.concurrent.TimeUnit;
|
||||
|
||||
import org.junit.Test;
|
||||
import org.mockito.InOrder;
|
||||
|
||||
/**
|
||||
* @author hongshuwei@gmail.com
|
||||
*/
|
||||
public class WriterTest extends StdOutTest {
|
||||
|
||||
/**
|
||||
* Verify that multiple writers will get the lock in order.
|
||||
*/
|
||||
@Test
|
||||
public void testWrite() throws Exception {
|
||||
|
||||
ExecutorService executeService = Executors.newFixedThreadPool(2);
|
||||
ReaderWriterLock lock = new ReaderWriterLock();
|
||||
|
||||
Writer writer1 = spy(new Writer("Writer 1", lock.writeLock()));
|
||||
Writer writer2 = spy(new Writer("Writer 2", lock.writeLock()));
|
||||
|
||||
executeService.submit(writer1);
|
||||
// Let write1 execute first
|
||||
Thread.sleep(150);
|
||||
executeService.submit(writer2);
|
||||
|
||||
executeService.shutdown();
|
||||
try {
|
||||
executeService.awaitTermination(10, TimeUnit.SECONDS);
|
||||
} catch (InterruptedException e) {
|
||||
System.out.println("Error waiting for ExecutorService shutdown");
|
||||
}
|
||||
// Write operation will hold the write lock 250 milliseconds, so here we verify that when two
|
||||
// writer execute concurrently, the second writer can only writes only when the first one is
|
||||
// finished.
|
||||
final InOrder inOrder = inOrder(getStdOutMock());
|
||||
inOrder.verify(getStdOutMock()).println("Writer 1 begin");
|
||||
inOrder.verify(getStdOutMock()).println("Writer 1 finish");
|
||||
inOrder.verify(getStdOutMock()).println("Writer 2 begin");
|
||||
inOrder.verify(getStdOutMock()).println("Writer 2 finish");
|
||||
}
|
||||
}
|
@ -10,7 +10,8 @@ tags:
|
||||
- Spring
|
||||
---
|
||||
|
||||
**Intent:** Repository layer is added between the domain and data mapping
|
||||
## Intent
|
||||
Repository layer is added between the domain and data mapping
|
||||
layers to isolate domain objects from details of the database access code and
|
||||
to minimize scattering and duplication of query code. The Repository pattern is
|
||||
especially useful in systems where number of domain classes is large or heavy
|
||||
@ -18,19 +19,19 @@ querying is utilized.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Repository pattern when
|
||||
## Applicability
|
||||
Use the Repository pattern when
|
||||
|
||||
* the number of domain objects is large
|
||||
* you want to avoid duplication of query code
|
||||
* you want to keep the database querying code in single place
|
||||
* you have multiple data sources
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [Spring Data](http://projects.spring.io/spring-data/)
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Don’t use DAO, use Repository](http://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/)
|
||||
* [Advanced Spring Data JPA - Specifications and Querydsl](https://spring.io/blog/2011/04/26/advanced-spring-data-jpa-specifications-and-querydsl/)
|
||||
|
||||
|
@ -10,10 +10,12 @@ tags:
|
||||
- Idiom
|
||||
---
|
||||
|
||||
**Intent:** Resource Acquisition Is Initialization pattern can be used to implement exception safe resource management.
|
||||
## Intent
|
||||
Resource Acquisition Is Initialization pattern can be used to implement exception safe resource management.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Resource Acquisition Is Initialization pattern when
|
||||
## Applicability
|
||||
Use the Resource Acquisition Is Initialization pattern when
|
||||
|
||||
* you have resources that must be closed in every condition
|
||||
|
@ -9,12 +9,14 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** Servant is used for providing some behavior to a group of classes.
|
||||
## Intent
|
||||
Servant is used for providing some behavior to a group of classes.
|
||||
Instead of defining that behavior in each class - or when we cannot factor out
|
||||
this behavior in the common parent class - it is defined once in the Servant.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Servant pattern when
|
||||
## Applicability
|
||||
Use the Servant pattern when
|
||||
|
||||
* when we want some objects to perform a common action and don't want to define this action as a method in every class.
|
||||
|
@ -9,7 +9,8 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Service Layer is an abstraction over domain logic. Typically
|
||||
## Intent
|
||||
Service Layer is an abstraction over domain logic. Typically
|
||||
applications require multiple kinds of interfaces to the data they store and
|
||||
logic they implement: data loaders, user interfaces, integration gateways, and
|
||||
others. Despite their different purposes, these interfaces often need common
|
||||
@ -18,12 +19,13 @@ its business logic. The Service Layer fulfills this role.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Service Layer pattern when
|
||||
## Applicability
|
||||
Use the Service Layer pattern when
|
||||
|
||||
* you want to encapsulate domain logic under API
|
||||
* you need to implement multiple interfaces with common logic and data
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Martin Fowler - Service Layer](http://martinfowler.com/eaaCatalog/serviceLayer.html)
|
||||
* [Patterns of Enterprise Application Architecture](http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420)
|
||||
|
@ -10,12 +10,14 @@ tags:
|
||||
- Performance
|
||||
---
|
||||
|
||||
**Intent:** Encapsulate the processes involved in obtaining a service with a
|
||||
## Intent
|
||||
Encapsulate the processes involved in obtaining a service with a
|
||||
strong abstraction layer.
|
||||
|
||||

|
||||
|
||||
**Applicability:** The service locator pattern is applicable whenever we want
|
||||
## Applicability
|
||||
The service locator pattern is applicable whenever we want
|
||||
to locate/fetch various services using JNDI which, typically, is a redundant
|
||||
and expensive lookup. The service Locator pattern addresses this expensive
|
||||
lookup by making use of caching techniques ie. for the very first time a
|
||||
@ -24,12 +26,12 @@ the relevant service and then finally caches this service object. Now, further
|
||||
lookups of the same service via Service Locator is done in its cache which
|
||||
improves the performance of application to great extent.
|
||||
|
||||
**Typical Use Case:**
|
||||
## Typical Use Case
|
||||
|
||||
* when network hits are expensive and time consuming
|
||||
* lookups of services are done quite frequently
|
||||
* large number of services are being used
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [J2EE Design Patterns](http://www.amazon.com/J2EE-Design-Patterns-William-Crawford/dp/0596004273/ref=sr_1_2)
|
||||
|
@ -10,26 +10,28 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** Ensure a class only has one instance, and provide a global point of
|
||||
## Intent
|
||||
Ensure a class only has one instance, and provide a global point of
|
||||
access to it.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Singleton pattern when
|
||||
## Applicability
|
||||
Use the Singleton pattern when
|
||||
|
||||
* there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point
|
||||
* when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code
|
||||
|
||||
**Typical Use Case:**
|
||||
## Typical Use Case
|
||||
|
||||
* the logging class
|
||||
* managing a connection to a database
|
||||
* file manager
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [java.lang.Runtime#getRuntime()](http://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#getRuntime%28%29)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -9,18 +9,20 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** Specification pattern separates the statement of how to match a
|
||||
## Intent
|
||||
Specification pattern separates the statement of how to match a
|
||||
candidate, from the candidate object that it is matched against. As well as its
|
||||
usefulness in selection, it is also valuable for validation and for building to
|
||||
order
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Specification pattern when
|
||||
## Applicability
|
||||
Use the Specification pattern when
|
||||
|
||||
* 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)
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Martin Fowler - Specifications](http://martinfowler.com/apsupp/spec.pdf)
|
||||
|
@ -10,18 +10,21 @@ tags:
|
||||
- Gang Of Four
|
||||
---
|
||||
|
||||
**Also known as:** Objects for States
|
||||
## Also known as
|
||||
Objects for States
|
||||
|
||||
**Intent:** Allow an object to alter its behavior when its internal state
|
||||
## Intent
|
||||
Allow an object to alter its behavior when its internal state
|
||||
changes. The object will appear to change its class.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the State pattern in either of the following cases
|
||||
## Applicability
|
||||
Use the State pattern in either of the following cases
|
||||
|
||||
* an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
|
||||
* operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects.
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -9,13 +9,15 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** An extension of the Builder pattern that fully guides the user through the creation of the object with no chances of confusion.
|
||||
## Intent
|
||||
An extension of the Builder pattern that fully guides the user through the creation of the object with no chances of confusion.
|
||||
The user experience will be much more improved by the fact that he will only see the next step methods available, NO build method until is the right time to build the object.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Step 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 when in the process of constructing the order is important.
|
||||
## Applicability
|
||||
Use the Step 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 when in the process of constructing the order is important.
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Marco Castigliego - Step Builder](http://rdafbn.blogspot.co.uk/2012/07/step-builder-pattern_28.html)
|
||||
|
@ -10,21 +10,24 @@ tags:
|
||||
- Gang Of Four
|
||||
---
|
||||
|
||||
**Also known as:** Policy
|
||||
## Also known as
|
||||
Policy
|
||||
|
||||
**Intent:** Define a family of algorithms, encapsulate each one, and make them
|
||||
## Intent
|
||||
Define a family of algorithms, encapsulate each one, and make them
|
||||
interchangeable. Strategy lets the algorithm vary independently from clients
|
||||
that use it.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Strategy pattern when
|
||||
## Applicability
|
||||
Use the Strategy pattern when
|
||||
|
||||
* many related classes differ only in their behavior. Strategies provide a way to configure a class either one of many behaviors
|
||||
* you need different variants of an algorithm. for example, you might define algorithms reflecting different space/time trade-offs. Strategies can be used when these variants are implemented as a class hierarchy of algorithms
|
||||
* an algorithm uses data that clients shouldn't know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures
|
||||
* a class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,18 +10,20 @@ tags:
|
||||
- Gang Of Four
|
||||
---
|
||||
|
||||
**Intent:** Define the skeleton of an algorithm in an operation, deferring some
|
||||
## Intent
|
||||
Define the skeleton of an algorithm in an operation, deferring some
|
||||
steps to subclasses. Template method lets subclasses redefine certain steps of
|
||||
an algorithm without changing the algorithm's structure.
|
||||
|
||||

|
||||
|
||||
**Applicability:** The Template Method pattern should be used
|
||||
## Applicability
|
||||
The Template Method pattern should be used
|
||||
|
||||
* to implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behavior that can vary
|
||||
* when common behavior among subclasses should be factored and localized in a common class to avoid code duplication. This is good example of "refactoring to generalize" as described by Opdyke and Johnson. You first identify the differences in the existing code and then separate the differences into new operations. Finally, you replace the differing code with a template method that calls one of these new operations
|
||||
* to control subclasses extensions. You can define a template method that calls "hook" operations at specific points, thereby permitting extensions only at those points
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
@ -10,7 +10,8 @@ tags:
|
||||
- Performance
|
||||
---
|
||||
|
||||
**Intent:** It is often the case that tasks to be executed are short-lived and
|
||||
## Intent
|
||||
It is often the case that tasks to be executed are short-lived and
|
||||
the number of tasks is large. Creating a new thread for each task would make
|
||||
the system spend more time creating and destroying the threads than executing
|
||||
the actual tasks. Thread Pool solves this problem by reusing existing threads
|
||||
@ -18,6 +19,7 @@ and eliminating the latency of creating new threads.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Thread Pool pattern when
|
||||
## Applicability
|
||||
Use the Thread Pool pattern when
|
||||
|
||||
* you have a large number of short-lived tasks to be executed in parallel
|
||||
|
@ -9,17 +9,19 @@ tags:
|
||||
- Difficulty-Beginner
|
||||
---
|
||||
|
||||
**Intent:** Tolerant Reader is an integration pattern that helps creating
|
||||
## Intent
|
||||
Tolerant Reader is an integration pattern that helps creating
|
||||
robust communication systems. The idea is to be as tolerant as possible when
|
||||
reading data from another service. This way, when the communication schema
|
||||
changes, the readers must not break.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Tolerant Reader pattern when
|
||||
## Applicability
|
||||
Use the Tolerant Reader pattern when
|
||||
|
||||
* the communication schema can evolve and change and yet the receiving side should not break
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Martin Fowler - Tolerant Reader](http://martinfowler.com/bliki/TolerantReader.html)
|
||||
|
@ -9,16 +9,18 @@ tags:
|
||||
- Difficulty-Intermediate
|
||||
---
|
||||
|
||||
**Intent:** Twin pattern is a design pattern which provides a standard solution to simulate multiple
|
||||
## Intent
|
||||
Twin pattern is a design pattern which provides a standard solution to simulate multiple
|
||||
inheritance in java
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Twin idiom when
|
||||
## Applicability
|
||||
Use the Twin idiom when
|
||||
|
||||
* to simulate multiple inheritance in a language that does not support this feature.
|
||||
* to avoid certain problems of multiple inheritance such as name clashes.
|
||||
|
||||
**Credits:**
|
||||
## Credits
|
||||
|
||||
* [Twin – A Design Pattern for Modeling Multiple Inheritance](http://www.ssw.uni-linz.ac.at/Research/Papers/Moe99/Paper.pdf)
|
||||
|
@ -10,22 +10,24 @@ tags:
|
||||
- Gang Of Four
|
||||
---
|
||||
|
||||
**Intent:** Represent an operation to be performed on the elements of an object
|
||||
## Intent
|
||||
Represent an operation to be performed on the elements of an object
|
||||
structure. Visitor lets you define a new operation without changing the classes
|
||||
of the elements on which it operates.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Visitor pattern when
|
||||
## Applicability
|
||||
Use the Visitor pattern when
|
||||
|
||||
* an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes
|
||||
* many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid "polluting" their classes with these operations. Visitor lets you keep related operations together by defining them in one class. When the object structure is shared by many applications, use Visitor to put operations in just those applications that need them
|
||||
* the classes defining the object structure rarely change, but you often want to define new operations over the structure. Changing the object structure classes requires redefining the interface to all visitors, which is potentially costly. If the object structure classes change often, then it's probably better to define the operations in those classes
|
||||
|
||||
**Real world examples:**
|
||||
## Real world examples
|
||||
|
||||
* [Apache Wicket](https://github.com/apache/wicket) component tree, see [MarkupContainer](https://github.com/apache/wicket/blob/b60ec64d0b50a611a9549809c9ab216f0ffa3ae3/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java)
|
||||
|
||||
**Credits**
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||
|
Loading…
x
Reference in New Issue
Block a user