You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[](https://gitter.im/iluwatar/java-design-patterns?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
12
12
<!-- ALL-CONTRIBUTORS-BADGE:START - Do not remove or modify this section -->
Copy file name to clipboardExpand all lines: callback/README.md
+12-6
Original file line number
Diff line number
Diff line change
@@ -9,22 +9,26 @@ tags:
9
9
---
10
10
11
11
## Intent
12
-
Callback is a piece of executable code that is passed as an argument to other code, which is expected to call back
13
-
(execute) the argument at some convenient time.
12
+
13
+
Callback is a piece of executable code that is passed as an argument to other code, which is
14
+
expected to call back (execute) the argument at some convenient time.
14
15
15
16
## Explanation
16
17
17
18
Real world example
18
19
19
-
> We need to be notified after executing task has finished. We pass a callback method for the executor and wait for it to call back on us.
20
+
> We need to be notified after executing task has finished. We pass a callback method for
21
+
> the executor and wait for it to call back on us.
20
22
21
23
In plain words
22
24
23
25
> Callback is a method passed to the executor which will be called at defined moment.
24
26
25
27
Wikipedia says
26
28
27
-
> In computer programming, a callback, also known as a "call-after" function, is any executable code that is passed as an argument to other code; that other code is expected to call back (execute) the argument at a given time.
29
+
> In computer programming, a callback, also known as a "call-after" function, is any executable
30
+
> code that is passed as an argument to other code; that other code is expected to call
31
+
> back (execute) the argument at a given time.
28
32
29
33
**Programmatic Example**
30
34
@@ -61,21 +65,23 @@ public final class SimpleTask extends Task {
61
65
}
62
66
```
63
67
64
-
Finally here's how we execute a task and receive a callback when it's finished.
68
+
Finally, here's how we execute a task and receive a callback when it's finished.
* when some arbitrary synchronous or asynchronous action must be performed after execution of some defined activity.
78
84
79
85
## Real world examples
80
86
81
-
*[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.
87
+
*[CyclicBarrier](http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/CyclicBarrier.html#CyclicBarrier%28int,%20java.lang.Runnable%29) constructor can accept a callback that will be triggered every time a barrier is tripped.
Copy file name to clipboardExpand all lines: chain/README.md
+17-10
Original file line number
Diff line number
Diff line change
@@ -9,27 +9,32 @@ tags:
9
9
---
10
10
11
11
## Intent
12
-
Avoid coupling the sender of a request to its receiver by giving
13
-
more than one object a chance to handle the request. Chain the receiving
14
-
objects and pass the request along the chain until an object handles it.
12
+
Avoid coupling the sender of a request to its receiver by giving more than one object a chance to
13
+
handle the request. Chain the receiving objects and pass the request along the chain until an object
14
+
handles it.
15
15
16
16
## Explanation
17
17
18
18
Real world example
19
19
20
-
> The Orc King gives loud orders to his army. The closest one to react is the commander, then officer and then soldier. The commander, officer and soldier here form a chain of responsibility.
20
+
> The Orc King gives loud orders to his army. The closest one to react is the commander, then
21
+
> officer and then soldier. The commander, officer and soldier here form a chain of responsibility.
21
22
22
23
In plain words
23
24
24
-
> It helps building a chain of objects. Request enters from one end and keeps going from object to object till it finds the suitable handler.
25
+
> It helps to build a chain of objects. A request enters from one end and keeps going from an object
26
+
> to another until it finds a suitable handler.
25
27
26
28
Wikipedia says
27
29
28
-
> In object-oriented design, the chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain.
30
+
> In object-oriented design, the chain-of-responsibility pattern is a design pattern consisting of
31
+
> a source of command objects and a series of processing objects. Each processing object contains
32
+
> logic that defines the types of command objects that it can handle; the rest are passed to the
33
+
> next processing object in the chain.
29
34
30
35
**Programmatic Example**
31
36
32
-
Translating our example with orcs from above. First we have the request class
37
+
Translating our example with the orcs from above. First we have the `Request` class:
Copy file name to clipboardExpand all lines: circuit-breaker/README.md
+31-16
Original file line number
Diff line number
Diff line change
@@ -12,32 +12,43 @@ tags:
12
12
13
13
## Intent
14
14
15
-
Handle costly remote *procedure/service* calls in such a way that the failure of a **single** service/component cannot bring the whole application down, and we can reconnect to the service as soon as possible.
15
+
Handle costly remote service calls in such a way that the failure of a single service/component
16
+
cannot bring the whole application down, and we can reconnect to the service as soon as possible.
16
17
17
18
## Explanation
18
19
19
20
Real world example
20
21
21
-
> Imagine a Web App that has both local (example: files and images) and remote (example: database entries) to serve. The database might not be responding due to a variety of reasons, so if the application keeps trying to read from the database using multiple threads/processes, soon all of them will hang and our entire web application will crash. We should be able to detect this situation and show the user an appropriate message so that he/she can explore other parts of the app unaffected by the database failure without any problem.
22
+
> Imagine a web application that has both local files/images and remote database entries to serve.
23
+
> The database might not be responding due to a variety of reasons, so if the application keeps
24
+
> trying to read from the database using multiple threads/processes, soon all of them will hang
25
+
> causing our entire web application will crash. We should be able to detect this situation and show
26
+
> the user an appropriate message so that he/she can explore other parts of the app unaffected by
27
+
> the database failure.
22
28
23
29
In plain words
24
30
25
-
> Allows us to save resources when we know a remote service failed. Useful when all parts of our application are highly decoupled from each other, and failure of one component doesn't mean the other parts will stop working.
31
+
> Circuit Breaker allows graceful handling of failed remote services. It's especially useful when
32
+
> all parts of our application are highly decoupled from each other, and failure of one component
33
+
> doesn't mean the other parts will stop working.
26
34
27
35
Wikipedia says
28
36
29
-
> **Circuit breaker** is a design pattern used in modern software development. It is used to detect failures and encapsulates the logic of preventing a failure from constantly recurring, during maintenance, temporary external system failure or unexpected system difficulties.
30
-
31
-
So, how does this all come together?
37
+
> Circuit breaker is a design pattern used in modern software development. It is used to detect
38
+
> failures and encapsulates the logic of preventing a failure from constantly recurring, during
39
+
> maintenance, temporary external system failure or unexpected system difficulties.
32
40
33
41
## Programmatic Example
34
-
With the above example in mind we will imitate the functionality in a simple manner. We have two services: A *monitoring service* which will mimic the web app and will make both **local** and **remote** calls.
42
+
43
+
So, how does this all come together? With the above example in mind we will imitate the
44
+
functionality in a simple example. A monitoring service mimics the web app and makes both local and
@@ -80,7 +91,8 @@ public class MonitoringService {
80
91
}
81
92
}
82
93
```
83
-
As it can be seen, it does the call to get local resources directly, but it wraps the call to remote (costly) service in a circuit breaker object, which prevents faults as follows:
94
+
As it can be seen, it does the call to get local resources directly, but it wraps the call to
95
+
remote (costly) service in a circuit breaker object, which prevents faults as follows:
84
96
85
97
```java
86
98
publicclassCircuitBreaker {
@@ -155,24 +167,27 @@ public class CircuitBreaker {
155
167
}
156
168
```
157
169
158
-
How does the above pattern prevent failures? Let's understand via this finite state machine implemented by it.
170
+
How does the above pattern prevent failures? Let's understand via this finite state machine
- We initialize the Circuit Breaker object with certain parameters: **timeout**, **failureThreshold** and **retryTimePeriod** which help determine how resilient the API is.
163
-
- Initially, we are in the **closed** state and the remote call to API happens.
175
+
- We initialize the Circuit Breaker object with certain parameters: `timeout`, `failureThreshold` and `retryTimePeriod` which help determine how resilient the API is.
176
+
- Initially, we are in the `closed` state and nos remote calls to the API have occurred.
164
177
- Every time the call succeeds, we reset the state to as it was in the beginning.
165
-
- If the number of failures cross a certain threshold, we move to the **open** state, which acts just like an open circuit and prevents remote service calls from being made, thus saving resources. (Here, we return the response called ```stale response from API```)
166
-
- Once we exceed the retry timeout period, we move to the **half-open** state and make another call to the remote service again to check if the service is working so that we can serve fresh content. A *failure* sets it back to **open** state and another attempt is made after retry timeout period, while a *success* sets it to **closed** state so that everything starts working normally again.
178
+
- If the number of failures cross a certain threshold, we move to the `open` state, which acts just like an open circuit and prevents remote service calls from being made, thus saving resources. (Here, we return the response called ```stale response from API```)
179
+
- Once we exceed the retry timeout period, we move to the `half-open` state and make another call to the remote service again to check if the service is working so that we can serve fresh content. A failure sets it back to `open` state and another attempt is made after retry timeout period, while a success sets it to `closed` state so that everything starts working normally again.
167
180
168
181
## Class diagram
182
+
169
183
![alt text](./etc/circuit-breaker.urm.png"Circuit Breaker class diagram")
170
184
171
185
## Applicability
186
+
172
187
Use the Circuit Breaker pattern when
173
188
174
189
- Building a fault-tolerant application where failure of some services shouldn't bring the entire application down.
175
-
- Building an continuously incremental/continuous delivery application, as some of it's components can be upgraded without shutting it down entirely.
190
+
- Building a continuously running (always-on) application, so that its components can be upgraded without shutting it down entirely.
0 commit comments