Compare commits
2 Commits
factoryKit
...
updateTram
Author | SHA1 | Date | |
---|---|---|---|
5681340ec7 | |||
c66ca67201 |
@ -9,6 +9,10 @@ tags:
|
||||
- Reactive
|
||||
---
|
||||
|
||||
## Name
|
||||
|
||||
Event Aggregator
|
||||
|
||||
## 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
|
||||
@ -17,6 +21,136 @@ 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.
|
||||
|
||||
## Explanation
|
||||
|
||||
Real-world example
|
||||
|
||||
> King Joffrey sits on the iron throne and rules the seven kingdoms of Westeros. He receives most
|
||||
> of his critical information from King's Hand, the second in command. King's hand has many
|
||||
> close advisors himself, feeding him with relevant information about events occurring in the
|
||||
> kingdom.
|
||||
|
||||
In Plain Words
|
||||
|
||||
> Event Aggregator is an event mediator that collects events from multiple sources and delivers
|
||||
> them to registered observers.
|
||||
|
||||
**Programmatic Example**
|
||||
|
||||
In our programmatic example, we demonstrate the implementation of an event aggregator pattern. Some of
|
||||
the objects are event listeners, some are event emitters, and the event aggregator does both.
|
||||
|
||||
```java
|
||||
public interface EventObserver {
|
||||
void onEvent(Event e);
|
||||
}
|
||||
|
||||
public abstract class EventEmitter {
|
||||
|
||||
private final Map<Event, List<EventObserver>> observerLists;
|
||||
|
||||
public EventEmitter() {
|
||||
observerLists = new HashMap<>();
|
||||
}
|
||||
|
||||
public final void registerObserver(EventObserver obs, Event e) {
|
||||
...
|
||||
}
|
||||
|
||||
protected void notifyObservers(Event e) {
|
||||
...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`KingJoffrey` is listening to events from `KingsHand`.
|
||||
|
||||
```java
|
||||
@Slf4j
|
||||
public class KingJoffrey implements EventObserver {
|
||||
@Override
|
||||
public void onEvent(Event e) {
|
||||
LOGGER.info("Received event from the King's Hand: {}", e.toString());
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`KingsHand` is listening to events from his subordinates `LordBaelish`, `LordVarys`, and `Scout`.
|
||||
Whatever he hears from them, he delivers to `KingJoffrey`.
|
||||
|
||||
```java
|
||||
public class KingsHand extends EventEmitter implements EventObserver {
|
||||
|
||||
public KingsHand() {
|
||||
}
|
||||
|
||||
public KingsHand(EventObserver obs, Event e) {
|
||||
super(obs, e);
|
||||
}
|
||||
|
||||
@Override
|
||||
public void onEvent(Event e) {
|
||||
notifyObservers(e);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
For example, `LordVarys` finds a traitor every Sunday and notifies the `KingsHand`.
|
||||
|
||||
```java
|
||||
@Slf4j
|
||||
public class LordVarys extends EventEmitter implements EventObserver {
|
||||
@Override
|
||||
public void timePasses(Weekday day) {
|
||||
if (day == Weekday.SATURDAY) {
|
||||
notifyObservers(Event.TRAITOR_DETECTED);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The following snippet demonstrates how the objects are constructed and wired together.
|
||||
|
||||
```java
|
||||
var kingJoffrey = new KingJoffrey();
|
||||
|
||||
var kingsHand = new KingsHand();
|
||||
kingsHand.registerObserver(kingJoffrey, Event.TRAITOR_DETECTED);
|
||||
kingsHand.registerObserver(kingJoffrey, Event.STARK_SIGHTED);
|
||||
kingsHand.registerObserver(kingJoffrey, Event.WARSHIPS_APPROACHING);
|
||||
kingsHand.registerObserver(kingJoffrey, Event.WHITE_WALKERS_SIGHTED);
|
||||
|
||||
var varys = new LordVarys();
|
||||
varys.registerObserver(kingsHand, Event.TRAITOR_DETECTED);
|
||||
varys.registerObserver(kingsHand, Event.WHITE_WALKERS_SIGHTED);
|
||||
|
||||
var scout = new Scout();
|
||||
scout.registerObserver(kingsHand, Event.WARSHIPS_APPROACHING);
|
||||
scout.registerObserver(varys, Event.WHITE_WALKERS_SIGHTED);
|
||||
|
||||
var baelish = new LordBaelish(kingsHand, Event.STARK_SIGHTED);
|
||||
|
||||
var emitters = List.of(
|
||||
kingsHand,
|
||||
baelish,
|
||||
varys,
|
||||
scout
|
||||
);
|
||||
|
||||
Arrays.stream(Weekday.values())
|
||||
.<Consumer<? super EventEmitter>>map(day -> emitter -> emitter.timePasses(day))
|
||||
.forEachOrdered(emitters::forEach);
|
||||
```
|
||||
|
||||
The console output after running the example.
|
||||
|
||||
```
|
||||
18:21:52.955 [main] INFO com.iluwatar.event.aggregator.KingJoffrey - Received event from the King's Hand: Warships approaching
|
||||
18:21:52.960 [main] INFO com.iluwatar.event.aggregator.KingJoffrey - Received event from the King's Hand: White walkers sighted
|
||||
18:21:52.960 [main] INFO com.iluwatar.event.aggregator.KingJoffrey - Received event from the King's Hand: Stark sighted
|
||||
18:21:52.960 [main] INFO com.iluwatar.event.aggregator.KingJoffrey - Received event from the King's Hand: Traitor detected
|
||||
```
|
||||
|
||||
## Class diagram
|
||||

|
||||
|
||||
@ -26,9 +160,13 @@ 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
|
||||
Aggregator. As well as simplifying registration, an Event Aggregator also
|
||||
simplifies the memory management issues in using observers.
|
||||
|
||||
## Related patterns
|
||||
|
||||
* [Observer](https://java-design-patterns.com/patterns/observer/)
|
||||
|
||||
## Credits
|
||||
|
||||
* [Martin Fowler - Event Aggregator](http://martinfowler.com/eaaDev/EventAggregator.html)
|
||||
|
@ -10,115 +10,19 @@ tags:
|
||||
---
|
||||
|
||||
## Intent
|
||||
|
||||
Define a factory of immutable content with separated builder and factory interfaces.
|
||||
|
||||
## Explanation
|
||||
|
||||
Real-world example
|
||||
|
||||
> Imagine a magical weapon factory that can create any type of weapon wished for. When the factory
|
||||
> is unboxed, the master recites the weapon types needed to prepare it. After that, any of those
|
||||
> weapon types can be summoned in an instant.
|
||||
|
||||
In plain words
|
||||
|
||||
> Factory kit is a configurable object builder.
|
||||
|
||||
**Programmatic Example**
|
||||
|
||||
Let's first define the simple `Weapon` hierarchy.
|
||||
|
||||
```java
|
||||
public interface Weapon {
|
||||
}
|
||||
|
||||
public enum WeaponType {
|
||||
SWORD,
|
||||
AXE,
|
||||
BOW,
|
||||
SPEAR
|
||||
}
|
||||
|
||||
public class Sword implements Weapon {
|
||||
@Override
|
||||
public String toString() {
|
||||
return "Sword";
|
||||
}
|
||||
}
|
||||
|
||||
// Axe, Bow, and Spear are defined similarly
|
||||
```
|
||||
|
||||
Next, we define a functional interface that allows adding a builder with a name to the factory.
|
||||
|
||||
```java
|
||||
public interface Builder {
|
||||
void add(WeaponType name, Supplier<Weapon> supplier);
|
||||
}
|
||||
```
|
||||
|
||||
The meat of the example is the `WeaponFactory` interface that effectively implements the factory
|
||||
kit pattern. The method `#factory` is used to configure the factory with the classes it needs to
|
||||
be able to construct. The method `#create` is then used to create object instances.
|
||||
|
||||
```java
|
||||
public interface WeaponFactory {
|
||||
|
||||
static WeaponFactory factory(Consumer<Builder> consumer) {
|
||||
var map = new HashMap<WeaponType, Supplier<Weapon>>();
|
||||
consumer.accept(map::put);
|
||||
return name -> map.get(name).get();
|
||||
}
|
||||
|
||||
Weapon create(WeaponType name);
|
||||
}
|
||||
```
|
||||
|
||||
Now, we can show how `WeaponFactory` can be used.
|
||||
|
||||
```java
|
||||
var factory = WeaponFactory.factory(builder -> {
|
||||
builder.add(WeaponType.SWORD, Sword::new);
|
||||
builder.add(WeaponType.AXE, Axe::new);
|
||||
builder.add(WeaponType.SPEAR, Spear::new);
|
||||
builder.add(WeaponType.BOW, Bow::new);
|
||||
});
|
||||
var list = new ArrayList<Weapon>();
|
||||
list.add(factory.create(WeaponType.AXE));
|
||||
list.add(factory.create(WeaponType.SPEAR));
|
||||
list.add(factory.create(WeaponType.SWORD));
|
||||
list.add(factory.create(WeaponType.BOW));
|
||||
list.stream().forEach(weapon -> LOGGER.info("{}", weapon.toString()));
|
||||
```
|
||||
|
||||
Here is the console output when the example is run.
|
||||
|
||||
```
|
||||
21:15:49.709 [main] INFO com.iluwatar.factorykit.App - Axe
|
||||
21:15:49.713 [main] INFO com.iluwatar.factorykit.App - Spear
|
||||
21:15:49.713 [main] INFO com.iluwatar.factorykit.App - Sword
|
||||
21:15:49.713 [main] INFO com.iluwatar.factorykit.App - Bow
|
||||
```
|
||||
|
||||
## Class diagram
|
||||
|
||||

|
||||
|
||||
## Applicability
|
||||
|
||||
Use the Factory Kit pattern when
|
||||
|
||||
* The factory class can't anticipate the types of objects it must create
|
||||
* A new instance of a custom builder is needed instead of a global one
|
||||
* The types of objects that the factory can build need to be defined outside the class
|
||||
* The builder and creator interfaces need to be separated
|
||||
|
||||
## Related patterns
|
||||
|
||||
* [Builder](https://java-design-patterns.com/patterns/builder/)
|
||||
* [Factory](https://java-design-patterns.com/patterns/factory/)
|
||||
* a class can't anticipate the class of objects it must create
|
||||
* you just want a new instance of a custom builder instead of the global one
|
||||
* you explicitly want to define types of objects, that factory can build
|
||||
* you want a separated builder and creator interface
|
||||
|
||||
## Credits
|
||||
|
||||
* [Design Pattern Reloaded by Remi Forax](https://www.youtube.com/watch?v=-k2X7guaArU)
|
||||
* [Design Pattern Reloaded by Remi Forax: ](https://www.youtube.com/watch?v=-k2X7guaArU)
|
||||
|
@ -23,16 +23,14 @@
|
||||
|
||||
package com.iluwatar.factorykit;
|
||||
|
||||
import java.util.ArrayList;
|
||||
|
||||
import lombok.extern.slf4j.Slf4j;
|
||||
|
||||
/**
|
||||
* Factory kit is a creational pattern that defines a factory of immutable content with separated
|
||||
* Factory-kit is a creational pattern which defines a factory of immutable content with separated
|
||||
* builder and factory interfaces to deal with the problem of creating one of the objects specified
|
||||
* directly in the factory kit instance.
|
||||
* directly in the factory-kit instance.
|
||||
*
|
||||
* <p>In the given example {@link WeaponFactory} represents the factory kit, that contains four
|
||||
* <p>In the given example {@link WeaponFactory} represents the factory-kit, that contains four
|
||||
* {@link Builder}s for creating new objects of the classes implementing {@link Weapon} interface.
|
||||
*
|
||||
* <p>Each of them can be called with {@link WeaponFactory#create(WeaponType)} method, with
|
||||
@ -54,11 +52,7 @@ public class App {
|
||||
builder.add(WeaponType.SPEAR, Spear::new);
|
||||
builder.add(WeaponType.BOW, Bow::new);
|
||||
});
|
||||
var list = new ArrayList<Weapon>();
|
||||
list.add(factory.create(WeaponType.AXE));
|
||||
list.add(factory.create(WeaponType.SPEAR));
|
||||
list.add(factory.create(WeaponType.SWORD));
|
||||
list.add(factory.create(WeaponType.BOW));
|
||||
list.stream().forEach(weapon -> LOGGER.info("{}", weapon.toString()));
|
||||
var axe = factory.create(WeaponType.AXE);
|
||||
LOGGER.info(axe.toString());
|
||||
}
|
||||
}
|
||||
|
@ -17,19 +17,19 @@ and to interleave the execution of functions without hard coding them together.
|
||||
## Explanation
|
||||
|
||||
Recursion is a frequently adopted technique for solving algorithmic problems in a divide and conquer
|
||||
style. For example calculating fibonacci accumulating sum and factorials. In these kinds of problems
|
||||
recursion is more straightforward than their loop counterpart. Furthermore recursion may need less
|
||||
code and looks more concise. There is a saying that every recursion problem can be solved using
|
||||
a loop with the cost of writing code that is more difficult to understand.
|
||||
style. For example, calculating Fibonacci accumulating sum and factorials. In these kinds of
|
||||
problems, recursion is more straightforward than its loop counterpart. Furthermore, recursion may
|
||||
need less code and looks more concise. There is a saying that every recursion problem can be solved
|
||||
using a loop with the cost of writing code that is more difficult to understand.
|
||||
|
||||
However recursion type solutions have one big caveat. For each recursive call it typically needs
|
||||
However, recursion-type solutions have one big caveat. For each recursive call, it typically needs
|
||||
an intermediate value stored and there is a limited amount of stack memory available. Running out of
|
||||
stack memory creates a stack overflow error and halts the program execution.
|
||||
|
||||
Trampoline pattern is a trick that allows us define recursive algorithms in Java without blowing the
|
||||
Trampoline pattern is a trick that allows defining recursive algorithms in Java without blowing the
|
||||
stack.
|
||||
|
||||
Real world example
|
||||
Real-world example
|
||||
|
||||
> A recursive Fibonacci calculation without the stack overflow problem using the Trampoline pattern.
|
||||
|
||||
@ -105,24 +105,26 @@ public interface Trampoline<T> {
|
||||
Using the `Trampoline` to get Fibonacci values.
|
||||
|
||||
```java
|
||||
public static Trampoline<Integer> loop(int times, int prod) {
|
||||
public static void main(String[] args) {
|
||||
LOGGER.info("Start calculating war casualties");
|
||||
var result = loop(10, 1).result();
|
||||
LOGGER.info("The number of orcs perished in the war: {}", result);
|
||||
}
|
||||
|
||||
public static Trampoline<Integer> loop(int times, int prod) {
|
||||
if (times == 0) {
|
||||
return Trampoline.done(prod);
|
||||
return Trampoline.done(prod);
|
||||
} else {
|
||||
return Trampoline.more(() -> loop(times - 1, prod * times));
|
||||
return Trampoline.more(() -> loop(times - 1, prod * times));
|
||||
}
|
||||
}
|
||||
|
||||
log.info("start pattern");
|
||||
var result = loop(10, 1).result();
|
||||
log.info("result {}", result);
|
||||
}
|
||||
```
|
||||
|
||||
Program output:
|
||||
|
||||
```
|
||||
start pattern
|
||||
result 3628800
|
||||
19:22:24.462 [main] INFO com.iluwatar.trampoline.TrampolineApp - Start calculating war casualties
|
||||
19:22:24.472 [main] INFO com.iluwatar.trampoline.TrampolineApp - The number of orcs perished in the war: 3628800
|
||||
```
|
||||
|
||||
## Class diagram
|
||||
@ -133,8 +135,8 @@ result 3628800
|
||||
|
||||
Use the Trampoline pattern when
|
||||
|
||||
* For implementing tail recursive function. This pattern allows to switch on a stackless operation.
|
||||
* For interleaving the execution of two or more functions on the same thread.
|
||||
* For implementing tail-recursive functions. This pattern allows to switch on a stackless operation.
|
||||
* For interleaving execution of two or more functions on the same thread.
|
||||
|
||||
## Known uses
|
||||
|
||||
|
@ -107,6 +107,4 @@ public interface Trampoline<T> {
|
||||
}
|
||||
};
|
||||
}
|
||||
|
||||
|
||||
}
|
||||
|
@ -39,9 +39,9 @@ public class TrampolineApp {
|
||||
* Main program for showing pattern. It does loop with factorial function.
|
||||
*/
|
||||
public static void main(String[] args) {
|
||||
LOGGER.info("start pattern");
|
||||
LOGGER.info("Start calculating war casualties");
|
||||
var result = loop(10, 1).result();
|
||||
LOGGER.info("result {}", result);
|
||||
LOGGER.info("The number of orcs perished in the war: {}", result);
|
||||
|
||||
}
|
||||
|
||||
@ -55,5 +55,4 @@ public class TrampolineApp {
|
||||
return Trampoline.more(() -> loop(times - 1, prod * times));
|
||||
}
|
||||
}
|
||||
|
||||
}
|
||||
|
Reference in New Issue
Block a user