gaspersic/java-design-patterns
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
Ilkka Seppälä 2020-08-29 22:13:55 +03:00
parent bc35911475
commit 67d1d16e1f
3 changed files with 77 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
object-pool/README.md
View File

@ -10,16 +10,18 @@ tags:
--- ---
## Intent ## 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. When objects are expensive to create and they are needed only for short periods of time it is
The Object Pool provides a cache for instantiated objects tracking which ones advantageous to utilize the Object Pool pattern. The Object Pool provides a cache for instantiated
are in use and which are available. objects tracking which ones are in use and which are available.
## Explanation ## Explanation
Real world example Real world example
> In our war game we need to use oliphaunts, massive and mythic beasts, but the problem is that they are extremely expensive to create. The solution is to create a pool of them, track which ones are in-use, and instead of disposing them re-use the instances. > In our war game we need to use oliphaunts, massive and mythic beasts, but the problem is that they
> are extremely expensive to create. The solution is to create a pool of them, track which ones are
> in-use, and instead of disposing them re-use the instances.
In plain words In plain words
@ -27,11 +29,12 @@ In plain words
Wikipedia says Wikipedia says
> The object pool pattern is a software creational design pattern that uses a set of initialized objects kept ready to use – a "pool" – rather than allocating and destroying them on demand. > The object pool pattern is a software creational design pattern that uses a set of initialized
> objects kept ready to use – a "pool" – rather than allocating and destroying them on demand.
**Programmatic Example** **Programmatic Example**
Here's the basic Oliphaunt class. These are very expensive to create. Here's the basic `Oliphaunt` class. These giants are very expensive to create.
```java ```java
public class Oliphaunt { public class Oliphaunt {
@ -60,7 +63,7 @@ public class Oliphaunt {
} }
``` ```
Next we present the Object Pool and more specifically Oliphaunt Pool. Next we present the `ObjectPool` and more specifically `OliphauntPool`.
```java ```java
public abstract class ObjectPool<T> { public abstract class ObjectPool<T> {
@ -100,7 +103,7 @@ public class OliphauntPool extends ObjectPool<Oliphaunt> {
} }
``` ```
And finally here's how we utilize the pool. Finally, here's how we utilize the pool.
```java ```java
var pool = new OliphauntPool(); var pool = new OliphauntPool();
@ -113,11 +116,30 @@ And finally here's how we utilize the pool.
var oliphaunt5 = pool.checkOut(); var oliphaunt5 = pool.checkOut();
``` ```
Program output:
```
Pool available=0 inUse=0
Checked out Oliphaunt id=1
Pool available=0 inUse=1
Checked out Oliphaunt id=2
Checked out Oliphaunt id=3
Pool available=0 inUse=3
Checking in Oliphaunt id=1
Checking in Oliphaunt id=2
Pool available=2 inUse=1
Checked out Oliphaunt id=2
Checked out Oliphaunt id=1
Pool available=0 inUse=3
```
## Class diagram ## Class diagram
![alt text](./etc/object-pool.png "Object Pool") ![alt text](./etc/object-pool.png "Object Pool")
## Applicability ## Applicability
Use the Object Pool pattern when Use the Object Pool pattern when
* The objects are expensive to create (allocation cost) * The objects are expensive to create (allocation cost).
* You need a large number of short-lived objects (memory fragmentation) * You need a large number of short-lived objects (memory fragmentation).

70
observer/README.md
View File

@ -10,17 +10,21 @@ tags:
--- ---
## Also known as ## Also known as
Dependents, Publish-Subscribe Dependents, Publish-Subscribe
## Intent ## Intent
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified
and updated automatically. Define a one-to-many dependency between objects so that when one object changes state, all its
dependents are notified and updated automatically.
## Explanation ## Explanation
Real world example Real world example
> In a land far away lives the races of hobbits and orcs. Both of them are mostly outdoors so they closely follow the changes in weather. One could say that they are constantly observing the weather. > In a land far away lives the races of hobbits and orcs. Both of them are mostly outdoors so they
> closely follow the changes in weather. One could say that they are constantly observing the
> weather.
In plain words In plain words
@ -28,11 +32,13 @@ In plain words
Wikipedia says Wikipedia says
> The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. > The observer pattern is a software design pattern in which an object, called the subject,
> maintains a list of its dependents, called observers, and notifies them automatically of any state
> changes, usually by calling one of their methods.
**Programmatic Example** **Programmatic Example**
Let's first introduce the weather observer interface and our races, orcs and hobbits. Let's first introduce the `WeatherObserver` interface and our races, `Orcs` and `Hobbits`.
```java ```java
public interface WeatherObserver { public interface WeatherObserver {
@ -58,11 +64,12 @@ public class Hobbits implements WeatherObserver {
public void update(WeatherType currentWeather) { public void update(WeatherType currentWeather) {
switch (currentWeather) { switch (currentWeather) {
LOGGER.info("The hobbits are facing " + currentWeather.getDescription() + " weather now"); LOGGER.info("The hobbits are facing " + currentWeather.getDescription() + " weather now");
}
} }
} }
``` ```
Then here's the weather that is constantly changing. Then here's the `Weather` that is constantly changing.
```java ```java
public class Weather { public class Weather {
@ -109,38 +116,47 @@ Here's the full example in action.
var weather = new Weather(); var weather = new Weather();
weather.addObserver(new Orcs()); weather.addObserver(new Orcs());
weather.addObserver(new Hobbits()); weather.addObserver(new Hobbits());
weather.timePasses();
weather.timePasses();
weather.timePasses();
weather.timePasses();
```
weather.timePasses(); Program output:
// The weather changed to rainy.
// The orcs are facing rainy weather now ```
// The hobbits are facing rainy weather now The weather changed to rainy.
weather.timePasses(); The orcs are facing rainy weather now
// The weather changed to windy. The hobbits are facing rainy weather now
// The orcs are facing windy weather now The weather changed to windy.
// The hobbits are facing windy weather now The orcs are facing windy weather now
weather.timePasses(); The hobbits are facing windy weather now
// The weather changed to cold. The weather changed to cold.
// The orcs are facing cold weather now The orcs are facing cold weather now
// The hobbits are facing cold weather now The hobbits are facing cold weather now
weather.timePasses(); The weather changed to sunny.
// The weather changed to sunny. The orcs are facing sunny weather now
// The orcs are facing sunny weather now The hobbits are facing sunny weather now
// The hobbits are facing sunny weather now
``` ```
## Class diagram ## Class diagram
![alt text](./etc/observer.png "Observer") ![alt text](./etc/observer.png "Observer")
## Applicability ## 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 Use the Observer pattern in any of the following situations:
* 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 * When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in
separate objects lets you vary and reuse them independently.
* When a change to one object requires changing others, and you don't know how many objects need to
be changed.
* When an object should be able to notify other objects without making assumptions about who these
objects are. In other words, you don't want these objects tightly coupled.
## Typical Use Case ## Typical Use Case
* Changing in one object leads to a change in other objects * Changing in one object leads to a change in other objects.
## Real world examples ## Real world examples

2
observer/src/main/java/com/iluwatar/observer/generic/Observable.java
View File

@ -35,7 +35,7 @@ import java.util.concurrent.CopyOnWriteArrayList;
*/ */
public abstract class Observable<S extends Observable<S, O, A>, O extends Observer<S, O, A>, A> { public abstract class Observable<S extends Observable<S, O, A>, O extends Observer<S, O, A>, A> {
protected List<O> observers; protected final List<O> observers;
public Observable() { public Observable() {
this.observers = new CopyOnWriteArrayList<>(); this.observers = new CopyOnWriteArrayList<>();