Merge branch 'master' of https://github.com/iluwatar/java-design-patterns

Author: chenhao

.all-contributorsrc

@@ -1176,6 +1176,15 @@
       "contributions": [
         "code"
       ]
+    },
+    {
+      "login": "fedorskvorcov",
+      "name": "Fedor Skvorcov",
+      "avatar_url": "https://avatars3.githubusercontent.com/u/43882212?v=4",
+      "profile": "https://github.com/fedorskvorcov",
+      "contributions": [
+        "code"
+      ]
     }
   ],
   "contributorsPerLine": 4,

.github/workflows/maven-ci.yml

@@ -33,10 +33,13 @@ on:
 jobs:
   build:
 
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-20.04
 
     steps:
     - uses: actions/checkout@v2
+      with:
+        # Disabling shallow clone for improving relevancy of SonarQube reporting
+        fetch-depth: 0
     - name: Set up JDK 11
       uses: actions/setup-java@v1
       with:
@@ -49,14 +52,11 @@ jobs:
           ${{ runner.os }}-maven-
     # Some tests need screen access
     - name: Install xvfb
-      run: sudo apt-get install xvfb
-    # SonarQube scan does not work for forked repositories
+      run: sudo apt-get install -y xvfb
+    # The SonarQube analysis is only for the master branch of the main repository.
+    # SonarQube scan does not work for forked repositories try changing it to xvfb-run mvn clean verify
     # See https://jira.sonarsource.com/browse/MMF-1371
-    - name: Build with Maven
-      if: github.ref != 'refs/heads/master'
-      run: xvfb-run mvn clean verify
     - name: Build with Maven and run SonarQube analysis
-      if: github.ref == 'refs/heads/master'
       run: xvfb-run mvn clean verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar
       env:
         # These two env variables are needed for sonar analysis

.github/workflows/maven-pr-builder.yml

@@ -33,7 +33,7 @@ on:
 jobs:
   build:
 
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-20.04
 
     steps:
     - uses: actions/checkout@v2
@@ -49,9 +49,9 @@ jobs:
           ${{ runner.os }}-maven-
     # Some tests need screen access
     - name: Install xvfb
-      run: sudo apt-get install xvfb
-    # SonarQube scan does not work for forked repositories
+      run: sudo apt-get install -y xvfb
+    # This worflow is only for building Pull Requests, the master branch runs Sonar analysis on the main repository.
+    # SonarQube scan does not work for forked repositories.
     # See https://jira.sonarsource.com/browse/MMF-1371
     - name: Build with Maven
-      if: github.ref != 'refs/heads/master'
       run: xvfb-run mvn clean verify

README.md

