Skip to content

Commit 67d1d16

Browse files
committed
Update README.md
1 parent bc35911 commit 67d1d16

File tree

3 files changed

+74
-36
lines changed

3 files changed

+74
-36
lines changed

object-pool/README.md

+33-11
Original file line numberDiff line numberDiff line change
@@ -10,28 +10,31 @@ tags:
1010
---
1111

1212
## Intent
13-
When objects are expensive to create and they are needed only for
14-
short periods of time it is advantageous to utilize the Object Pool pattern.
15-
The Object Pool provides a cache for instantiated objects tracking which ones
16-
are in use and which are available.
13+
14+
When objects are expensive to create and they are needed only for short periods of time it is
15+
advantageous to utilize the Object Pool pattern. The Object Pool provides a cache for instantiated
16+
objects tracking which ones are in use and which are available.
1717

1818
## Explanation
1919

2020
Real world example
2121

22-
> 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.
22+
> In our war game we need to use oliphaunts, massive and mythic beasts, but the problem is that they
23+
> are extremely expensive to create. The solution is to create a pool of them, track which ones are
24+
> in-use, and instead of disposing them re-use the instances.
2325
2426
In plain words
2527

2628
> Object Pool manages a set of instances instead of creating and destroying them on demand.
2729
2830
Wikipedia says
2931

30-
> 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.
32+
> The object pool pattern is a software creational design pattern that uses a set of initialized
33+
> objects kept ready to use – a "pool" – rather than allocating and destroying them on demand.
3134
3235
**Programmatic Example**
3336

34-
Here's the basic Oliphaunt class. These are very expensive to create.
37+
Here's the basic `Oliphaunt` class. These giants are very expensive to create.
3538

3639
```java
3740
public class Oliphaunt {
@@ -60,7 +63,7 @@ public class Oliphaunt {
6063
}
6164
```
6265

63-
Next we present the Object Pool and more specifically Oliphaunt Pool.
66+
Next we present the `ObjectPool` and more specifically `OliphauntPool`.
6467

6568
```java
6669
public abstract class ObjectPool<T> {
@@ -100,7 +103,7 @@ public class OliphauntPool extends ObjectPool<Oliphaunt> {
100103
}
101104
```
102105

103-
And finally here's how we utilize the pool.
106+
Finally, here's how we utilize the pool.
104107

105108
```java
106109
var pool = new OliphauntPool();
@@ -113,11 +116,30 @@ And finally here's how we utilize the pool.
113116
var oliphaunt5 = pool.checkOut();
114117
```
115118

119+
Program output:
120+
121+
```
122+
Pool available=0 inUse=0
123+
Checked out Oliphaunt id=1
124+
Pool available=0 inUse=1
125+
Checked out Oliphaunt id=2
126+
Checked out Oliphaunt id=3
127+
Pool available=0 inUse=3
128+
Checking in Oliphaunt id=1
129+
Checking in Oliphaunt id=2
130+
Pool available=2 inUse=1
131+
Checked out Oliphaunt id=2
132+
Checked out Oliphaunt id=1
133+
Pool available=0 inUse=3
134+
```
135+
116136
## Class diagram
137+
117138
![alt text](./etc/object-pool.png "Object Pool")
118139

119140
## Applicability
141+
120142
Use the Object Pool pattern when
121143

122-
* The objects are expensive to create (allocation cost)
123-
* You need a large number of short-lived objects (memory fragmentation)
144+
* The objects are expensive to create (allocation cost).
145+
* You need a large number of short-lived objects (memory fragmentation).

observer/README.md

+40-24
Original file line numberDiff line numberDiff line change
@@ -10,29 +10,35 @@ tags:
1010
---
1111

1212
## Also known as
13+
1314
Dependents, Publish-Subscribe
1415

1516
## Intent
16-
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified
17-
and updated automatically.
17+
18+
Define a one-to-many dependency between objects so that when one object changes state, all its
19+
dependents are notified and updated automatically.
1820

1921
## Explanation
2022

2123
Real world example
2224

