From ea524ee2c0ca2ec8706f62f3a38b814806c4dad5 Mon Sep 17 00:00:00 2001 From: Ilkka Seppala Date: Thu, 13 Aug 2015 20:48:29 +0300 Subject: [PATCH 1/3] #84 Removed Layers stuff accidentally pushed to master --- layers/pom.xml | 36 ------ .../main/java/com/iluwatar/layers/App.java | 27 ----- .../main/java/com/iluwatar/layers/Cake.java | 57 --------- .../iluwatar/layers/CakeBakingException.java | 11 -- .../iluwatar/layers/CakeBakingService.java | 16 --- .../layers/CakeBakingServiceImpl.java | 111 ------------------ .../java/com/iluwatar/layers/CakeDao.java | 9 -- .../java/com/iluwatar/layers/CakeInfo.java | 23 ---- .../java/com/iluwatar/layers/CakeLayer.java | 67 ----------- .../com/iluwatar/layers/CakeLayerDao.java | 9 -- .../com/iluwatar/layers/CakeLayerInfo.java | 27 ----- .../java/com/iluwatar/layers/CakeTopping.java | 67 ----------- .../com/iluwatar/layers/CakeToppingDao.java | 9 -- .../com/iluwatar/layers/CakeToppingInfo.java | 27 ----- .../main/resources/META-INF/persistence.xml | 8 -- .../src/main/resources/applicationContext.xml | 42 ------- .../java/com/iluwatar/layers/AppTest.java | 12 -- pom.xml | 1 - 18 files changed, 559 deletions(-) delete mode 100644 layers/pom.xml delete mode 100644 layers/src/main/java/com/iluwatar/layers/App.java delete mode 100644 layers/src/main/java/com/iluwatar/layers/Cake.java delete mode 100644 layers/src/main/java/com/iluwatar/layers/CakeBakingException.java delete mode 100644 layers/src/main/java/com/iluwatar/layers/CakeBakingService.java delete mode 100644 layers/src/main/java/com/iluwatar/layers/CakeBakingServiceImpl.java delete mode 100644 layers/src/main/java/com/iluwatar/layers/CakeDao.java delete mode 100644 layers/src/main/java/com/iluwatar/layers/CakeInfo.java delete mode 100644 layers/src/main/java/com/iluwatar/layers/CakeLayer.java delete mode 100644 layers/src/main/java/com/iluwatar/layers/CakeLayerDao.java delete mode 100644 layers/src/main/java/com/iluwatar/layers/CakeLayerInfo.java delete mode 100644 layers/src/main/java/com/iluwatar/layers/CakeTopping.java delete mode 100644 layers/src/main/java/com/iluwatar/layers/CakeToppingDao.java delete mode 100644 layers/src/main/java/com/iluwatar/layers/CakeToppingInfo.java delete mode 100644 layers/src/main/resources/META-INF/persistence.xml delete mode 100644 layers/src/main/resources/applicationContext.xml delete mode 100644 layers/src/test/java/com/iluwatar/layers/AppTest.java diff --git a/layers/pom.xml b/layers/pom.xml deleted file mode 100644 index dd036e74c..000000000 --- a/layers/pom.xml +++ /dev/null @@ -1,36 +0,0 @@ - - - 4.0.0 - - com.iluwatar - java-design-patterns - 1.5.0 - - com.iluwatar.layers - layers - - - org.springframework.data - spring-data-jpa - - - org.hibernate - hibernate-entitymanager - - - commons-dbcp - commons-dbcp - - - com.h2database - h2 - - - junit - junit - test - - - diff --git a/layers/src/main/java/com/iluwatar/layers/App.java b/layers/src/main/java/com/iluwatar/layers/App.java deleted file mode 100644 index 239674d02..000000000 --- a/layers/src/main/java/com/iluwatar/layers/App.java +++ /dev/null @@ -1,27 +0,0 @@ -package com.iluwatar.layers; - -import java.util.Arrays; - -public class App { - - public static void main(String[] args) { - - CakeBakingService service = new CakeBakingServiceImpl(); - service.saveNewLayer(new CakeLayerInfo("chocolate", 1200)); - service.saveNewLayer(new CakeLayerInfo("banana", 900)); - service.saveNewLayer(new CakeLayerInfo("strawberry", 950)); - service.getAllLayers().stream().forEach((layer) -> System.out.println(layer)); - - service.saveNewTopping(new CakeToppingInfo("candies", 350)); - service.getAllToppings().stream().forEach((topping) -> System.out.println(topping)); - - CakeInfo cakeInfo = new CakeInfo(new CakeToppingInfo("candies", 0), - Arrays.asList(new CakeLayerInfo("chocolate", 0), new CakeLayerInfo("chocolate", 0), - new CakeLayerInfo("chocolate", 0))); - try { - service.bakeNewCake(cakeInfo); - } catch (CakeBakingException e) { - e.printStackTrace(); - } - } -} diff --git a/layers/src/main/java/com/iluwatar/layers/Cake.java b/layers/src/main/java/com/iluwatar/layers/Cake.java deleted file mode 100644 index 5bdb4ae51..000000000 --- a/layers/src/main/java/com/iluwatar/layers/Cake.java +++ /dev/null @@ -1,57 +0,0 @@ -package com.iluwatar.layers; - -import java.util.ArrayList; -import java.util.List; - -import javax.persistence.CascadeType; -import javax.persistence.Entity; -import javax.persistence.GeneratedValue; -import javax.persistence.Id; -import javax.persistence.OneToMany; -import javax.persistence.OneToOne; - -@Entity -public class Cake { - - @Id - @GeneratedValue - private Long id; - - @OneToOne(cascade = CascadeType.ALL) - private CakeTopping topping; - - @OneToMany(cascade = CascadeType.ALL) - private List layers; - - public Cake() { - setLayers(new ArrayList<>()); - } - - public Long getId() { - return id; - } - - public void setId(Long id) { - this.id = id; - } - - public CakeTopping getTopping() { - return topping; - } - - public void setTopping(CakeTopping topping) { - this.topping = topping; - } - - public List getLayers() { - return layers; - } - - public void setLayers(List layers) { - this.layers = layers; - } - - public void addLayer(CakeLayer layer) { - this.layers.add(layer); - } -} diff --git a/layers/src/main/java/com/iluwatar/layers/CakeBakingException.java b/layers/src/main/java/com/iluwatar/layers/CakeBakingException.java deleted file mode 100644 index 2b131da19..000000000 --- a/layers/src/main/java/com/iluwatar/layers/CakeBakingException.java +++ /dev/null @@ -1,11 +0,0 @@ -package com.iluwatar.layers; - -public class CakeBakingException extends Exception { - - public CakeBakingException() { - } - - public CakeBakingException(String message) { - super(message); - } -} diff --git a/layers/src/main/java/com/iluwatar/layers/CakeBakingService.java b/layers/src/main/java/com/iluwatar/layers/CakeBakingService.java deleted file mode 100644 index 731650d7e..000000000 --- a/layers/src/main/java/com/iluwatar/layers/CakeBakingService.java +++ /dev/null @@ -1,16 +0,0 @@ -package com.iluwatar.layers; - -import java.util.List; - -public interface CakeBakingService { - - void bakeNewCake(CakeInfo cakeInfo) throws CakeBakingException; - - void saveNewTopping(CakeToppingInfo toppingInfo); - - List getAllToppings(); - - void saveNewLayer(CakeLayerInfo layerInfo); - - List getAllLayers(); -} diff --git a/layers/src/main/java/com/iluwatar/layers/CakeBakingServiceImpl.java b/layers/src/main/java/com/iluwatar/layers/CakeBakingServiceImpl.java deleted file mode 100644 index 419a31d4f..000000000 --- a/layers/src/main/java/com/iluwatar/layers/CakeBakingServiceImpl.java +++ /dev/null @@ -1,111 +0,0 @@ -package com.iluwatar.layers; - -import java.util.ArrayList; -import java.util.Iterator; -import java.util.List; -import java.util.Optional; -import java.util.stream.Collectors; - -import org.springframework.context.support.AbstractApplicationContext; -import org.springframework.context.support.ClassPathXmlApplicationContext; -import org.springframework.stereotype.Service; -import org.springframework.transaction.annotation.Transactional; - -@Service -@Transactional -public class CakeBakingServiceImpl implements CakeBakingService { - - private AbstractApplicationContext context; - - public CakeBakingServiceImpl() { - this.context = new ClassPathXmlApplicationContext("applicationContext.xml"); - } - - @Override - public void bakeNewCake(CakeInfo cakeInfo) throws CakeBakingException { - List allToppings = getAllToppings(); - List matchingToppings = allToppings.stream() - .filter((t) -> t.name.equals(cakeInfo.cakeToppingInfo.name)).collect(Collectors.toList()); - if (matchingToppings.isEmpty()) { - throw new CakeBakingException(String.format("Topping %s is not available", cakeInfo.cakeToppingInfo.name)); - } - List allLayers = getAllLayerEntities(); - List foundLayers = new ArrayList<>(); - for (CakeLayerInfo info: cakeInfo.cakeLayerInfos) { - Optional found = allLayers.stream().filter((layer) -> layer.getName().equals(info.name)).findFirst(); - if (!found.isPresent()) { - throw new CakeBakingException(String.format("Layer %s is not available", info.name)); - } else { - foundLayers.add(found.get()); - } - } - CakeToppingDao toppingBean = context.getBean(CakeToppingDao.class); - CakeTopping topping = toppingBean.findOne(matchingToppings.iterator().next().id.get()); - CakeDao cakeBean = context.getBean(CakeDao.class); - Cake cake = new Cake(); - cake = cakeBean.save(cake); - cake.setTopping(topping); - topping.setCake(cake); - cake.setLayers(foundLayers); - for (CakeLayer layer: foundLayers) { - layer.setCake(cake); - } - cakeBean.save(cake); - } - - @Override - public void saveNewTopping(CakeToppingInfo toppingInfo) { - CakeToppingDao bean = context.getBean(CakeToppingDao.class); - bean.save(new CakeTopping(toppingInfo.name, toppingInfo.calories)); - } - - @Override - public void saveNewLayer(CakeLayerInfo layerInfo) { - CakeLayerDao bean = context.getBean(CakeLayerDao.class); - bean.save(new CakeLayer(layerInfo.name, layerInfo.calories)); - } - - private List getAllToppingEntities() { - CakeToppingDao bean = context.getBean(CakeToppingDao.class); - List result = new ArrayList<>(); - Iterator iterator = bean.findAll().iterator(); - while (iterator.hasNext()) { - result.add(iterator.next()); - } - return result; - } - - @Override - public List getAllToppings() { - CakeToppingDao bean = context.getBean(CakeToppingDao.class); - List result = new ArrayList<>(); - Iterator iterator = bean.findAll().iterator(); - while (iterator.hasNext()) { - CakeTopping next = iterator.next(); - result.add(new CakeToppingInfo(next.getId(), next.getName(), next.getCalories())); - } - return result; - } - - private List getAllLayerEntities() { - CakeLayerDao bean = context.getBean(CakeLayerDao.class); - List result = new ArrayList<>(); - Iterator iterator = bean.findAll().iterator(); - while (iterator.hasNext()) { - result.add(iterator.next()); - } - return result; - } - - @Override - public List getAllLayers() { - CakeLayerDao bean = context.getBean(CakeLayerDao.class); - List result = new ArrayList<>(); - Iterator iterator = bean.findAll().iterator(); - while (iterator.hasNext()) { - CakeLayer next = iterator.next(); - result.add(new CakeLayerInfo(next.getId(), next.getName(), next.getCalories())); - } - return result; - } -} diff --git a/layers/src/main/java/com/iluwatar/layers/CakeDao.java b/layers/src/main/java/com/iluwatar/layers/CakeDao.java deleted file mode 100644 index eb9e2fdaa..000000000 --- a/layers/src/main/java/com/iluwatar/layers/CakeDao.java +++ /dev/null @@ -1,9 +0,0 @@ -package com.iluwatar.layers; - -import org.springframework.data.repository.CrudRepository; -import org.springframework.stereotype.Repository; - -@Repository -public interface CakeDao extends CrudRepository { - -} diff --git a/layers/src/main/java/com/iluwatar/layers/CakeInfo.java b/layers/src/main/java/com/iluwatar/layers/CakeInfo.java deleted file mode 100644 index f5be954a7..000000000 --- a/layers/src/main/java/com/iluwatar/layers/CakeInfo.java +++ /dev/null @@ -1,23 +0,0 @@ -package com.iluwatar.layers; - -import java.util.List; -import java.util.Optional; - -public class CakeInfo { - - public final Optional id; - public final CakeToppingInfo cakeToppingInfo; - public final List cakeLayerInfos; - - public CakeInfo(Long id, CakeToppingInfo cakeToppingInfo, List cakeLayerInfos) { - this.id = Optional.of(id); - this.cakeToppingInfo = cakeToppingInfo; - this.cakeLayerInfos = cakeLayerInfos; - } - - public CakeInfo(CakeToppingInfo cakeToppingInfo, List cakeLayerInfos) { - this.id = Optional.empty(); - this.cakeToppingInfo = cakeToppingInfo; - this.cakeLayerInfos = cakeLayerInfos; - } -} diff --git a/layers/src/main/java/com/iluwatar/layers/CakeLayer.java b/layers/src/main/java/com/iluwatar/layers/CakeLayer.java deleted file mode 100644 index 00101a379..000000000 --- a/layers/src/main/java/com/iluwatar/layers/CakeLayer.java +++ /dev/null @@ -1,67 +0,0 @@ -package com.iluwatar.layers; - -import javax.persistence.CascadeType; -import javax.persistence.Entity; -import javax.persistence.GeneratedValue; -import javax.persistence.Id; -import javax.persistence.ManyToOne; - -@Entity -public class CakeLayer { - - @Id - @GeneratedValue - private Long id; - - private String name; - - private int calories; - - @ManyToOne(cascade = CascadeType.ALL) - private Cake cake; - - public CakeLayer() { - } - - public CakeLayer(String name, int calories) { - this.setName(name); - this.setCalories(calories); - } - - public Long getId() { - return id; - } - - public void setId(Long id) { - this.id = id; - } - - public String getName() { - return name; - } - - public void setName(String name) { - this.name = name; - } - - public int getCalories() { - return calories; - } - - public void setCalories(int calories) { - this.calories = calories; - } - - @Override - public String toString() { - return String.format("name: %s calories: %d", name, calories); - } - - public Cake getCake() { - return cake; - } - - public void setCake(Cake cake) { - this.cake = cake; - } -} diff --git a/layers/src/main/java/com/iluwatar/layers/CakeLayerDao.java b/layers/src/main/java/com/iluwatar/layers/CakeLayerDao.java deleted file mode 100644 index c46aafaeb..000000000 --- a/layers/src/main/java/com/iluwatar/layers/CakeLayerDao.java +++ /dev/null @@ -1,9 +0,0 @@ -package com.iluwatar.layers; - -import org.springframework.data.repository.CrudRepository; -import org.springframework.stereotype.Repository; - -@Repository -public interface CakeLayerDao extends CrudRepository { - -} diff --git a/layers/src/main/java/com/iluwatar/layers/CakeLayerInfo.java b/layers/src/main/java/com/iluwatar/layers/CakeLayerInfo.java deleted file mode 100644 index 6b59ebb06..000000000 --- a/layers/src/main/java/com/iluwatar/layers/CakeLayerInfo.java +++ /dev/null @@ -1,27 +0,0 @@ -package com.iluwatar.layers; - -import java.util.Optional; - -public class CakeLayerInfo { - - public final Optional id; - public final String name; - public final int calories; - - public CakeLayerInfo(Long id, String name, int calories) { - this.id = Optional.of(id); - this.name = name; - this.calories = calories; - } - - public CakeLayerInfo(String name, int calories) { - this.id = Optional.empty(); - this.name = name; - this.calories = calories; - } - - @Override - public String toString() { - return String.format("CakeLayerInfo name: %s calories: %d", name, calories); - } -} diff --git a/layers/src/main/java/com/iluwatar/layers/CakeTopping.java b/layers/src/main/java/com/iluwatar/layers/CakeTopping.java deleted file mode 100644 index 5aa861979..000000000 --- a/layers/src/main/java/com/iluwatar/layers/CakeTopping.java +++ /dev/null @@ -1,67 +0,0 @@ -package com.iluwatar.layers; - -import javax.persistence.CascadeType; -import javax.persistence.Entity; -import javax.persistence.GeneratedValue; -import javax.persistence.Id; -import javax.persistence.OneToOne; - -@Entity -public class CakeTopping { - - @Id - @GeneratedValue - private Long id; - - private String name; - - private int calories; - - @OneToOne(cascade = CascadeType.ALL) - private Cake cake; - - public CakeTopping() { - } - - public CakeTopping(String name, int calories) { - this.setName(name); - this.setCalories(calories); - } - - public Long getId() { - return id; - } - - public void setId(Long id) { - this.id = id; - } - - public String getName() { - return name; - } - - public void setName(String name) { - this.name = name; - } - - public int getCalories() { - return calories; - } - - public void setCalories(int calories) { - this.calories = calories; - } - - @Override - public String toString() { - return String.format("name: %s calories: %d", name, calories); - } - - public Cake getCake() { - return cake; - } - - public void setCake(Cake cake) { - this.cake = cake; - } -} diff --git a/layers/src/main/java/com/iluwatar/layers/CakeToppingDao.java b/layers/src/main/java/com/iluwatar/layers/CakeToppingDao.java deleted file mode 100644 index 81f371750..000000000 --- a/layers/src/main/java/com/iluwatar/layers/CakeToppingDao.java +++ /dev/null @@ -1,9 +0,0 @@ -package com.iluwatar.layers; - -import org.springframework.data.repository.CrudRepository; -import org.springframework.stereotype.Repository; - -@Repository -public interface CakeToppingDao extends CrudRepository { - -} diff --git a/layers/src/main/java/com/iluwatar/layers/CakeToppingInfo.java b/layers/src/main/java/com/iluwatar/layers/CakeToppingInfo.java deleted file mode 100644 index 829862b3d..000000000 --- a/layers/src/main/java/com/iluwatar/layers/CakeToppingInfo.java +++ /dev/null @@ -1,27 +0,0 @@ -package com.iluwatar.layers; - -import java.util.Optional; - -public class CakeToppingInfo { - - public final Optional id; - public final String name; - public final int calories; - - public CakeToppingInfo(Long id, String name, int calories) { - this.id = Optional.of(id); - this.name = name; - this.calories = calories; - } - - public CakeToppingInfo(String name, int calories) { - this.id = Optional.empty(); - this.name = name; - this.calories = calories; - } - - @Override - public String toString() { - return String.format("CakeToppingInfo name: %s calories: %d", name, calories); - } -} diff --git a/layers/src/main/resources/META-INF/persistence.xml b/layers/src/main/resources/META-INF/persistence.xml deleted file mode 100644 index 0aded0dbd..000000000 --- a/layers/src/main/resources/META-INF/persistence.xml +++ /dev/null @@ -1,8 +0,0 @@ - - - - - - diff --git a/layers/src/main/resources/applicationContext.xml b/layers/src/main/resources/applicationContext.xml deleted file mode 100644 index 3de47a215..000000000 --- a/layers/src/main/resources/applicationContext.xml +++ /dev/null @@ -1,42 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/layers/src/test/java/com/iluwatar/layers/AppTest.java b/layers/src/test/java/com/iluwatar/layers/AppTest.java deleted file mode 100644 index 22c35267a..000000000 --- a/layers/src/test/java/com/iluwatar/layers/AppTest.java +++ /dev/null @@ -1,12 +0,0 @@ -package com.iluwatar.layers; - -import org.junit.Test; - -public class AppTest { - - @Test - public void test() { - String[] args = {}; - App.main(args); - } -} diff --git a/pom.xml b/pom.xml index 1296fc3d5..1059edc58 100644 --- a/pom.xml +++ b/pom.xml @@ -74,7 +74,6 @@ business-delegate half-sync-half-async step-builder - layers From fbb12b53ba66ee62d561accb5e7a2b4e792a0112 Mon Sep 17 00:00:00 2001 From: Markus Date: Thu, 13 Aug 2015 23:54:40 +0200 Subject: [PATCH 2/3] Work towards #56: Splitting up the README I did the job and splitted up the readme, hopefully everything was splitted correctly... --- README.md | 760 +----------------- abstract-factory/index.md | 25 + adapter/index.md | 23 + async-method-invocation/index.md | 26 + bridge/index.md | 21 + builder/index.md | 23 + business-delegate/index.md | 20 + callback/index.md | 21 + chain-of-responsibility/index.md | 24 + command/index.md | 31 + composite/index.md | 23 + dao/index.md | 17 + decorator/index.md | 19 + dependency-injection/index.md | 21 + double-checked-locking/index.md | 19 + double-dispatch/index.md | 20 + event-aggregator/index.md | 24 + execute-around/index.md | 18 + facade/index.md | 18 + factory-method/index.md | 19 + flux/index.md | 18 + flyweight/index.md | 25 + front-controller/index.md | 23 + half-sync-half-async/index.md | 27 + idioms/index.md | 24 + intercepting-filter/index.md | 18 + interpreter/index.md | 19 + introduction/index.md | 18 + iterator/index.md | 22 + lazy-loading/index.md | 22 + mediator/index.md | 19 + memento/index.md | 21 + model-view-controller/index.md | 18 + model-view-presenter/index.md | 17 + multiton/index.md | 16 + naked-objects/index.md | 23 + null-object/index.md | 22 + object-pool/index.md | 19 + observer/index.md | 27 + poison-pill/index.md | 20 + private-class-data/index.md | 17 + property/index.md | 20 + prototype/index.md | 22 + proxy/index.md | 33 + repository/index.md | 26 + .../index.md | 15 + servant/index.md | 17 + service-layer/index.md | 21 + service-locator/index.md | 27 + singleton/index.md | 27 + specification/index.md | 19 + state/index.md | 17 + step-builder/index.md | 14 + strategy/index.md | 20 + template-method/index.md | 19 + thread-pool/index.md | 19 + tolerant-reader/index.md | 18 + visitor/index.md | 23 + 58 files changed, 1205 insertions(+), 759 deletions(-) create mode 100644 abstract-factory/index.md create mode 100644 adapter/index.md create mode 100644 async-method-invocation/index.md create mode 100644 bridge/index.md create mode 100644 builder/index.md create mode 100644 business-delegate/index.md create mode 100644 callback/index.md create mode 100644 chain-of-responsibility/index.md create mode 100644 command/index.md create mode 100644 composite/index.md create mode 100644 dao/index.md create mode 100644 decorator/index.md create mode 100644 dependency-injection/index.md create mode 100644 double-checked-locking/index.md create mode 100644 double-dispatch/index.md create mode 100644 event-aggregator/index.md create mode 100644 execute-around/index.md create mode 100644 facade/index.md create mode 100644 factory-method/index.md create mode 100644 flux/index.md create mode 100644 flyweight/index.md create mode 100644 front-controller/index.md create mode 100644 half-sync-half-async/index.md create mode 100644 idioms/index.md create mode 100644 intercepting-filter/index.md create mode 100644 interpreter/index.md create mode 100644 introduction/index.md create mode 100644 iterator/index.md create mode 100644 lazy-loading/index.md create mode 100644 mediator/index.md create mode 100644 memento/index.md create mode 100644 model-view-controller/index.md create mode 100644 model-view-presenter/index.md create mode 100644 multiton/index.md create mode 100644 naked-objects/index.md create mode 100644 null-object/index.md create mode 100644 object-pool/index.md create mode 100644 observer/index.md create mode 100644 poison-pill/index.md create mode 100644 private-class-data/index.md create mode 100644 property/index.md create mode 100644 prototype/index.md create mode 100644 proxy/index.md create mode 100644 repository/index.md create mode 100644 resource-acquisition-is-initialization/index.md create mode 100644 servant/index.md create mode 100644 service-layer/index.md create mode 100644 service-locator/index.md create mode 100644 singleton/index.md create mode 100644 specification/index.md create mode 100644 state/index.md create mode 100644 step-builder/index.md create mode 100644 strategy/index.md create mode 100644 template-method/index.md create mode 100644 thread-pool/index.md create mode 100644 tolerant-reader/index.md create mode 100644 visitor/index.md diff --git a/README.md b/README.md index dc43a2dc5..a1561b483 100644 --- a/README.md +++ b/README.md @@ -152,764 +152,6 @@ something small while the patterns are larger. * [Resource Acquisition Is Initialization](#resource-acquisition-is-initialization) * [Private Class Data](#private-class-data) -## Abstract Factory [↑](#list-of-design-patterns) -**Intent:** Provide an interface for creating families of related or dependent -objects without specifying their concrete classes. - -![alt text](./abstract-factory/etc/abstract-factory_1.png "Abstract Factory") - -**Applicability:** Use the Abstract Factory pattern when -* a system should be independent of how its products are created, composed and represented -* a system should be configured with one of multiple families of products -* a family of related product objects is designed to be used together, and you need to enforce this constraint -* you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations - -**Real world examples:** -* [javax.xml.parsers.DocumentBuilderFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/parsers/DocumentBuilderFactory.html) - -## Builder [↑](#list-of-design-patterns) -**Intent:** Separate the construction of a complex object from its -representation so that the same construction process can create different -representations. - -![alt text](./builder/etc/builder_1.png "Builder") - -**Applicability:** Use the Builder pattern when -* the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled -* the construction process must allow different representations for the object that's constructed - -**Real world examples:** -* [java.lang.StringBuilder](http://docs.oracle.com/javase/8/docs/api/java/lang/StringBuilder.html) -* [Apache Camel builders](https://github.com/apache/camel/tree/0e195428ee04531be27a0b659005e3aa8d159d23/camel-core/src/main/java/org/apache/camel/builder) - -## Factory Method [↑](#list-of-design-patterns) -**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. - -![alt text](./factory-method/etc/factory-method_1.png "Factory Method") - -**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 - -## Prototype [↑](#list-of-design-patterns) -**Intent:** Specify the kinds of objects to create using a prototypical -instance, and create new objects by copying this prototype. - -![alt text](./prototype/etc/prototype_1.png "Prototype") - -**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:** -* [java.lang.Object#clone()](http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#clone%28%29) - -## Singleton [↑](#list-of-design-patterns) -**Intent:** Ensure a class only has one instance, and provide a global point of -access to it. - -![alt text](./singleton/etc/singleton_1.png "Singleton") - -**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:** -* the logging class -* managing a connection to a database -* file manager - -**Real world examples:** -* [java.lang.Runtime#getRuntime()](http://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#getRuntime%28%29) - -## Step Builder [↑](#list-of-design-patterns) -**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. - -![alt text](./step-builder/etc/step-builder.png "Step Builder") - -**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. - -## Adapter [↑](#list-of-design-patterns) -**Intent:** Convert the interface of a class into another interface the clients -expect. Adapter lets classes work together that couldn't otherwise because of -incompatible interfaces. - -![alt text](./adapter/etc/adapter_1.png "Adapter") - -**Applicability:** Use the Adapter pattern when -* you want to use an existing class, and its interface does not match the one you need -* you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces -* you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class. - -**Real world examples:** -* [java.util.Arrays#asList()](http://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#asList%28T...%29) - -## Bridge [↑](#list-of-design-patterns) -**Intent:** Decouple an abstraction from its implementation so that the two can -vary independently. - - -![alt text](./bridge/etc/bridge_1.png "Bridge") - -**Applicability:** Use the Bridge pattern when -* you want to avoid a permanent binding between an abstraction and its implementation. This might be the case, for example, when the implementation must be selected or switched at run-time. -* both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently -* changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled. -* you have a proliferation of classes. Such a class hierarchy indicates the need for splitting an object into two parts. Rumbaugh uses the term "nested generalizations" to refer to such class hierarchies -* you want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be hidden from the client. A simple example is Coplien's String class, in which multiple objects can share the same string representation. - -## Composite [↑](#list-of-design-patterns) -**Intent:** Compose objects into tree structures to represent part-whole -hierarchies. Composite lets clients treat individual objects and compositions -of objects uniformly. - -![alt text](./composite/etc/composite_1.png "Composite") - -**Applicability:** Use the Composite pattern when -* you want to represent part-whole hierarchies of objects -* you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly - -**Real world examples:** -* [java.awt.Container](http://docs.oracle.com/javase/8/docs/api/java/awt/Container.html) and [java.awt.Component](http://docs.oracle.com/javase/8/docs/api/java/awt/Component.html) -* [Apache Wicket](https://github.com/apache/wicket) component tree, see [Component](https://github.com/apache/wicket/blob/91e154702ab1ff3481ef6cbb04c6044814b7e130/wicket-core/src/main/java/org/apache/wicket/Component.java) and [MarkupContainer](https://github.com/apache/wicket/blob/b60ec64d0b50a611a9549809c9ab216f0ffa3ae3/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java) - -## Decorator [↑](#list-of-design-patterns) -**Intent:** Attach additional responsibilities to an object dynamically. -Decorators provide a flexible alternative to subclassing for extending -functionality. - -![alt text](./decorator/etc/decorator_1.png "Decorator") - -**Applicability:** Use Decorator -* to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects -* for responsibilities that can be withdrawn -* when extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination. Or a class definition may be hidden or otherwise unavailable for subclassing - -## Facade [↑](#list-of-design-patterns) -**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. - -![alt text](./facade/etc/facade_1.png "Facade") - -**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 - -## Flyweight [↑](#list-of-design-patterns) -**Intent:** Use sharing to support large numbers of fine-grained objects -efficiently. - -![alt text](./flyweight/etc/flyweight_1.png "Flyweight") - -**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 -* an application uses a large number of objects -* storage costs are high because of the sheer quantity of objects -* most object state can be made extrinsic -* 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:** -* [java.lang.Integer#valueOf(int)](http://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#valueOf%28int%29) - -## Proxy [↑](#list-of-design-patterns) -**Intent:** Provide a surrogate or placeholder for another object to control -access to it. - -![alt text](./proxy/etc/proxy_1.png "Proxy") - -**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 - -* a remote proxy provides a local representative for an object in a different address space. -* 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:** - -* control access to another object -* lazy initialization -* implement logging -* facilitate network connection -* to count references to an object - -**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/) - -## Service Locator [↑](#list-of-design-patterns) -**Intent:** Encapsulate the processes involved in obtaining a service with a -strong abstraction layer. - -![alt text](./service-locator/etc/service-locator.png "Proxy") - -**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 -particular service is requested, the service Locator looks up in JNDI, fetched -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:** - -* when network hits are expensive and time consuming -* lookups of services are done quite frequently -* large number of services are being used - -## Chain of responsibility [↑](#list-of-design-patterns) -**Intent:** Avoid coupling the sender of a request to its receiver by giving -more than one object a chance to handle the request. Chain the receiving -objects and pass the request along the chain until an object handles it. - -![alt text](./chain/etc/chain_1.png "Chain of Responsibility") - -**Applicability:** Use Chain of Responsibility when -* more than one object may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically -* you want to issue a request to one of several objects without specifying the receiver explicitly -* the set of objects that can handle a request should be specified dynamically - -**Real world examples:** -* [java.util.logging.Logger#log()](http://docs.oracle.com/javase/8/docs/api/java/util/logging/Logger.html#log%28java.util.logging.Level,%20java.lang.String%29) -* [Apache Commons Chain](https://commons.apache.org/proper/commons-chain/index.html) - -## Command [↑](#list-of-design-patterns) -**Intent:** Encapsulate a request as an object, thereby letting you -parameterize clients with different requests, queue or log requests, and -support undoable operations. - -![alt text](./command/etc/command.png "Command") - -**Applicability:** Use the Command pattern when you want to - -* parameterize objects by an action to perform. You can express such parameterization in a procedural language with a callback function, that is, a function that's registered somewhere to be called at a later point. Commands are an object-oriented replacement for callbacks. -* specify, queue, and execute requests at different times. A Command object can have a lifetime independent of the original request. If the receiver of a request can be represented in an address space-independent way, then you can transfer a command object for the request to a different process and fulfill the request there -* support undo. The Command's execute operation can store state for reversing its effects in the command itself. The Command interface must have an added Unexecute operation that reverses the effects of a previous call to execute. Executed commands are stored in a history list. Unlimited-level undo and redo is achieved by traversing this list backwards and forwards calling unexecute and execute, respectively -* support logging changes so that they can be reapplied in case of a system crash. By augmenting the Command interface with load and store operations, you can keep a persistent log of changes. Recovering from a crash involves reloading logged commands from disk and re-executing them with the execute operation -* structure a system around high-level operations build on primitive operations. Such a structure is common in information systems that support transactions. A transaction encapsulates a set of changes to data. The Command pattern offers a way to model transactions. Commands have a common interface, letting you invoke all transactions the same way. The pattern also makes it easy to extend the system with new transactions - -**Typical Use Case:** - -* to keep a history of requests -* implement callback functionality -* implement the undo functionality - -**Real world examples:** -* [java.lang.Runnable](http://docs.oracle.com/javase/8/docs/api/java/lang/Runnable.html) - -## Interpreter [↑](#list-of-design-patterns) -**Intent:** Given a language, define a representation for its grammar along -with an interpreter that uses the representation to interpret sentences in the -language. - -![alt text](./interpreter/etc/interpreter_1.png "Interpreter") - -**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 - -## Iterator [↑](#list-of-design-patterns) -**Intent:** Provide a way to access the elements of an aggregate object -sequentially without exposing its underlying representation. - -![alt text](./iterator/etc/iterator_1.png "Iterator") - -**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:** -* [java.util.Iterator](http://docs.oracle.com/javase/8/docs/api/java/util/Iterator.html) - -## Mediator [↑](#list-of-design-patterns) -**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. - -![alt text](./mediator/etc/mediator_1.png "Mediator") - -**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 - -## Memento [↑](#list-of-design-patterns) -**Intent:** Without violating encapsulation, capture and externalize an -object's internal state so that the object can be restored to this state later. - -![alt text](./memento/etc/memento.png "Memento") - -**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:** -* [java.util.Date](http://docs.oracle.com/javase/8/docs/api/java/util/Date.html) - -## Observer [↑](#list-of-design-patterns) -**Intent:** Define a one-to-many dependency between objects so that when one -object changes state, all its dependents are notified and updated -automatically. - -![alt text](./observer/etc/observer_1.png "Observer") - -**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:** - -* changing in one object leads to a change in other objects - -**Real world examples:** -* [java.util.Observer](http://docs.oracle.com/javase/8/docs/api/java/util/Observer.html) - -## State [↑](#list-of-design-patterns) -**Intent:** Allow an object to alter its behavior when its internal state -changes. The object will appear to change its class. - -![alt text](./state/etc/state_1.png "State") - -**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. - -## Strategy [↑](#list-of-design-patterns) -**Intent:** Define a family of algorithms, encapsulate each one, and make them -interchangeable. Strategy lets the algorithm vary independently from clients -that use it. - -![alt text](./strategy/etc/strategy_1.png "Strategy") - -**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 - -## Template method [↑](#list-of-design-patterns) -**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. - -![alt text](./template-method/etc/template-method_1.png "Template Method") - -**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 - -## Visitor [↑](#list-of-design-patterns) -**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. - -![alt text](./visitor/etc/visitor_1.png "Visitor") - -**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:** -* [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) - -## Model-View-Presenter [↑](#list-of-design-patterns) -**Intent:** Apply a "Separation of Concerns" principle in a way that allows -developers to build and test user interfaces. - -![alt text](./model-view-presenter/etc/model-view-presenter_1.png "Model-View-Presenter") - -**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. - -## Data Access Object [↑](#list-of-design-patterns) -**Intent:** Object provides an abstract interface to some type of database or -other persistence mechanism. - -![alt text](./dao/etc/dao.png "Data Access Object") - -**Applicability:** Use the Data Access Object in any of the following situations -* when you want to consolidate how the data layer is accessed -* when you want to avoid writing multiple data retrieval/persistence layers - -## Double Checked Locking [↑](#list-of-design-patterns) -**Intent:** Reduce the overhead of acquiring a lock by first testing the -locking criterion (the "lock hint") without actually acquiring the lock. Only -if the locking criterion check indicates that locking is required does the -actual locking logic proceed. - -![alt text](./double-checked-locking/etc/double_checked_locking_1.png "Double Checked Locking") - -**Applicability:** Use the Double Checked Locking pattern when -* there is a concurrent access in object creation, e.g. singleton, where you want to create single instance of the same class and checking if it's null or not maybe not be enough when there are two or more threads that checks if instance is null or not. -* there is a concurrent access on a method where method's behaviour changes according to the some constraints and these constraint change within this method. - -## Servant [↑](#list-of-design-patterns) -**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. - -![alt text](./servant/etc/servant-pattern.png "Servant") - -**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. - -## Null Object [↑](#list-of-design-patterns) -**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 -object (for instance, a non-existent customer), one uses an object which -implements the expected interface, but whose method body is empty. The -advantage of this approach over a working default implementation is that a Null -Object is very predictable and has no side effects: it does nothing. - -![alt text](./null-object/etc/null-object.png "Null Object") - -**Applicability:** Use the Null Object pattern when -* you want to avoid explicit null checks and keep the algorithm elegant and easy to read. - -## Event Aggregator [↑](#list-of-design-patterns) -**Intent:** A system with lots of objects can lead to complexities when a -client wants to subscribe to events. The client has to find and register for -each object individually, if each object has multiple events then each event -requires a separate subscription. An Event Aggregator acts as a single source -of events for many objects. It registers for all the events of the many objects -allowing clients to register with just the aggregator. - -![alt text](./event-aggregator/etc/classes.png "Event Aggregator") - -**Applicability:** Use the Event Aggregator pattern when -* Event Aggregator is a good choice when you have lots of objects that are - potential event sources. Rather than have the observer deal with registering - with them all, you can centralize the registration logic to the Event - Aggregator. As well as simplifying registration, a Event Aggregator also - simplifies the memory management issues in using observers. - -## Callback [↑](#list-of-design-patterns) -**Intent:** Callback is a piece of executable code that is passed as an -argument to other code, which is expected to call back (execute) the argument -at some convenient time. - -![alt text](./callback/etc/callback.png "Callback") - -**Applicability:** Use the Callback pattern when -* when some arbitrary synchronous or asynchronous action must be performed after execution of some defined activity. - -**Real world examples:** -* [CyclicBarrier] (http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/CyclicBarrier.html#CyclicBarrier%28int,%20java.lang.Runnable%29) constructor can accept callback that will be triggered every time when barrier is tripped. - -## Intercepting Filter [↑](#list-of-design-patterns) -**Intent:** Provide pluggable filters to conduct necessary pre-processing and -post-processing to requests from a client to a target - -![alt text](./intercepting-filter/etc/intercepting-filter.png "Intercepting Filter") - -**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 - -## Execute Around [↑](#list-of-design-patterns) -**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. - -![alt text](./execute-around/etc/execute-around.png "Execute Around") - -**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. - -## Property [↑](#list-of-design-patterns) -**Intent:** Create hierarchy of objects and new objects using already existing -objects as parents. - -![alt text](./property/etc/property.png "Property") - -**Applicability:** Use the Property pattern when -* when you like to have objects with dynamic set of fields and prototype inheritance - -**Real world examples:** -* [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain) prototype inheritance - -## Poison Pill [↑](#list-of-design-patterns) -**Intent:** Poison Pill is known predefined data item that allows to provide -graceful shutdown for separate distributed consumption process. - -![alt text](./poison-pill/etc/poison-pill.png "Poison Pill") - -**Applicability:** Use the Poison Pill idiom when -* need to send signal from one thread/process to another to terminate - -**Real world examples:** -* [akka.actor.PoisonPill](http://doc.akka.io/docs/akka/2.1.4/java/untyped-actors.html) - -## Lazy Loading [↑](#list-of-design-patterns) -**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. - -![alt text](./lazy-loading/etc/lazy-loading.png "Lazy Loading") - -**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:** -* JPA annotations @OneToOne, @OneToMany, @ManyToOne, @ManyToMany and fetch = FetchType.LAZY - -## Service Layer [↑](#list-of-design-patterns) -**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 -interactions with the application to access and manipulate its data and invoke -its business logic. The Service Layer fulfills this role. - -![alt text](./service-layer/etc/service-layer.png "Service Layer") - -**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 - -## Specification [↑](#list-of-design-patterns) -**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 - -![alt text](./specification/etc/specification.png "Specification") - -**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) - -## Tolerant Reader [↑](#list-of-design-patterns) -**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. - -![alt text](./tolerant-reader/etc/tolerant-reader.png "Tolerant Reader") - -**Applicability:** Use the Tolerant Reader pattern when -* the communication schema can evolve and change and yet the receiving side should not break - -## Model-View-Controller [↑](#list-of-design-patterns) -**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. - -![alt text](./model-view-controller/etc/model-view-controller.png "Model-View-Controller") - -**Applicability:** Use the Model-View-Controller pattern when -* you want to clearly separate the domain data from its user interface representation - -## Flux [↑](#list-of-design-patterns) -**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. - -![alt text](./flux/etc/flux.png "Flux") - -**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. - -## Double Dispatch [↑](#list-of-design-patterns) -**Intent:** Double Dispatch pattern is a way to create maintainable dynamic -behavior based on receiver and parameter types. - -![alt text](./double-dispatch/etc/double-dispatch.png "Double Dispatch") - -**Applicability:** Use the Double Dispatch pattern when -* the dynamic behavior is not defined only based on receiving object's type but also on the receiving method's parameter type. - -**Real world examples:** -* [ObjectOutputStream](https://docs.oracle.com/javase/8/docs/api/java/io/ObjectOutputStream.html) - -## Multiton [↑](#list-of-design-patterns) -**Intent:** Ensure a class only has limited number of instances, and provide a -global point of access to them. - -![alt text](./multiton/etc/multiton.png "Multiton") - -**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 - -## Resource Acquisition Is Initialization [↑](#list-of-design-patterns) -**Intent:** Resource Acquisition Is Initialization pattern can be used to implement exception safe resource management. - -![alt text](./resource-acquisition-is-initialization/etc/resource-acquisition-is-initialization.png "Resource Acquisition Is Initialization") - -**Applicability:** Use the Resource Acquisition Is Initialization pattern when -* you have resources that must be closed in every condition - -## Thread Pool [↑](#list-of-design-patterns) -**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 -and eliminating the latency of creating new threads. - -![alt text](./thread-pool/etc/thread-pool.png "Thread Pool") - -**Applicability:** Use the Thread Pool pattern when -* you have a large number of short-lived tasks to be executed in parallel - -## Async Method Invocation [↑](#list-of-design-patterns) -**Intent:** Asynchronous method invocation is pattern where the calling thread -is not blocked while waiting results of tasks. The pattern provides parallel -processing of multiple independent tasks and retrieving the results via -callbacks or waiting until everything is done. - -![alt text](./async-method-invocation/etc/async-method-invocation.png "Async Method Invocation") - -**Applicability:** Use async method invocation pattern when -* you have multiple independent tasks that can run in parallel -* you need to improve the performance of a group of sequential tasks -* you have limited amount of processing capacity or long running tasks and the - caller should not wait the tasks to be ready - -**Real world examples:** -* [FutureTask](http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/FutureTask.html), [CompletableFuture](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html) and [ExecutorService](http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html) (Java) -* [Task-based Asynchronous Pattern](https://msdn.microsoft.com/en-us/library/hh873175.aspx) (.NET) - -## Private Class Data [↑](#list-of-design-patterns) -**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. - -![alt text](./private-class-data/etc/private-class-data.png "Private Class Data") - -**Applicability:** Use the Private Class Data pattern when -* you want to prevent write access to class data members - -## Object Pool [↑](#list-of-design-patterns) -**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. - -![alt text](./object-pool/etc/object-pool.png "Object Pool") - -**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) - -## Dependency Injection [↑](#list-of-design-patterns) -**Intent:** Dependency Injection is a software design pattern in which one or -more dependencies (or services) are injected, or passed by reference, into a -dependent object (or client) and are made part of the client's state. The -pattern separates the creation of a client's dependencies from its own -behavior, which allows program designs to be loosely coupled and to follow the -inversion of control and single responsibility principles. - -![alt text](./dependency-injection/etc/dependency-injection.png "Dependency Injection") - -**Applicability:** Use the Dependency Injection pattern when -* when you need to remove knowledge of concrete implementation from object -* to enable unit testing of classes in isolation using mock objects or stubs - -## Naked Objects [↑](#list-of-design-patterns) -**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. - -![alt text](./naked-objects/etc/naked-objects.png "Naked Objects") - -**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:** -* [Apache Isis](https://isis.apache.org/) - -## Front Controller [↑](#list-of-design-patterns) -**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. - -![alt text](./front-controller/etc/front-controller.png "Front Controller") - -**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:** -* [Apache Struts](https://struts.apache.org/) - -## Repository [↑](#list-of-design-patterns) -**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 -querying is utilized. - -![alt text](./repository/etc/repository.png "Repository") - -**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:** -* [Spring Data](http://projects.spring.io/spring-data/) - -## Business Delegate [↑](#list-of-design-patterns) -**Intent:** The Business Delegate pattern adds an abstraction layer between -presentation and business tiers. By using the pattern we gain loose coupling -between the tiers and encapsulate knowledge about how to locate, connect to, -and interact with the business objects that make up the application. - -![alt text](./business-delegate/etc/business-delegate.png "Business Delegate") - -**Applicability:** Use the Business Delegate pattern when -* you want loose coupling between presentation and business tiers -* you want to orchestrate calls to multiple business services -* you want to encapsulate service lookups and service calls - -## Half-Sync/Half-Async [↑](#list-of-design-patterns) -**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. - -![Half-Sync/Half-Async class diagram](./half-sync-half-async/etc/half-sync-half-async.png) - -**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 - * it is inefficient to dedicate separate thread of control to perform synchronous I/O for each external source of event - * the higher level tasks in the system can be simplified significantly if I/O is performed synchronously. -* one or more tasks in a system must run in a single thread of control, while other tasks may benefit from multi-threading. - -**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) - # Frequently asked questions [↑](#top) **Q: What is the difference between State and Strategy patterns?** @@ -1021,7 +263,7 @@ other words, version numbers are used only for project planning sake. * [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612) * [Effective Java (2nd Edition)](http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683) * [Java Generics and Collections](http://www.amazon.com/Java-Generics-Collections-Maurice-Naftalin/dp/0596527756/) -* [Let’s Modify the Objects-First Approach into Design-Patterns-First](http://edu.pecinovsky.cz/papers/2006_ITiCSE_Design_Patterns_First.pdf) +* [Let's Modify the Objects-First Approach into Design-Patterns-First](http://edu.pecinovsky.cz/papers/2006_ITiCSE_Design_Patterns_First.pdf) * [Pattern Languages of Program Design](http://www.amazon.com/Pattern-Languages-Program-Design-Coplien/dp/0201607344/ref=sr_1_1) * [Martin Fowler - Event Aggregator](http://martinfowler.com/eaaDev/EventAggregator.html) * [TutorialsPoint - Intercepting Filter](http://www.tutorialspoint.com/design_pattern/intercepting_filter_pattern.htm) diff --git a/abstract-factory/index.md b/abstract-factory/index.md new file mode 100644 index 000000000..ae053b2a2 --- /dev/null +++ b/abstract-factory/index.md @@ -0,0 +1,25 @@ +--- +layout: pattern +title: Abstract Factory +folder: abstract-factory +categories: + - pattern_cat + - creational +tags: pattern_tag +--- + +**Intent:** Provide an interface for creating families of related or dependent +objects without specifying their concrete classes. + +![alt text](./etc/abstract-factory_1.png "Abstract Factory") + +**Applicability:** Use the Abstract Factory pattern when + +* a system should be independent of how its products are created, composed and represented +* a system should be configured with one of multiple families of products +* a family of related product objects is designed to be used together, and you need to enforce this constraint +* you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations + +**Real world examples:** + +* [javax.xml.parsers.DocumentBuilderFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/parsers/DocumentBuilderFactory.html) \ No newline at end of file diff --git a/adapter/index.md b/adapter/index.md new file mode 100644 index 000000000..b8d2741cc --- /dev/null +++ b/adapter/index.md @@ -0,0 +1,23 @@ +--- +layout: pattern +title: Adapter +folder: adapter +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Convert the interface of a class into another interface the clients +expect. Adapter lets classes work together that couldn't otherwise because of +incompatible interfaces. + +![alt text](./etc/adapter_1.png "Adapter") + +**Applicability:** Use the Adapter pattern when + +* you want to use an existing class, and its interface does not match the one you need +* you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces +* you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class. + +**Real world examples:** + +* [java.util.Arrays#asList()](http://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#asList%28T...%29) \ No newline at end of file diff --git a/async-method-invocation/index.md b/async-method-invocation/index.md new file mode 100644 index 000000000..00812d310 --- /dev/null +++ b/async-method-invocation/index.md @@ -0,0 +1,26 @@ +--- +layout: pattern +title: Async Method Invocation +folder: async-method-invocation +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Asynchronous method invocation is pattern where the calling thread +is not blocked while waiting results of tasks. The pattern provides parallel +processing of multiple independent tasks and retrieving the results via +callbacks or waiting until everything is done. + +![alt text](./etc/async-method-invocation.png "Async Method Invocation") + +**Applicability:** Use async method invocation pattern when + +* you have multiple independent tasks that can run in parallel +* you need to improve the performance of a group of sequential tasks +* you have limited amount of processing capacity or long running tasks and the + caller should not wait the tasks to be ready + +**Real world examples:** + +* [FutureTask](http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/FutureTask.html), [CompletableFuture](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html) and [ExecutorService](http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html) (Java) +* [Task-based Asynchronous Pattern](https://msdn.microsoft.com/en-us/library/hh873175.aspx) (.NET) \ No newline at end of file diff --git a/bridge/index.md b/bridge/index.md new file mode 100644 index 000000000..d0a1e0ea1 --- /dev/null +++ b/bridge/index.md @@ -0,0 +1,21 @@ +--- +layout: pattern +title: Bridge +folder: bridge +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Decouple an abstraction from its implementation so that the two can +vary independently. + + +![alt text](./etc/bridge_1.png "Bridge") + +**Applicability:** Use the Bridge pattern when + +* you want to avoid a permanent binding between an abstraction and its implementation. This might be the case, for example, when the implementation must be selected or switched at run-time. +* both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently +* changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled. +* you have a proliferation of classes. Such a class hierarchy indicates the need for splitting an object into two parts. Rumbaugh uses the term "nested generalizations" to refer to such class hierarchies +* you want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be hidden from the client. A simple example is Coplien's String class, in which multiple objects can share the same string representation. \ No newline at end of file diff --git a/builder/index.md b/builder/index.md new file mode 100644 index 000000000..0a5254ce1 --- /dev/null +++ b/builder/index.md @@ -0,0 +1,23 @@ +--- +layout: pattern +title: Builder +folder: builder +categories: creational +tags: pattern_tag +--- + +**Intent:** Separate the construction of a complex object from its +representation so that the same construction process can create different +representations. + +![alt text](./etc/builder_1.png "Builder") + +**Applicability:** Use the Builder pattern when + +* the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled +* the construction process must allow different representations for the object that's constructed + +**Real world examples:** + +* [java.lang.StringBuilder](http://docs.oracle.com/javase/8/docs/api/java/lang/StringBuilder.html) +* [Apache Camel builders](https://github.com/apache/camel/tree/0e195428ee04531be27a0b659005e3aa8d159d23/camel-core/src/main/java/org/apache/camel/builder) \ No newline at end of file diff --git a/business-delegate/index.md b/business-delegate/index.md new file mode 100644 index 000000000..23c92b89e --- /dev/null +++ b/business-delegate/index.md @@ -0,0 +1,20 @@ +--- +layout: pattern +title: Business Delegate +folder: business-delegate +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** The Business Delegate pattern adds an abstraction layer between +presentation and business tiers. By using the pattern we gain loose coupling +between the tiers and encapsulate knowledge about how to locate, connect to, +and interact with the business objects that make up the application. + +![alt text](./etc/business-delegate.png "Business Delegate") + +**Applicability:** Use the Business Delegate pattern when + +* you want loose coupling between presentation and business tiers +* you want to orchestrate calls to multiple business services +* you want to encapsulate service lookups and service calls \ No newline at end of file diff --git a/callback/index.md b/callback/index.md new file mode 100644 index 000000000..b8a4f2808 --- /dev/null +++ b/callback/index.md @@ -0,0 +1,21 @@ +--- +layout: pattern +title: Callback +folder: callback +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Callback is a piece of executable code that is passed as an +argument to other code, which is expected to call back (execute) the argument +at some convenient time. + +![alt text](./etc/callback.png "Callback") + +**Applicability:** Use the Callback pattern when + +* when some arbitrary synchronous or asynchronous action must be performed after execution of some defined activity. + +**Real world examples:** + +* [CyclicBarrier] (http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/CyclicBarrier.html#CyclicBarrier%28int,%20java.lang.Runnable%29) constructor can accept callback that will be triggered every time when barrier is tripped. \ No newline at end of file diff --git a/chain-of-responsibility/index.md b/chain-of-responsibility/index.md new file mode 100644 index 000000000..234815506 --- /dev/null +++ b/chain-of-responsibility/index.md @@ -0,0 +1,24 @@ +--- +layout: pattern +title: Chain of responsibility +folder: chain-of-responsibility +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Avoid coupling the sender of a request to its receiver by giving +more than one object a chance to handle the request. Chain the receiving +objects and pass the request along the chain until an object handles it. + +![alt text](./chain/etc/chain_1.png "Chain of Responsibility") + +**Applicability:** Use Chain of Responsibility when + +* more than one object may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically +* you want to issue a request to one of several objects without specifying the receiver explicitly +* the set of objects that can handle a request should be specified dynamically + +**Real world examples:** + +* [java.util.logging.Logger#log()](http://docs.oracle.com/javase/8/docs/api/java/util/logging/Logger.html#log%28java.util.logging.Level,%20java.lang.String%29) +* [Apache Commons Chain](https://commons.apache.org/proper/commons-chain/index.html) \ No newline at end of file diff --git a/command/index.md b/command/index.md new file mode 100644 index 000000000..21422da35 --- /dev/null +++ b/command/index.md @@ -0,0 +1,31 @@ +--- +layout: pattern +title: Command +folder: command +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Encapsulate a request as an object, thereby letting you +parameterize clients with different requests, queue or log requests, and +support undoable operations. + +![alt text](./etc/command.png "Command") + +**Applicability:** Use the Command pattern when you want to + +* parameterize objects by an action to perform. You can express such parameterization in a procedural language with a callback function, that is, a function that's registered somewhere to be called at a later point. Commands are an object-oriented replacement for callbacks. +* specify, queue, and execute requests at different times. A Command object can have a lifetime independent of the original request. If the receiver of a request can be represented in an address space-independent way, then you can transfer a command object for the request to a different process and fulfill the request there +* support undo. The Command's execute operation can store state for reversing its effects in the command itself. The Command interface must have an added Unexecute operation that reverses the effects of a previous call to execute. Executed commands are stored in a history list. Unlimited-level undo and redo is achieved by traversing this list backwards and forwards calling unexecute and execute, respectively +* support logging changes so that they can be reapplied in case of a system crash. By augmenting the Command interface with load and store operations, you can keep a persistent log of changes. Recovering from a crash involves reloading logged commands from disk and re-executing them with the execute operation +* structure a system around high-level operations build on primitive operations. Such a structure is common in information systems that support transactions. A transaction encapsulates a set of changes to data. The Command pattern offers a way to model transactions. Commands have a common interface, letting you invoke all transactions the same way. The pattern also makes it easy to extend the system with new transactions + +**Typical Use Case:** + +* to keep a history of requests +* implement callback functionality +* implement the undo functionality + +**Real world examples:** + +* [java.lang.Runnable](http://docs.oracle.com/javase/8/docs/api/java/lang/Runnable.html) \ No newline at end of file diff --git a/composite/index.md b/composite/index.md new file mode 100644 index 000000000..d987aa27c --- /dev/null +++ b/composite/index.md @@ -0,0 +1,23 @@ +--- +layout: pattern +title: Composite +folder: composite +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Compose objects into tree structures to represent part-whole +hierarchies. Composite lets clients treat individual objects and compositions +of objects uniformly. + +![alt text](./etc/composite_1.png "Composite") + +**Applicability:** Use the Composite pattern when + +* you want to represent part-whole hierarchies of objects +* you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly + +**Real world examples:** + +* [java.awt.Container](http://docs.oracle.com/javase/8/docs/api/java/awt/Container.html) and [java.awt.Component](http://docs.oracle.com/javase/8/docs/api/java/awt/Component.html) +* [Apache Wicket](https://github.com/apache/wicket) component tree, see [Component](https://github.com/apache/wicket/blob/91e154702ab1ff3481ef6cbb04c6044814b7e130/wicket-core/src/main/java/org/apache/wicket/Component.java) and [MarkupContainer](https://github.com/apache/wicket/blob/b60ec64d0b50a611a9549809c9ab216f0ffa3ae3/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java) \ No newline at end of file diff --git a/dao/index.md b/dao/index.md new file mode 100644 index 000000000..3d6b10d3f --- /dev/null +++ b/dao/index.md @@ -0,0 +1,17 @@ +--- +layout: pattern +title: Data Access Object +folder: dao +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Object provides an abstract interface to some type of database or +other persistence mechanism. + +![alt text](./etc/dao.png "Data Access Object") + +**Applicability:** Use the Data Access Object in any of the following situations + +* when you want to consolidate how the data layer is accessed +* when you want to avoid writing multiple data retrieval/persistence layers \ No newline at end of file diff --git a/decorator/index.md b/decorator/index.md new file mode 100644 index 000000000..3674e5d4a --- /dev/null +++ b/decorator/index.md @@ -0,0 +1,19 @@ +--- +layout: pattern +title: Decorator +folder: decorator +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Attach additional responsibilities to an object dynamically. +Decorators provide a flexible alternative to subclassing for extending +functionality. + +![alt text](./etc/decorator_1.png "Decorator") + +**Applicability:** Use Decorator + +* to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects +* for responsibilities that can be withdrawn +* when extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination. Or a class definition may be hidden or otherwise unavailable for subclassing \ No newline at end of file diff --git a/dependency-injection/index.md b/dependency-injection/index.md new file mode 100644 index 000000000..d0b238818 --- /dev/null +++ b/dependency-injection/index.md @@ -0,0 +1,21 @@ +--- +layout: pattern +title: Dependency Injection +folder: dependency-injection +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Dependency Injection is a software design pattern in which one or +more dependencies (or services) are injected, or passed by reference, into a +dependent object (or client) and are made part of the client's state. The +pattern separates the creation of a client's dependencies from its own +behavior, which allows program designs to be loosely coupled and to follow the +inversion of control and single responsibility principles. + +![alt text](./etc/dependency-injection.png "Dependency Injection") + +**Applicability:** Use the Dependency Injection pattern when + +* when you need to remove knowledge of concrete implementation from object +* to enable unit testing of classes in isolation using mock objects or stubs \ No newline at end of file diff --git a/double-checked-locking/index.md b/double-checked-locking/index.md new file mode 100644 index 000000000..8af9e6af0 --- /dev/null +++ b/double-checked-locking/index.md @@ -0,0 +1,19 @@ +--- +layout: pattern +title: Double Checked Locking +folder: double-checked-locking +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Reduce the overhead of acquiring a lock by first testing the +locking criterion (the "lock hint") without actually acquiring the lock. Only +if the locking criterion check indicates that locking is required does the +actual locking logic proceed. + +![alt text](./etc/double_checked_locking_1.png "Double Checked Locking") + +**Applicability:** Use the Double Checked Locking pattern when + +* there is a concurrent access in object creation, e.g. singleton, where you want to create single instance of the same class and checking if it's null or not maybe not be enough when there are two or more threads that checks if instance is null or not. +* there is a concurrent access on a method where method's behaviour changes according to the some constraints and these constraint change within this method. \ No newline at end of file diff --git a/double-dispatch/index.md b/double-dispatch/index.md new file mode 100644 index 000000000..8c6586590 --- /dev/null +++ b/double-dispatch/index.md @@ -0,0 +1,20 @@ +--- +layout: pattern +title: Double Dispatch +folder: double-dispatch +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Double Dispatch pattern is a way to create maintainable dynamic +behavior based on receiver and parameter types. + +![alt text](./etc/double-dispatch.png "Double Dispatch") + +**Applicability:** Use the Double Dispatch pattern when + +* the dynamic behavior is not defined only based on receiving object's type but also on the receiving method's parameter type. + +**Real world examples:** + +* [ObjectOutputStream](https://docs.oracle.com/javase/8/docs/api/java/io/ObjectOutputStream.html) \ No newline at end of file diff --git a/event-aggregator/index.md b/event-aggregator/index.md new file mode 100644 index 000000000..a6fd9fb22 --- /dev/null +++ b/event-aggregator/index.md @@ -0,0 +1,24 @@ +--- +layout: pattern +title: Event Aggregator +folder: event-aggregator +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** A system with lots of objects can lead to complexities when a +client wants to subscribe to events. The client has to find and register for +each object individually, if each object has multiple events then each event +requires a separate subscription. An Event Aggregator acts as a single source +of events for many objects. It registers for all the events of the many objects +allowing clients to register with just the aggregator. + +![alt text](./etc/classes.png "Event Aggregator") + +**Applicability:** Use the Event Aggregator pattern when + +* Event Aggregator is a good choice when you have lots of objects that are + potential event sources. Rather than have the observer deal with registering + with them all, you can centralize the registration logic to the Event + Aggregator. As well as simplifying registration, a Event Aggregator also + simplifies the memory management issues in using observers. \ No newline at end of file diff --git a/execute-around/index.md b/execute-around/index.md new file mode 100644 index 000000000..949f424c3 --- /dev/null +++ b/execute-around/index.md @@ -0,0 +1,18 @@ +--- +layout: pattern +title: Execute Around +folder: execute-around +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/execute-around.png "Execute Around") + +**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. \ No newline at end of file diff --git a/facade/index.md b/facade/index.md new file mode 100644 index 000000000..8a9a9c1b9 --- /dev/null +++ b/facade/index.md @@ -0,0 +1,18 @@ +--- +layout: pattern +title: Facade +folder: facade +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/facade_1.png "Facade") + +**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 \ No newline at end of file diff --git a/factory-method/index.md b/factory-method/index.md new file mode 100644 index 000000000..e80382b9c --- /dev/null +++ b/factory-method/index.md @@ -0,0 +1,19 @@ +--- +layout: pattern +title: Factory Method +folder: factory-method +categories: creational +tags: pattern_tag +--- + +**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. + +![alt text](./etc/factory-method_1.png "Factory Method") + +**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 \ No newline at end of file diff --git a/flux/index.md b/flux/index.md new file mode 100644 index 000000000..f91c0ef00 --- /dev/null +++ b/flux/index.md @@ -0,0 +1,18 @@ +--- +layout: pattern +title: Flux +folder: flux +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/flux.png "Flux") + +**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. \ No newline at end of file diff --git a/flyweight/index.md b/flyweight/index.md new file mode 100644 index 000000000..c1d2439a7 --- /dev/null +++ b/flyweight/index.md @@ -0,0 +1,25 @@ +--- +layout: pattern +title: Flyweight +folder: flyweight +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Use sharing to support large numbers of fine-grained objects +efficiently. + +![alt text](./etc/flyweight_1.png "Flyweight") + +**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 +* an application uses a large number of objects +* storage costs are high because of the sheer quantity of objects +* most object state can be made extrinsic +* 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:** + +* [java.lang.Integer#valueOf(int)](http://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#valueOf%28int%29) \ No newline at end of file diff --git a/front-controller/index.md b/front-controller/index.md new file mode 100644 index 000000000..0a77a5ef3 --- /dev/null +++ b/front-controller/index.md @@ -0,0 +1,23 @@ +--- +layout: pattern +title: Front Controller +folder: front-controller +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/front-controller.png "Front Controller") + +**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:** + +* [Apache Struts](https://struts.apache.org/) \ No newline at end of file diff --git a/half-sync-half-async/index.md b/half-sync-half-async/index.md new file mode 100644 index 000000000..a9cd97698 --- /dev/null +++ b/half-sync-half-async/index.md @@ -0,0 +1,27 @@ +--- +layout: pattern +title: Half-Sync/Half-Async +folder: half-sync-half-async +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![Half-Sync/Half-Async class diagram](./half-sync-half-async/etc/half-sync-half-async.png) + +**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 + * it is inefficient to dedicate separate thread of control to perform synchronous I/O for each external source of event + * the higher level tasks in the system can be simplified significantly if I/O is performed synchronously. +* one or more tasks in a system must run in a single thread of control, while other tasks may benefit from multi-threading. + +**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) \ No newline at end of file diff --git a/idioms/index.md b/idioms/index.md new file mode 100644 index 000000000..68b689117 --- /dev/null +++ b/idioms/index.md @@ -0,0 +1,24 @@ +--- +layout: pattern +title: Idioms +folder: idioms +categories: pattern_cat +tags: pattern_tag +--- + + +A programming idiom is a means of expressing a recurring construct in one or +more programming languages. Generally speaking, a programming idiom is an +expression of a simple task, algorithm, or data structure that is not a built-in +feature in the programming language being used, or, conversely, the use of an +unusual or notable feature that is built into a programming language. What +distinguishes idioms from patterns is generally the size, the idioms tend to be +something small while the patterns are larger. + +* [Execute Around](#execute-around) +* [Poison Pill](#poison-pill) +* [Callback](#callback) +* [Lazy Loading](#lazy-loading) +* [Double Dispatch](#double-dispatch) +* [Resource Acquisition Is Initialization](#resource-acquisition-is-initialization) +* [Private Class Data](#private-class-data) \ No newline at end of file diff --git a/intercepting-filter/index.md b/intercepting-filter/index.md new file mode 100644 index 000000000..1badb0521 --- /dev/null +++ b/intercepting-filter/index.md @@ -0,0 +1,18 @@ +--- +layout: pattern +title: Intercepting Filter +folder: intercepting-filter +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Provide pluggable filters to conduct necessary pre-processing and +post-processing to requests from a client to a target + +![alt text](./etc/intercepting-filter.png "Intercepting Filter") + +**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 \ No newline at end of file diff --git a/interpreter/index.md b/interpreter/index.md new file mode 100644 index 000000000..dcd0d9f46 --- /dev/null +++ b/interpreter/index.md @@ -0,0 +1,19 @@ +--- +layout: pattern +title: Interpreter +folder: interpreter +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Given a language, define a representation for its grammar along +with an interpreter that uses the representation to interpret sentences in the +language. + +![alt text](./etc/interpreter_1.png "Interpreter") + +**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 \ No newline at end of file diff --git a/introduction/index.md b/introduction/index.md new file mode 100644 index 000000000..8ca2aea0e --- /dev/null +++ b/introduction/index.md @@ -0,0 +1,18 @@ +--- +layout: pattern +title: Introduction +folder: introduction +categories: pattern_cat +tags: pattern_tag +--- + + +Design patterns are formalized best practices that the programmer can use to +solve common problems when designing an application or system. + +Design patterns can speed up the development process by providing tested, proven +development paradigms. + +Reusing design patterns helps to prevent subtle issues that can cause major +problems, and it also improves code readability for coders and architects who +are familiar with the patterns. \ No newline at end of file diff --git a/iterator/index.md b/iterator/index.md new file mode 100644 index 000000000..75d9223d1 --- /dev/null +++ b/iterator/index.md @@ -0,0 +1,22 @@ +--- +layout: pattern +title: Iterator +folder: iterator +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Provide a way to access the elements of an aggregate object +sequentially without exposing its underlying representation. + +![alt text](./etc/iterator_1.png "Iterator") + +**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:** + +* [java.util.Iterator](http://docs.oracle.com/javase/8/docs/api/java/util/Iterator.html) \ No newline at end of file diff --git a/lazy-loading/index.md b/lazy-loading/index.md new file mode 100644 index 000000000..4a14d83d6 --- /dev/null +++ b/lazy-loading/index.md @@ -0,0 +1,22 @@ +--- +layout: pattern +title: Lazy Loading +folder: lazy-loading +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/lazy-loading.png "Lazy Loading") + +**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:** + +* JPA annotations @OneToOne, @OneToMany, @ManyToOne, @ManyToMany and fetch = FetchType.LAZY \ No newline at end of file diff --git a/mediator/index.md b/mediator/index.md new file mode 100644 index 000000000..f112d68ff --- /dev/null +++ b/mediator/index.md @@ -0,0 +1,19 @@ +--- +layout: pattern +title: Mediator +folder: mediator +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/mediator_1.png "Mediator") + +**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 \ No newline at end of file diff --git a/memento/index.md b/memento/index.md new file mode 100644 index 000000000..5c7bbb618 --- /dev/null +++ b/memento/index.md @@ -0,0 +1,21 @@ +--- +layout: pattern +title: Memento +folder: memento +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Without violating encapsulation, capture and externalize an +object's internal state so that the object can be restored to this state later. + +![alt text](./etc/memento.png "Memento") + +**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:** + +* [java.util.Date](http://docs.oracle.com/javase/8/docs/api/java/util/Date.html) \ No newline at end of file diff --git a/model-view-controller/index.md b/model-view-controller/index.md new file mode 100644 index 000000000..39a370258 --- /dev/null +++ b/model-view-controller/index.md @@ -0,0 +1,18 @@ +--- +layout: pattern +title: Model-View-Controller +folder: model-view-controller +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/model-view-controller.png "Model-View-Controller") + +**Applicability:** Use the Model-View-Controller pattern when + +* you want to clearly separate the domain data from its user interface representation \ No newline at end of file diff --git a/model-view-presenter/index.md b/model-view-presenter/index.md new file mode 100644 index 000000000..85b72029b --- /dev/null +++ b/model-view-presenter/index.md @@ -0,0 +1,17 @@ +--- +layout: pattern +title: Model-View-Presenter +folder: model-view-presenter +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Apply a "Separation of Concerns" principle in a way that allows +developers to build and test user interfaces. + +![alt text](./etc/model-view-presenter_1.png "Model-View-Presenter") + +**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. \ No newline at end of file diff --git a/multiton/index.md b/multiton/index.md new file mode 100644 index 000000000..23ddc714a --- /dev/null +++ b/multiton/index.md @@ -0,0 +1,16 @@ +--- +layout: pattern +title: Multiton +folder: multiton +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Ensure a class only has limited number of instances, and provide a +global point of access to them. + +![alt text](./etc/multiton.png "Multiton") + +**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 \ No newline at end of file diff --git a/naked-objects/index.md b/naked-objects/index.md new file mode 100644 index 000000000..db7a48b48 --- /dev/null +++ b/naked-objects/index.md @@ -0,0 +1,23 @@ +--- +layout: pattern +title: Naked Objects +folder: naked-objects +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/naked-objects.png "Naked Objects") + +**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:** + +* [Apache Isis](https://isis.apache.org/) \ No newline at end of file diff --git a/null-object/index.md b/null-object/index.md new file mode 100644 index 000000000..0ffb4395f --- /dev/null +++ b/null-object/index.md @@ -0,0 +1,22 @@ +--- +layout: pattern +title: Null Object +folder: null-object +categories: pattern_cat +tags: pattern_tag +--- + +**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 +object (for instance, a non-existent customer), one uses an object which +implements the expected interface, but whose method body is empty. The +advantage of this approach over a working default implementation is that a Null +Object is very predictable and has no side effects: it does nothing. + +![alt text](./etc/null-object.png "Null Object") + +**Applicability:** Use the Null Object pattern when + +* you want to avoid explicit null checks and keep the algorithm elegant and easy to read. \ No newline at end of file diff --git a/object-pool/index.md b/object-pool/index.md new file mode 100644 index 000000000..7521ce66f --- /dev/null +++ b/object-pool/index.md @@ -0,0 +1,19 @@ +--- +layout: pattern +title: Object Pool +folder: object-pool +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/object-pool.png "Object Pool") + +**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) \ No newline at end of file diff --git a/observer/index.md b/observer/index.md new file mode 100644 index 000000000..16bcfcd67 --- /dev/null +++ b/observer/index.md @@ -0,0 +1,27 @@ +--- +layout: pattern +title: Observer +folder: observer +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Define a one-to-many dependency between objects so that when one +object changes state, all its dependents are notified and updated +automatically. + +![alt text](./etc/observer_1.png "Observer") + +**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:** + +* changing in one object leads to a change in other objects + +**Real world examples:** + +* [java.util.Observer](http://docs.oracle.com/javase/8/docs/api/java/util/Observer.html) \ No newline at end of file diff --git a/poison-pill/index.md b/poison-pill/index.md new file mode 100644 index 000000000..ab151dc5d --- /dev/null +++ b/poison-pill/index.md @@ -0,0 +1,20 @@ +--- +layout: pattern +title: Poison Pill +folder: poison-pill +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Poison Pill is known predefined data item that allows to provide +graceful shutdown for separate distributed consumption process. + +![alt text](./etc/poison-pill.png "Poison Pill") + +**Applicability:** Use the Poison Pill idiom when + +* need to send signal from one thread/process to another to terminate + +**Real world examples:** + +* [akka.actor.PoisonPill](http://doc.akka.io/docs/akka/2.1.4/java/untyped-actors.html) \ No newline at end of file diff --git a/private-class-data/index.md b/private-class-data/index.md new file mode 100644 index 000000000..4f83a0c32 --- /dev/null +++ b/private-class-data/index.md @@ -0,0 +1,17 @@ +--- +layout: pattern +title: Private Class Data +folder: private-class-data +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/private-class-data.png "Private Class Data") + +**Applicability:** Use the Private Class Data pattern when + +* you want to prevent write access to class data members \ No newline at end of file diff --git a/property/index.md b/property/index.md new file mode 100644 index 000000000..6e92c35f8 --- /dev/null +++ b/property/index.md @@ -0,0 +1,20 @@ +--- +layout: pattern +title: Property +folder: property +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Create hierarchy of objects and new objects using already existing +objects as parents. + +![alt text](./etc/property.png "Property") + +**Applicability:** Use the Property pattern when + +* when you like to have objects with dynamic set of fields and prototype inheritance + +**Real world examples:** + +* [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain) prototype inheritance \ No newline at end of file diff --git a/prototype/index.md b/prototype/index.md new file mode 100644 index 000000000..aeb4b69b0 --- /dev/null +++ b/prototype/index.md @@ -0,0 +1,22 @@ +--- +layout: pattern +title: Prototype +folder: prototype +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Specify the kinds of objects to create using a prototypical +instance, and create new objects by copying this prototype. + +![alt text](./etc/prototype_1.png "Prototype") + +**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:** + +* [java.lang.Object#clone()](http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#clone%28%29) \ No newline at end of file diff --git a/proxy/index.md b/proxy/index.md new file mode 100644 index 000000000..8f907d563 --- /dev/null +++ b/proxy/index.md @@ -0,0 +1,33 @@ +--- +layout: pattern +title: Proxy +folder: proxy +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Provide a surrogate or placeholder for another object to control +access to it. + +![alt text](./etc/proxy_1.png "Proxy") + +**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 + +* a remote proxy provides a local representative for an object in a different address space. +* 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:** + +* control access to another object +* lazy initialization +* implement logging +* facilitate network connection +* to count references to an object + +**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/) \ No newline at end of file diff --git a/repository/index.md b/repository/index.md new file mode 100644 index 000000000..0fbd39d30 --- /dev/null +++ b/repository/index.md @@ -0,0 +1,26 @@ +--- +layout: pattern +title: Repository +folder: repository +categories: pattern_cat +tags: pattern_tag +--- + +**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 +querying is utilized. + +![alt text](./etc/repository.png "Repository") + +**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:** + +* [Spring Data](http://projects.spring.io/spring-data/) \ No newline at end of file diff --git a/resource-acquisition-is-initialization/index.md b/resource-acquisition-is-initialization/index.md new file mode 100644 index 000000000..d5fb509c6 --- /dev/null +++ b/resource-acquisition-is-initialization/index.md @@ -0,0 +1,15 @@ +--- +layout: pattern +title: Resource Acquisition Is Initialization +folder: resource-acquisition-is-initialization +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Resource Acquisition Is Initialization pattern can be used to implement exception safe resource management. + +![alt text](./etc/resource-acquisition-is-initialization.png "Resource Acquisition Is Initialization") + +**Applicability:** Use the Resource Acquisition Is Initialization pattern when + +* you have resources that must be closed in every condition \ No newline at end of file diff --git a/servant/index.md b/servant/index.md new file mode 100644 index 000000000..ff0339d00 --- /dev/null +++ b/servant/index.md @@ -0,0 +1,17 @@ +--- +layout: pattern +title: Servant +folder: servant +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/servant-pattern.png "Servant") + +**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. \ No newline at end of file diff --git a/service-layer/index.md b/service-layer/index.md new file mode 100644 index 000000000..0c1a09163 --- /dev/null +++ b/service-layer/index.md @@ -0,0 +1,21 @@ +--- +layout: pattern +title: Service Layer +folder: service-layer +categories: pattern_cat +tags: pattern_tag +--- + +**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 +interactions with the application to access and manipulate its data and invoke +its business logic. The Service Layer fulfills this role. + +![alt text](./etc/service-layer.png "Service Layer") + +**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 \ No newline at end of file diff --git a/service-locator/index.md b/service-locator/index.md new file mode 100644 index 000000000..c091b3440 --- /dev/null +++ b/service-locator/index.md @@ -0,0 +1,27 @@ +--- +layout: pattern +title: Service Locator +folder: service-locator +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Encapsulate the processes involved in obtaining a service with a +strong abstraction layer. + +![alt text](./etc/service-locator.png "Proxy") + +**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 +particular service is requested, the service Locator looks up in JNDI, fetched +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:** + +* when network hits are expensive and time consuming +* lookups of services are done quite frequently +* large number of services are being used \ No newline at end of file diff --git a/singleton/index.md b/singleton/index.md new file mode 100644 index 000000000..a06b4efcc --- /dev/null +++ b/singleton/index.md @@ -0,0 +1,27 @@ +--- +layout: pattern +title: Singleton +folder: singleton +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Ensure a class only has one instance, and provide a global point of +access to it. + +![alt text](./etc/singleton_1.png "Singleton") + +**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:** + +* the logging class +* managing a connection to a database +* file manager + +**Real world examples:** + +* [java.lang.Runtime#getRuntime()](http://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#getRuntime%28%29) \ No newline at end of file diff --git a/specification/index.md b/specification/index.md new file mode 100644 index 000000000..1ad6cd3f7 --- /dev/null +++ b/specification/index.md @@ -0,0 +1,19 @@ +--- +layout: pattern +title: Specification +folder: specification +categories: pattern_cat +tags: pattern_tag +--- + +**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 + +![alt text](./etc/specification.png "Specification") + +**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) \ No newline at end of file diff --git a/state/index.md b/state/index.md new file mode 100644 index 000000000..8bafb0fe1 --- /dev/null +++ b/state/index.md @@ -0,0 +1,17 @@ +--- +layout: pattern +title: State +folder: state +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Allow an object to alter its behavior when its internal state +changes. The object will appear to change its class. + +![alt text](./etc/state_1.png "State") + +**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. \ No newline at end of file diff --git a/step-builder/index.md b/step-builder/index.md new file mode 100644 index 000000000..ce805fe07 --- /dev/null +++ b/step-builder/index.md @@ -0,0 +1,14 @@ +--- +layout: pattern +title: Step Builder +folder: step-builder +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/step-builder.png "Step Builder") + +**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. \ No newline at end of file diff --git a/strategy/index.md b/strategy/index.md new file mode 100644 index 000000000..ecd6623fa --- /dev/null +++ b/strategy/index.md @@ -0,0 +1,20 @@ +--- +layout: pattern +title: Strategy +folder: strategy +categories: pattern_cat +tags: pattern_tag +--- + +**Intent:** Define a family of algorithms, encapsulate each one, and make them +interchangeable. Strategy lets the algorithm vary independently from clients +that use it. + +![alt text](./etc/strategy_1.png "Strategy") + +**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 \ No newline at end of file diff --git a/template-method/index.md b/template-method/index.md new file mode 100644 index 000000000..42f22f46f --- /dev/null +++ b/template-method/index.md @@ -0,0 +1,19 @@ +--- +layout: pattern +title: Template method +folder: template-method +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/template-method_1.png "Template Method") + +**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 \ No newline at end of file diff --git a/thread-pool/index.md b/thread-pool/index.md new file mode 100644 index 000000000..70ccd2231 --- /dev/null +++ b/thread-pool/index.md @@ -0,0 +1,19 @@ +--- +layout: pattern +title: Thread Pool +folder: thread-pool +categories: pattern_cat +tags: pattern_tag +--- + +**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 +and eliminating the latency of creating new threads. + +![alt text](./etc/thread-pool.png "Thread Pool") + +**Applicability:** Use the Thread Pool pattern when + +* you have a large number of short-lived tasks to be executed in parallel \ No newline at end of file diff --git a/tolerant-reader/index.md b/tolerant-reader/index.md new file mode 100644 index 000000000..3c04840b2 --- /dev/null +++ b/tolerant-reader/index.md @@ -0,0 +1,18 @@ +--- +layout: pattern +title: Tolerant Reader +folder: tolerant-reader +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/tolerant-reader.png "Tolerant Reader") + +**Applicability:** Use the Tolerant Reader pattern when + +* the communication schema can evolve and change and yet the receiving side should not break \ No newline at end of file diff --git a/visitor/index.md b/visitor/index.md new file mode 100644 index 000000000..d263fb80c --- /dev/null +++ b/visitor/index.md @@ -0,0 +1,23 @@ +--- +layout: pattern +title: Visitor +folder: visitor +categories: pattern_cat +tags: pattern_tag +--- + +**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. + +![alt text](./etc/visitor_1.png "Visitor") + +**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:** + +* [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) \ No newline at end of file From fdb9be1e7698f60aa230aa7006be8301144bc74b Mon Sep 17 00:00:00 2001 From: Markus Date: Sat, 15 Aug 2015 18:03:05 +0200 Subject: [PATCH 3/3] Work towards #56: Add permalink to every pattern This makes cleaner URLs thanks to jekyll --- abstract-factory/index.md | 3 ++- adapter/index.md | 3 ++- async-method-invocation/index.md | 3 ++- bridge/index.md | 3 ++- builder/index.md | 3 ++- business-delegate/index.md | 3 ++- callback/index.md | 3 ++- chain-of-responsibility/index.md | 3 ++- command/index.md | 3 ++- composite/index.md | 3 ++- dao/index.md | 3 ++- decorator/index.md | 3 ++- dependency-injection/index.md | 3 ++- double-checked-locking/index.md | 3 ++- double-dispatch/index.md | 3 ++- event-aggregator/index.md | 3 ++- execute-around/index.md | 3 ++- facade/index.md | 3 ++- factory-method/index.md | 3 ++- flux/index.md | 3 ++- flyweight/index.md | 3 ++- front-controller/index.md | 3 ++- half-sync-half-async/index.md | 3 ++- idioms/index.md | 24 ------------------- intercepting-filter/index.md | 3 ++- interpreter/index.md | 3 ++- introduction/index.md | 4 +++- iterator/index.md | 3 ++- lazy-loading/index.md | 3 ++- mediator/index.md | 3 ++- memento/index.md | 3 ++- model-view-controller/index.md | 3 ++- model-view-presenter/index.md | 3 ++- multiton/index.md | 3 ++- naked-objects/index.md | 3 ++- null-object/index.md | 3 ++- object-pool/index.md | 3 ++- observer/index.md | 3 ++- poison-pill/index.md | 3 ++- private-class-data/index.md | 3 ++- property/index.md | 3 ++- prototype/index.md | 3 ++- proxy/index.md | 3 ++- repository/index.md | 3 ++- .../index.md | 3 ++- servant/index.md | 3 ++- service-layer/index.md | 3 ++- service-locator/index.md | 3 ++- singleton/index.md | 3 ++- specification/index.md | 3 ++- state/index.md | 3 ++- step-builder/index.md | 3 ++- strategy/index.md | 3 ++- template-method/index.md | 3 ++- thread-pool/index.md | 3 ++- tolerant-reader/index.md | 3 ++- visitor/index.md | 3 ++- 57 files changed, 113 insertions(+), 80 deletions(-) delete mode 100644 idioms/index.md diff --git a/abstract-factory/index.md b/abstract-factory/index.md index ae053b2a2..412e16009 100644 --- a/abstract-factory/index.md +++ b/abstract-factory/index.md @@ -2,6 +2,7 @@ layout: pattern title: Abstract Factory folder: abstract-factory +permalink: /patterns/abstract-factory/ categories: - pattern_cat - creational @@ -22,4 +23,4 @@ objects without specifying their concrete classes. **Real world examples:** -* [javax.xml.parsers.DocumentBuilderFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/parsers/DocumentBuilderFactory.html) \ No newline at end of file +* [javax.xml.parsers.DocumentBuilderFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/parsers/DocumentBuilderFactory.html) diff --git a/adapter/index.md b/adapter/index.md index b8d2741cc..f1e4043b6 100644 --- a/adapter/index.md +++ b/adapter/index.md @@ -2,6 +2,7 @@ layout: pattern title: Adapter folder: adapter +permalink: /patterns/adapter/ categories: pattern_cat tags: pattern_tag --- @@ -20,4 +21,4 @@ incompatible interfaces. **Real world examples:** -* [java.util.Arrays#asList()](http://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#asList%28T...%29) \ No newline at end of file +* [java.util.Arrays#asList()](http://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#asList%28T...%29) diff --git a/async-method-invocation/index.md b/async-method-invocation/index.md index 00812d310..0ea60c168 100644 --- a/async-method-invocation/index.md +++ b/async-method-invocation/index.md @@ -2,6 +2,7 @@ layout: pattern title: Async Method Invocation folder: async-method-invocation +permalink: /patterns/async-method-invocation/ categories: pattern_cat tags: pattern_tag --- @@ -23,4 +24,4 @@ callbacks or waiting until everything is done. **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) \ No newline at end of file +* [Task-based Asynchronous Pattern](https://msdn.microsoft.com/en-us/library/hh873175.aspx) (.NET) diff --git a/bridge/index.md b/bridge/index.md index d0a1e0ea1..b2319e22e 100644 --- a/bridge/index.md +++ b/bridge/index.md @@ -2,6 +2,7 @@ layout: pattern title: Bridge folder: bridge +permalink: /patterns/bridge/ categories: pattern_cat tags: pattern_tag --- @@ -18,4 +19,4 @@ vary independently. * both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently * changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled. * you have a proliferation of classes. Such a class hierarchy indicates the need for splitting an object into two parts. Rumbaugh uses the term "nested generalizations" to refer to such class hierarchies -* you want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be hidden from the client. A simple example is Coplien's String class, in which multiple objects can share the same string representation. \ No newline at end of file +* 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. diff --git a/builder/index.md b/builder/index.md index 0a5254ce1..78fb61fea 100644 --- a/builder/index.md +++ b/builder/index.md @@ -2,6 +2,7 @@ layout: pattern title: Builder folder: builder +permalink: /patterns/builder/ categories: creational tags: pattern_tag --- @@ -20,4 +21,4 @@ representations. **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) \ No newline at end of file +* [Apache Camel builders](https://github.com/apache/camel/tree/0e195428ee04531be27a0b659005e3aa8d159d23/camel-core/src/main/java/org/apache/camel/builder) diff --git a/business-delegate/index.md b/business-delegate/index.md index 23c92b89e..37b118e15 100644 --- a/business-delegate/index.md +++ b/business-delegate/index.md @@ -2,6 +2,7 @@ layout: pattern title: Business Delegate folder: business-delegate +permalink: /patterns/business-delegate/ categories: pattern_cat tags: pattern_tag --- @@ -17,4 +18,4 @@ and interact with the business objects that make up the application. * you want loose coupling between presentation and business tiers * you want to orchestrate calls to multiple business services -* you want to encapsulate service lookups and service calls \ No newline at end of file +* you want to encapsulate service lookups and service calls diff --git a/callback/index.md b/callback/index.md index b8a4f2808..1d65e1514 100644 --- a/callback/index.md +++ b/callback/index.md @@ -2,6 +2,7 @@ layout: pattern title: Callback folder: callback +permalink: /patterns/callback/ categories: pattern_cat tags: pattern_tag --- @@ -18,4 +19,4 @@ at some convenient time. **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. \ No newline at end of file +* [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. diff --git a/chain-of-responsibility/index.md b/chain-of-responsibility/index.md index 234815506..3ee2a3c64 100644 --- a/chain-of-responsibility/index.md +++ b/chain-of-responsibility/index.md @@ -2,6 +2,7 @@ layout: pattern title: Chain of responsibility folder: chain-of-responsibility +permalink: /patterns/chain-of-responsibility/ categories: pattern_cat tags: pattern_tag --- @@ -21,4 +22,4 @@ objects and pass the request along the chain until an object handles it. **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) \ No newline at end of file +* [Apache Commons Chain](https://commons.apache.org/proper/commons-chain/index.html) diff --git a/command/index.md b/command/index.md index 21422da35..a675a30c7 100644 --- a/command/index.md +++ b/command/index.md @@ -2,6 +2,7 @@ layout: pattern title: Command folder: command +permalink: /patterns/command/ categories: pattern_cat tags: pattern_tag --- @@ -28,4 +29,4 @@ support undoable operations. **Real world examples:** -* [java.lang.Runnable](http://docs.oracle.com/javase/8/docs/api/java/lang/Runnable.html) \ No newline at end of file +* [java.lang.Runnable](http://docs.oracle.com/javase/8/docs/api/java/lang/Runnable.html) diff --git a/composite/index.md b/composite/index.md index d987aa27c..f50c32dd3 100644 --- a/composite/index.md +++ b/composite/index.md @@ -2,6 +2,7 @@ layout: pattern title: Composite folder: composite +permalink: /patterns/composite/ categories: pattern_cat tags: pattern_tag --- @@ -20,4 +21,4 @@ of objects uniformly. **Real world examples:** * [java.awt.Container](http://docs.oracle.com/javase/8/docs/api/java/awt/Container.html) and [java.awt.Component](http://docs.oracle.com/javase/8/docs/api/java/awt/Component.html) -* [Apache Wicket](https://github.com/apache/wicket) component tree, see [Component](https://github.com/apache/wicket/blob/91e154702ab1ff3481ef6cbb04c6044814b7e130/wicket-core/src/main/java/org/apache/wicket/Component.java) and [MarkupContainer](https://github.com/apache/wicket/blob/b60ec64d0b50a611a9549809c9ab216f0ffa3ae3/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java) \ No newline at end of file +* [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) diff --git a/dao/index.md b/dao/index.md index 3d6b10d3f..8058f7c7c 100644 --- a/dao/index.md +++ b/dao/index.md @@ -2,6 +2,7 @@ layout: pattern title: Data Access Object folder: dao +permalink: /patterns/dao/ categories: pattern_cat tags: pattern_tag --- @@ -14,4 +15,4 @@ other persistence mechanism. **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 \ No newline at end of file +* when you want to avoid writing multiple data retrieval/persistence layers diff --git a/decorator/index.md b/decorator/index.md index 3674e5d4a..95ad2dced 100644 --- a/decorator/index.md +++ b/decorator/index.md @@ -2,6 +2,7 @@ layout: pattern title: Decorator folder: decorator +permalink: /patterns/decorator/ categories: pattern_cat tags: pattern_tag --- @@ -16,4 +17,4 @@ functionality. * 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 \ No newline at end of file +* 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 diff --git a/dependency-injection/index.md b/dependency-injection/index.md index d0b238818..3b2853c75 100644 --- a/dependency-injection/index.md +++ b/dependency-injection/index.md @@ -2,6 +2,7 @@ layout: pattern title: Dependency Injection folder: dependency-injection +permalink: /patterns/dependency-injection/ categories: pattern_cat tags: pattern_tag --- @@ -18,4 +19,4 @@ inversion of control and single responsibility principles. **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 \ No newline at end of file +* to enable unit testing of classes in isolation using mock objects or stubs diff --git a/double-checked-locking/index.md b/double-checked-locking/index.md index 8af9e6af0..92fb22b01 100644 --- a/double-checked-locking/index.md +++ b/double-checked-locking/index.md @@ -2,6 +2,7 @@ layout: pattern title: Double Checked Locking folder: double-checked-locking +permalink: /patterns/double-checked-locking/ categories: pattern_cat tags: pattern_tag --- @@ -16,4 +17,4 @@ actual locking logic proceed. **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. \ No newline at end of file +* 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. diff --git a/double-dispatch/index.md b/double-dispatch/index.md index 8c6586590..842913738 100644 --- a/double-dispatch/index.md +++ b/double-dispatch/index.md @@ -2,6 +2,7 @@ layout: pattern title: Double Dispatch folder: double-dispatch +permalink: /patterns/double-dispatch/ categories: pattern_cat tags: pattern_tag --- @@ -17,4 +18,4 @@ behavior based on receiver and parameter types. **Real world examples:** -* [ObjectOutputStream](https://docs.oracle.com/javase/8/docs/api/java/io/ObjectOutputStream.html) \ No newline at end of file +* [ObjectOutputStream](https://docs.oracle.com/javase/8/docs/api/java/io/ObjectOutputStream.html) diff --git a/event-aggregator/index.md b/event-aggregator/index.md index a6fd9fb22..d4a2395bd 100644 --- a/event-aggregator/index.md +++ b/event-aggregator/index.md @@ -2,6 +2,7 @@ layout: pattern title: Event Aggregator folder: event-aggregator +permalink: /patterns/event-aggregator/ categories: pattern_cat tags: pattern_tag --- @@ -21,4 +22,4 @@ allowing clients to register with just the aggregator. potential event sources. Rather than have the observer deal with registering with them all, you can centralize the registration logic to the Event Aggregator. As well as simplifying registration, a Event Aggregator also - simplifies the memory management issues in using observers. \ No newline at end of file + simplifies the memory management issues in using observers. diff --git a/execute-around/index.md b/execute-around/index.md index 949f424c3..ec4c040bf 100644 --- a/execute-around/index.md +++ b/execute-around/index.md @@ -2,6 +2,7 @@ layout: pattern title: Execute Around folder: execute-around +permalink: /patterns/execute-around/ categories: pattern_cat tags: pattern_tag --- @@ -15,4 +16,4 @@ only what to do with the resource. **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. \ No newline at end of file +* you use an API that requires methods to be called in pairs such as open/close or allocate/deallocate. diff --git a/facade/index.md b/facade/index.md index 8a9a9c1b9..7e0d3100a 100644 --- a/facade/index.md +++ b/facade/index.md @@ -2,6 +2,7 @@ layout: pattern title: Facade folder: facade +permalink: /patterns/facade/ categories: pattern_cat tags: pattern_tag --- @@ -15,4 +16,4 @@ Facade defines a higher-level interface that makes the subsystem easier to use. * 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 \ No newline at end of file +* 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 diff --git a/factory-method/index.md b/factory-method/index.md index e80382b9c..11ad77dda 100644 --- a/factory-method/index.md +++ b/factory-method/index.md @@ -2,6 +2,7 @@ layout: pattern title: Factory Method folder: factory-method +permalink: /patterns/factory-method/ categories: creational tags: pattern_tag --- @@ -16,4 +17,4 @@ instantiation to subclasses. * 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 \ No newline at end of file +* classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate diff --git a/flux/index.md b/flux/index.md index f91c0ef00..fec262dce 100644 --- a/flux/index.md +++ b/flux/index.md @@ -2,6 +2,7 @@ layout: pattern title: Flux folder: flux +permalink: /patterns/flux/ categories: pattern_cat tags: pattern_tag --- @@ -15,4 +16,4 @@ logic, which updates all of the views that are affected. **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. \ No newline at end of file +* 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. diff --git a/flyweight/index.md b/flyweight/index.md index c1d2439a7..a2a4ca575 100644 --- a/flyweight/index.md +++ b/flyweight/index.md @@ -2,6 +2,7 @@ layout: pattern title: Flyweight folder: flyweight +permalink: /patterns/flyweight/ categories: pattern_cat tags: pattern_tag --- @@ -22,4 +23,4 @@ true **Real world examples:** -* [java.lang.Integer#valueOf(int)](http://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#valueOf%28int%29) \ No newline at end of file +* [java.lang.Integer#valueOf(int)](http://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#valueOf%28int%29) diff --git a/front-controller/index.md b/front-controller/index.md index 0a77a5ef3..221da0404 100644 --- a/front-controller/index.md +++ b/front-controller/index.md @@ -2,6 +2,7 @@ layout: pattern title: Front Controller folder: front-controller +permalink: /patterns/front-controller/ categories: pattern_cat tags: pattern_tag --- @@ -20,4 +21,4 @@ internationalization, routing and logging in a single place. **Real world examples:** -* [Apache Struts](https://struts.apache.org/) \ No newline at end of file +* [Apache Struts](https://struts.apache.org/) diff --git a/half-sync-half-async/index.md b/half-sync-half-async/index.md index a9cd97698..ef3677fce 100644 --- a/half-sync-half-async/index.md +++ b/half-sync-half-async/index.md @@ -2,6 +2,7 @@ layout: pattern title: Half-Sync/Half-Async folder: half-sync-half-async +permalink: /patterns/half-sync-half-async/ categories: pattern_cat tags: pattern_tag --- @@ -24,4 +25,4 @@ degrading execution efficiency. * [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) \ No newline at end of file +* [Android AsyncTask framework](http://developer.android.com/reference/android/os/AsyncTask.html) diff --git a/idioms/index.md b/idioms/index.md deleted file mode 100644 index 68b689117..000000000 --- a/idioms/index.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -layout: pattern -title: Idioms -folder: idioms -categories: pattern_cat -tags: pattern_tag ---- - - -A programming idiom is a means of expressing a recurring construct in one or -more programming languages. Generally speaking, a programming idiom is an -expression of a simple task, algorithm, or data structure that is not a built-in -feature in the programming language being used, or, conversely, the use of an -unusual or notable feature that is built into a programming language. What -distinguishes idioms from patterns is generally the size, the idioms tend to be -something small while the patterns are larger. - -* [Execute Around](#execute-around) -* [Poison Pill](#poison-pill) -* [Callback](#callback) -* [Lazy Loading](#lazy-loading) -* [Double Dispatch](#double-dispatch) -* [Resource Acquisition Is Initialization](#resource-acquisition-is-initialization) -* [Private Class Data](#private-class-data) \ No newline at end of file diff --git a/intercepting-filter/index.md b/intercepting-filter/index.md index 1badb0521..6ceb97277 100644 --- a/intercepting-filter/index.md +++ b/intercepting-filter/index.md @@ -2,6 +2,7 @@ layout: pattern title: Intercepting Filter folder: intercepting-filter +permalink: /patterns/intercepting-filter/ categories: pattern_cat tags: pattern_tag --- @@ -15,4 +16,4 @@ post-processing to requests from a client to a target * 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 \ No newline at end of file +* you want a modular approach to configuring pre-processing and post-processing schemes diff --git a/interpreter/index.md b/interpreter/index.md index dcd0d9f46..d1d0babaf 100644 --- a/interpreter/index.md +++ b/interpreter/index.md @@ -2,6 +2,7 @@ layout: pattern title: Interpreter folder: interpreter +permalink: /patterns/interpreter/ categories: pattern_cat tags: pattern_tag --- @@ -16,4 +17,4 @@ language. 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 \ No newline at end of file +* 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 diff --git a/introduction/index.md b/introduction/index.md index 8ca2aea0e..14df55cee 100644 --- a/introduction/index.md +++ b/introduction/index.md @@ -2,6 +2,8 @@ layout: pattern title: Introduction folder: introduction +permalink: /patterns/introduction/ +permalink: /patterns/introduction/ categories: pattern_cat tags: pattern_tag --- @@ -15,4 +17,4 @@ development paradigms. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who -are familiar with the patterns. \ No newline at end of file +are familiar with the patterns. diff --git a/iterator/index.md b/iterator/index.md index 75d9223d1..d8005cc23 100644 --- a/iterator/index.md +++ b/iterator/index.md @@ -2,6 +2,7 @@ layout: pattern title: Iterator folder: iterator +permalink: /patterns/iterator/ categories: pattern_cat tags: pattern_tag --- @@ -19,4 +20,4 @@ sequentially without exposing its underlying representation. **Real world examples:** -* [java.util.Iterator](http://docs.oracle.com/javase/8/docs/api/java/util/Iterator.html) \ No newline at end of file +* [java.util.Iterator](http://docs.oracle.com/javase/8/docs/api/java/util/Iterator.html) diff --git a/lazy-loading/index.md b/lazy-loading/index.md index 4a14d83d6..c1ecc1cf5 100644 --- a/lazy-loading/index.md +++ b/lazy-loading/index.md @@ -2,6 +2,7 @@ layout: pattern title: Lazy Loading folder: lazy-loading +permalink: /patterns/lazy-loading/ categories: pattern_cat tags: pattern_tag --- @@ -19,4 +20,4 @@ appropriately used. **Real world examples:** -* JPA annotations @OneToOne, @OneToMany, @ManyToOne, @ManyToMany and fetch = FetchType.LAZY \ No newline at end of file +* JPA annotations @OneToOne, @OneToMany, @ManyToOne, @ManyToMany and fetch = FetchType.LAZY diff --git a/mediator/index.md b/mediator/index.md index f112d68ff..ce1119eab 100644 --- a/mediator/index.md +++ b/mediator/index.md @@ -2,6 +2,7 @@ layout: pattern title: Mediator folder: mediator +permalink: /patterns/mediator/ categories: pattern_cat tags: pattern_tag --- @@ -16,4 +17,4 @@ other explicitly, and it lets you vary their interaction independently. * 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 \ No newline at end of file +* a behavior that's distributed between several classes should be customizable without a lot of subclassing diff --git a/memento/index.md b/memento/index.md index 5c7bbb618..beb447fc9 100644 --- a/memento/index.md +++ b/memento/index.md @@ -2,6 +2,7 @@ layout: pattern title: Memento folder: memento +permalink: /patterns/memento/ categories: pattern_cat tags: pattern_tag --- @@ -18,4 +19,4 @@ object's internal state so that the object can be restored to this state later. **Real world examples:** -* [java.util.Date](http://docs.oracle.com/javase/8/docs/api/java/util/Date.html) \ No newline at end of file +* [java.util.Date](http://docs.oracle.com/javase/8/docs/api/java/util/Date.html) diff --git a/model-view-controller/index.md b/model-view-controller/index.md index 39a370258..cb85bad19 100644 --- a/model-view-controller/index.md +++ b/model-view-controller/index.md @@ -2,6 +2,7 @@ layout: pattern title: Model-View-Controller folder: model-view-controller +permalink: /patterns/model-view-controller/ categories: pattern_cat tags: pattern_tag --- @@ -15,4 +16,4 @@ display. **Applicability:** Use the Model-View-Controller pattern when -* you want to clearly separate the domain data from its user interface representation \ No newline at end of file +* you want to clearly separate the domain data from its user interface representation diff --git a/model-view-presenter/index.md b/model-view-presenter/index.md index 85b72029b..35b62a391 100644 --- a/model-view-presenter/index.md +++ b/model-view-presenter/index.md @@ -2,6 +2,7 @@ layout: pattern title: Model-View-Presenter folder: model-view-presenter +permalink: /patterns/model-view-presenter/ categories: pattern_cat tags: pattern_tag --- @@ -14,4 +15,4 @@ developers to build and test user interfaces. **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. \ No newline at end of file +* when a user interface development and testing is necessary. diff --git a/multiton/index.md b/multiton/index.md index 23ddc714a..854d75de3 100644 --- a/multiton/index.md +++ b/multiton/index.md @@ -2,6 +2,7 @@ layout: pattern title: Multiton folder: multiton +permalink: /patterns/multiton/ categories: pattern_cat tags: pattern_tag --- @@ -13,4 +14,4 @@ global point of access to them. **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 \ No newline at end of file +* there must be specific number of instances of a class, and they must be accessible to clients from a well-known access point diff --git a/naked-objects/index.md b/naked-objects/index.md index db7a48b48..160e68add 100644 --- a/naked-objects/index.md +++ b/naked-objects/index.md @@ -2,6 +2,7 @@ layout: pattern title: Naked Objects folder: naked-objects +permalink: /patterns/naked-objects/ categories: pattern_cat tags: pattern_tag --- @@ -20,4 +21,4 @@ everything else is autogenerated by the framework. **Real world examples:** -* [Apache Isis](https://isis.apache.org/) \ No newline at end of file +* [Apache Isis](https://isis.apache.org/) diff --git a/null-object/index.md b/null-object/index.md index 0ffb4395f..9888eeaf7 100644 --- a/null-object/index.md +++ b/null-object/index.md @@ -2,6 +2,7 @@ layout: pattern title: Null Object folder: null-object +permalink: /patterns/null-object/ categories: pattern_cat tags: pattern_tag --- @@ -19,4 +20,4 @@ Object is very predictable and has no side effects: it does nothing. **Applicability:** Use the Null Object pattern when -* you want to avoid explicit null checks and keep the algorithm elegant and easy to read. \ No newline at end of file +* you want to avoid explicit null checks and keep the algorithm elegant and easy to read. diff --git a/object-pool/index.md b/object-pool/index.md index 7521ce66f..a812d3fa1 100644 --- a/object-pool/index.md +++ b/object-pool/index.md @@ -2,6 +2,7 @@ layout: pattern title: Object Pool folder: object-pool +permalink: /patterns/object-pool/ categories: pattern_cat tags: pattern_tag --- @@ -16,4 +17,4 @@ are in use and which are available. **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) \ No newline at end of file +* you need a large number of short-lived objects (memory fragmentation) diff --git a/observer/index.md b/observer/index.md index 16bcfcd67..ea6de55ae 100644 --- a/observer/index.md +++ b/observer/index.md @@ -2,6 +2,7 @@ layout: pattern title: Observer folder: observer +permalink: /patterns/observer/ categories: pattern_cat tags: pattern_tag --- @@ -24,4 +25,4 @@ automatically. **Real world examples:** -* [java.util.Observer](http://docs.oracle.com/javase/8/docs/api/java/util/Observer.html) \ No newline at end of file +* [java.util.Observer](http://docs.oracle.com/javase/8/docs/api/java/util/Observer.html) diff --git a/poison-pill/index.md b/poison-pill/index.md index ab151dc5d..7d3b02bf4 100644 --- a/poison-pill/index.md +++ b/poison-pill/index.md @@ -2,6 +2,7 @@ layout: pattern title: Poison Pill folder: poison-pill +permalink: /patterns/poison-pill/ categories: pattern_cat tags: pattern_tag --- @@ -17,4 +18,4 @@ graceful shutdown for separate distributed consumption process. **Real world examples:** -* [akka.actor.PoisonPill](http://doc.akka.io/docs/akka/2.1.4/java/untyped-actors.html) \ No newline at end of file +* [akka.actor.PoisonPill](http://doc.akka.io/docs/akka/2.1.4/java/untyped-actors.html) diff --git a/private-class-data/index.md b/private-class-data/index.md index 4f83a0c32..b90ae654d 100644 --- a/private-class-data/index.md +++ b/private-class-data/index.md @@ -2,6 +2,7 @@ layout: pattern title: Private Class Data folder: private-class-data +permalink: /patterns/private-class-data/ categories: pattern_cat tags: pattern_tag --- @@ -14,4 +15,4 @@ attributes by encapsulating them in single Data object. **Applicability:** Use the Private Class Data pattern when -* you want to prevent write access to class data members \ No newline at end of file +* you want to prevent write access to class data members diff --git a/property/index.md b/property/index.md index 6e92c35f8..4ebb3e74a 100644 --- a/property/index.md +++ b/property/index.md @@ -2,6 +2,7 @@ layout: pattern title: Property folder: property +permalink: /patterns/property/ categories: pattern_cat tags: pattern_tag --- @@ -17,4 +18,4 @@ objects as parents. **Real world examples:** -* [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain) prototype inheritance \ No newline at end of file +* [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain) prototype inheritance diff --git a/prototype/index.md b/prototype/index.md index aeb4b69b0..e0b500188 100644 --- a/prototype/index.md +++ b/prototype/index.md @@ -2,6 +2,7 @@ layout: pattern title: Prototype folder: prototype +permalink: /patterns/prototype/ categories: pattern_cat tags: pattern_tag --- @@ -19,4 +20,4 @@ instance, and create new objects by copying this prototype. **Real world examples:** -* [java.lang.Object#clone()](http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#clone%28%29) \ No newline at end of file +* [java.lang.Object#clone()](http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#clone%28%29) diff --git a/proxy/index.md b/proxy/index.md index 8f907d563..54d16b37c 100644 --- a/proxy/index.md +++ b/proxy/index.md @@ -2,6 +2,7 @@ layout: pattern title: Proxy folder: proxy +permalink: /patterns/proxy/ categories: pattern_cat tags: pattern_tag --- @@ -30,4 +31,4 @@ are several common situations in which the Proxy pattern is applicable **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/) \ No newline at end of file +* [Apache Commons Proxy](https://commons.apache.org/proper/commons-proxy/) diff --git a/repository/index.md b/repository/index.md index 0fbd39d30..320509f5e 100644 --- a/repository/index.md +++ b/repository/index.md @@ -2,6 +2,7 @@ layout: pattern title: Repository folder: repository +permalink: /patterns/repository/ categories: pattern_cat tags: pattern_tag --- @@ -23,4 +24,4 @@ querying is utilized. **Real world examples:** -* [Spring Data](http://projects.spring.io/spring-data/) \ No newline at end of file +* [Spring Data](http://projects.spring.io/spring-data/) diff --git a/resource-acquisition-is-initialization/index.md b/resource-acquisition-is-initialization/index.md index d5fb509c6..7b283ab8c 100644 --- a/resource-acquisition-is-initialization/index.md +++ b/resource-acquisition-is-initialization/index.md @@ -2,6 +2,7 @@ layout: pattern title: Resource Acquisition Is Initialization folder: resource-acquisition-is-initialization +permalink: /patterns/resource-acquisition-is-initialization/ categories: pattern_cat tags: pattern_tag --- @@ -12,4 +13,4 @@ tags: pattern_tag **Applicability:** Use the Resource Acquisition Is Initialization pattern when -* you have resources that must be closed in every condition \ No newline at end of file +* you have resources that must be closed in every condition diff --git a/servant/index.md b/servant/index.md index ff0339d00..3d2d6ead2 100644 --- a/servant/index.md +++ b/servant/index.md @@ -2,6 +2,7 @@ layout: pattern title: Servant folder: servant +permalink: /patterns/servant/ categories: pattern_cat tags: pattern_tag --- @@ -14,4 +15,4 @@ this behavior in the common parent class - it is defined once in the Servant. **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. \ No newline at end of file +* when we want some objects to perform a common action and don't want to define this action as a method in every class. diff --git a/service-layer/index.md b/service-layer/index.md index 0c1a09163..1ce533b37 100644 --- a/service-layer/index.md +++ b/service-layer/index.md @@ -2,6 +2,7 @@ layout: pattern title: Service Layer folder: service-layer +permalink: /patterns/service-layer/ categories: pattern_cat tags: pattern_tag --- @@ -18,4 +19,4 @@ its business logic. The Service Layer fulfills this role. **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 \ No newline at end of file +* you need to implement multiple interfaces with common logic and data diff --git a/service-locator/index.md b/service-locator/index.md index c091b3440..5e002fe67 100644 --- a/service-locator/index.md +++ b/service-locator/index.md @@ -2,6 +2,7 @@ layout: pattern title: Service Locator folder: service-locator +permalink: /patterns/service-locator/ categories: pattern_cat tags: pattern_tag --- @@ -24,4 +25,4 @@ improves the performance of application to great extent. * when network hits are expensive and time consuming * lookups of services are done quite frequently -* large number of services are being used \ No newline at end of file +* large number of services are being used diff --git a/singleton/index.md b/singleton/index.md index a06b4efcc..dad14ecd4 100644 --- a/singleton/index.md +++ b/singleton/index.md @@ -2,6 +2,7 @@ layout: pattern title: Singleton folder: singleton +permalink: /patterns/singleton/ categories: pattern_cat tags: pattern_tag --- @@ -24,4 +25,4 @@ access to it. **Real world examples:** -* [java.lang.Runtime#getRuntime()](http://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#getRuntime%28%29) \ No newline at end of file +* [java.lang.Runtime#getRuntime()](http://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#getRuntime%28%29) diff --git a/specification/index.md b/specification/index.md index 1ad6cd3f7..9c4d1c2f6 100644 --- a/specification/index.md +++ b/specification/index.md @@ -2,6 +2,7 @@ layout: pattern title: Specification folder: specification +permalink: /patterns/specification/ categories: pattern_cat tags: pattern_tag --- @@ -16,4 +17,4 @@ order **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) \ No newline at end of file +* you need to check that only suitable objects are used for a certain role (validation) diff --git a/state/index.md b/state/index.md index 8bafb0fe1..5142645fa 100644 --- a/state/index.md +++ b/state/index.md @@ -2,6 +2,7 @@ layout: pattern title: State folder: state +permalink: /patterns/state/ categories: pattern_cat tags: pattern_tag --- @@ -14,4 +15,4 @@ changes. The object will appear to change its class. **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. \ No newline at end of file +* 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. diff --git a/step-builder/index.md b/step-builder/index.md index ce805fe07..5a7a42246 100644 --- a/step-builder/index.md +++ b/step-builder/index.md @@ -2,6 +2,7 @@ layout: pattern title: Step Builder folder: step-builder +permalink: /patterns/step-builder/ categories: pattern_cat tags: pattern_tag --- @@ -11,4 +12,4 @@ The user experience will be much more improved by the fact that he will only see ![alt text](./etc/step-builder.png "Step Builder") -**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. \ No newline at end of file +**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. diff --git a/strategy/index.md b/strategy/index.md index ecd6623fa..0cc720138 100644 --- a/strategy/index.md +++ b/strategy/index.md @@ -2,6 +2,7 @@ layout: pattern title: Strategy folder: strategy +permalink: /patterns/strategy/ categories: pattern_cat tags: pattern_tag --- @@ -17,4 +18,4 @@ that use it. * 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 \ No newline at end of file +* 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 diff --git a/template-method/index.md b/template-method/index.md index 42f22f46f..ff4c14332 100644 --- a/template-method/index.md +++ b/template-method/index.md @@ -2,6 +2,7 @@ layout: pattern title: Template method folder: template-method +permalink: /patterns/template-method/ categories: pattern_cat tags: pattern_tag --- @@ -16,4 +17,4 @@ an algorithm without changing the algorithm's structure. * 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 \ No newline at end of file +* to control subclasses extensions. You can define a template method that calls "hook" operations at specific points, thereby permitting extensions only at those points diff --git a/thread-pool/index.md b/thread-pool/index.md index 70ccd2231..107d07850 100644 --- a/thread-pool/index.md +++ b/thread-pool/index.md @@ -2,6 +2,7 @@ layout: pattern title: Thread Pool folder: thread-pool +permalink: /patterns/thread-pool/ categories: pattern_cat tags: pattern_tag --- @@ -16,4 +17,4 @@ and eliminating the latency of creating new threads. **Applicability:** Use the Thread Pool pattern when -* you have a large number of short-lived tasks to be executed in parallel \ No newline at end of file +* you have a large number of short-lived tasks to be executed in parallel diff --git a/tolerant-reader/index.md b/tolerant-reader/index.md index 3c04840b2..f8d4d77df 100644 --- a/tolerant-reader/index.md +++ b/tolerant-reader/index.md @@ -2,6 +2,7 @@ layout: pattern title: Tolerant Reader folder: tolerant-reader +permalink: /patterns/tolerant-reader/ categories: pattern_cat tags: pattern_tag --- @@ -15,4 +16,4 @@ changes, the readers must not break. **Applicability:** Use the Tolerant Reader pattern when -* the communication schema can evolve and change and yet the receiving side should not break \ No newline at end of file +* the communication schema can evolve and change and yet the receiving side should not break diff --git a/visitor/index.md b/visitor/index.md index d263fb80c..6b1516135 100644 --- a/visitor/index.md +++ b/visitor/index.md @@ -2,6 +2,7 @@ layout: pattern title: Visitor folder: visitor +permalink: /patterns/visitor/ categories: pattern_cat tags: pattern_tag --- @@ -20,4 +21,4 @@ of the elements on which it operates. **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) \ No newline at end of file +* [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)