@@ -10,7 +10,7 @@
 [![Coverage](https://sonarcloud.io/api/project_badges/measure?project=iluwatar_java-design-patterns&metric=coverage)](https://sonarcloud.io/dashboard?id=iluwatar_java-design-patterns)
 [![Join the chat at https://gitter.im/iluwatar/java-design-patterns](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/iluwatar/java-design-patterns?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
 <!-- ALL-CONTRIBUTORS-BADGE:START - Do not remove or modify this section -->
-[![All Contributors](https://img.shields.io/badge/all_contributors-129-orange.svg?style=flat-square)](#contributors-)
+[![All Contributors](https://img.shields.io/badge/all_contributors-130-orange.svg?style=flat-square)](#contributors-)
 <!-- ALL-CONTRIBUTORS-BADGE:END -->
 
 # Introduction
@@ -263,6 +263,7 @@ This project is licensed under the terms of the MIT license.
   </tr>
   <tr>
     <td align="center"><a href="https://www.stefan-birkner.de"><img src="https://avatars1.githubusercontent.com/u/711349?v=4" width="100px;" alt=""/><br /><sub><b>Stefan Birkner</b></sub></a><br /><a href="https://github.com/iluwatar/java-design-patterns/commits?author=stefanbirkner" title="Code">💻</a></td>
+    <td align="center"><a href="https://github.com/fedorskvorcov"><img src="https://avatars3.githubusercontent.com/u/43882212?v=4" width="100px;" alt=""/><br /><sub><b>Fedor Skvorcov</b></sub></a><br /><a href="https://github.com/iluwatar/java-design-patterns/commits?author=fedorskvorcov" title="Code">💻</a></td>
   </tr>
 </table>
 

callback/README.md

@@ -9,22 +9,26 @@ tags:
 ---
 
 ## 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.
+
+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.
 
 ## Explanation
 
 Real world example
 
-> 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.     
+> 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.     
 
 In plain words
 
 > Callback is a method passed to the executor which will be called at defined moment. 
 
 Wikipedia says
 
-> 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.
+> 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.
 
 **Programmatic Example**
 
@@ -61,21 +65,23 @@ public final class SimpleTask extends Task {
 }
 ```
 
-Finally here's how we execute a task and receive a callback when it's finished.
+Finally, here's how we execute a task and receive a callback when it's finished.
 
 ```java
     var task = new SimpleTask();
     task.executeWith(() -> LOGGER.info("I'm done now."));
 ```
 
 ## Class diagram
+
 ![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.
+* [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.

callback/etc/callback.png

@@ -8,11 +8,6 @@ package com.iluwatar.callback {
   interface Callback {
     + call() {abstract}
   }
-  class LambdasApp {
-    - LOGGER : Logger {static}
-    - LambdasApp()
-    + main(args : String[]) {static}
-  }
   class SimpleTask {
     - LOGGER : Logger {static}
     + SimpleTask()

callback/etc/callback.urm.puml

@@ -9,27 +9,32 @@ tags:
 ---
 
 ## 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.
+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.
 
 ## Explanation
 
 Real world example
 
-> 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.
+> 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.
 
 In plain words
 
-> 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.
+> It helps to build a chain of objects. A request enters from one end and keeps going from an object 
+> to another until it finds a suitable handler.
 
 Wikipedia says
 
-> 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.
+> 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.
 
 **Programmatic Example**
 
-Translating our example with orcs from above. First we have the request class
+Translating our example with the orcs from above. First we have the `Request` class:
 
 ```java
 public class Request {
@@ -140,14 +145,16 @@ king.makeRequest(new Request(RequestType.COLLECT_TAX, "collect tax")); // Orc so
 ```
 
 ## Class diagram
+
 ![alt text](./etc/chain.urm.png "Chain of Responsibility class diagram")
 
 ## 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
+* 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
 

chain/README.md

@@ -12,32 +12,43 @@ tags:
 
 ## Intent
 
-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.
+Handle costly remote 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.
 
 ## Explanation
 
 Real world example
 
-> 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. 
+> Imagine a web application that has both local files/images and remote 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 
+> causing 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. 
 
 In plain words
 
-> 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.
+> Circuit Breaker allows graceful handling of failed remote services. It's especially 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.
 
 Wikipedia says
 
-> **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.
-
-So, how does this all come together?
+> 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.
 
 ## Programmatic Example
-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.
+
+So, how does this all come together? With the above example in mind we will imitate the 
+functionality in a simple example. A monitoring service mimics the web app and makes both local and 
+remote calls.
 
 The service architecture is as follows:
 
 ![alt text](./etc/ServiceDiagram.PNG "Service Diagram")
 
-In terms of code, the End user application is:
+In terms of code, the end user application is:
 
 ```java
 public class App {
@@ -62,7 +73,7 @@ public class App {
 }
 ```
 
-The monitoring service is: 
+The monitoring service: 
 
 ``` java
 public class MonitoringService {
@@ -80,7 +91,8 @@ public class MonitoringService {
   }
 }
 ```
-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:
+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:
 
 ```java
 public class CircuitBreaker {
@@ -155,24 +167,27 @@ public class CircuitBreaker {
 }
 ```
 
-How does the above pattern prevent failures? Let's understand via this finite state machine implemented by it.
+How does the above pattern prevent failures? Let's understand via this finite state machine 
+implemented by it.
 
 ![alt text](./etc/StateDiagram.PNG "State Diagram")
 
-- We initialize the Circuit Breaker object with certain parameters: **timeout**, **failureThreshold** and **retryTimePeriod** which help determine how resilient the API is.
-- Initially, we are in the **closed** state and the remote call to API happens.
+- We initialize the Circuit Breaker object with certain parameters: `timeout`, `failureThreshold` and `retryTimePeriod` which help determine how resilient the API is.
+- Initially, we are in the `closed` state and nos remote calls to the API have occurred.
 - Every time the call succeeds, we reset the state to as it was in the beginning.
-- 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```)
-- 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. 
+- 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```)
+- 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. 
 
 ## Class diagram
+
 ![alt text](./etc/circuit-breaker.urm.png "Circuit Breaker class diagram")
 
 ## Applicability
+
 Use the Circuit Breaker pattern when
 
 - Building a fault-tolerant application where failure of some services shouldn't bring the entire application down.
-- Building an continuously incremental/continuous delivery application, as some of it's components can be upgraded without shutting it down entirely.
+- Building a continuously running (always-on) application, so that its components can be upgraded without shutting it down entirely.
 
 ## Related Patterns