23-
> 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.
25+
> In a land far away lives the races of hobbits and orcs. Both of them are mostly outdoors so they
26+
> closely follow the changes in weather. One could say that they are constantly observing the
27+
> weather.
2428
2529
In plain words
2630

2731
> Register as an observer to receive state changes in the object.
2832
2933
Wikipedia says
3034

31-
> 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.
35+
> The observer pattern is a software design pattern in which an object, called the subject,
36+
> maintains a list of its dependents, called observers, and notifies them automatically of any state
37+
> changes, usually by calling one of their methods.
3238
3339
**Programmatic Example**
3440

35-
Let's first introduce the weather observer interface and our races, orcs and hobbits.
41+
Let's first introduce the `WeatherObserver` interface and our races, `Orcs` and `Hobbits`.
3642

3743
```java
3844
public interface WeatherObserver {
@@ -58,11 +64,12 @@ public class Hobbits implements WeatherObserver {
5864
public void update(WeatherType currentWeather) {
5965
switch (currentWeather) {
6066
LOGGER.info("The hobbits are facing " + currentWeather.getDescription() + " weather now");
67+
}
6168
}
6269
}
6370
```
6471

65-
Then here's the weather that is constantly changing.
72+
Then here's the `Weather` that is constantly changing.
6673

6774
```java
6875
public class Weather {
@@ -109,38 +116,47 @@ Here's the full example in action.
109116
var weather = new Weather();
110117
weather.addObserver(new Orcs());
111118
weather.addObserver(new Hobbits());
112-
113119
weather.timePasses();
114-
// The weather changed to rainy.
115-
// The orcs are facing rainy weather now
116-
// The hobbits are facing rainy weather now
117120
weather.timePasses();
118-
// The weather changed to windy.
119-
// The orcs are facing windy weather now
120-
// The hobbits are facing windy weather now
121121
weather.timePasses();
122-
// The weather changed to cold.
123-
// The orcs are facing cold weather now
124-
// The hobbits are facing cold weather now
125122
weather.timePasses();
126-
// The weather changed to sunny.
127-
// The orcs are facing sunny weather now
128-
// The hobbits are facing sunny weather now
123+
```
124+
125+
Program output:
126+
127+
```
128+
The weather changed to rainy.
129+
The orcs are facing rainy weather now
130+
The hobbits are facing rainy weather now
131+
The weather changed to windy.
132+
The orcs are facing windy weather now
133+
The hobbits are facing windy weather now
134+
The weather changed to cold.
135+
The orcs are facing cold weather now
136+
The hobbits are facing cold weather now
137+
The weather changed to sunny.
138+
The orcs are facing sunny weather now
139+
The hobbits are facing sunny weather now
129140
```
130141

131142
## Class diagram
143+
132144
![alt text](./etc/observer.png "Observer")
133145

134146
## Applicability
135-
Use the Observer pattern in any of the following situations
136147

137-
* When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently
138-
* When a change to one object requires changing others, and you don't know how many objects need to be changed
139-
* 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
148+
Use the Observer pattern in any of the following situations:
149+
150+
* When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in
151+
separate objects lets you vary and reuse them independently.
152+
* When a change to one object requires changing others, and you don't know how many objects need to
153+
be changed.
154+
* When an object should be able to notify other objects without making assumptions about who these
155+
objects are. In other words, you don't want these objects tightly coupled.
140156

141157
## Typical Use Case
142158

143-
* Changing in one object leads to a change in other objects
159+
* Changing in one object leads to a change in other objects.
144160

145161
## Real world examples
146162

observer/src/main/java/com/iluwatar/observer/generic/Observable.java

+1-1
Original file line numberDiff line numberDiff line change
@@ -35,7 +35,7 @@
3535
*/
3636
public abstract class Observable<S extends Observable<S, O, A>, O extends Observer<S, O, A>, A> {
3737

38-
protected List<O> observers;
38+
protected final List<O> observers;
3939

4040
public Observable() {
4141
this.observers = new CopyOnWriteArrayList<>();

0 commit comments

Comments
 (0)