docs: updates to several patterns

Author: iluwatar

abstract-document/README.md

@@ -19,7 +19,7 @@ The Abstract Document design pattern is a structural design pattern that aims to
 
 The Abstract Document pattern enables handling additional, non-static properties. This pattern uses concept of traits to enable type safety and separate properties of different classes into set of interfaces.
 
-Real world example
+Real-world example
 
 > Imagine a library system where books can have different formats and attributes: physical books, eBooks, and audiobooks. Each format has unique properties, such as page count for physical books, file size for eBooks, and duration for audiobooks. The Abstract Document design pattern allows the library system to manage these diverse formats flexibly. By using this pattern, the system can store and retrieve properties dynamically, without needing a rigid structure for each book type, making it easier to add new formats or attributes in the future without significant changes to the codebase.
 

active-object/README.md

@@ -99,21 +99,20 @@ public abstract class ActiveCreature {
 }
 ```
 
-We can see that any class that will extend the ActiveCreature class will have its own thread of control to invoke and execute methods.
+We can see that any class that will extend the `ActiveCreature` class will have its own thread of control to invoke and execute methods.
 
-For example, the Orc class:
+For example, the `Orc` class:
 
 ```java
 public class Orc extends ActiveCreature {
 
     public Orc(String name) {
         super(name);
     }
-
 }
 ```
 
-Now, we can create multiple creatures such as Orcs, tell them to eat and roam, and they will execute it on their own thread of control:
+Now, we can create multiple creatures such as orcs, tell them to eat and roam, and they will execute it on their own thread of control:
 
 ```java
 public class App implements Runnable {

acyclic-visitor/README.md

@@ -15,7 +15,7 @@ The Acyclic Visitor pattern decouples operations from an object hierarchy, allow
 
 ## Explanation
 
-Real world example
+Real-world example
 
 > An analogous real-world example of the Acyclic Visitor pattern is a museum guide system. Imagine a museum with various exhibits like paintings, sculptures, and historical artifacts. The museum has different types of guides (audio guide, human guide, virtual reality guide) that provide information about each exhibit. Instead of modifying the exhibits every time a new guide type is introduced, each guide implements an interface to visit different exhibit types. This way, the museum can add new types of guides without altering the existing exhibits, ensuring that the system remains extensible and maintainable without forming any dependency cycles.
 

adapter/README.md

@@ -106,10 +106,6 @@ The program outputs:
 10:25:08.074 [main] INFO com.iluwatar.adapter.FishingBoat -- The fishing boat is sailing
 ```
 
-## Class diagram
-
-![Adapter](./etc/adapter.urm.png "Adapter class diagram")
-
 ## Applicability
 
 Use the Adapter pattern when

aggregator-microservices/README.md

@@ -18,7 +18,7 @@ To aggregate responses from multiple microservices and return a consolidated res
 
 ## Explanation
 
-Real world example
+Real-world example
 
 > Imagine an online travel booking platform. When a user searches for a vacation package, the platform needs to gather information from several different services: flights, hotels, car rentals, and local attractions. Instead of the user making separate requests to each service, the platform employs an Aggregator Microservice. This microservice calls each of these services, collects their responses, and then consolidates the information into a single, unified response that is sent back to the user. This simplifies the user experience by providing all necessary travel details in one place and reduces the number of direct interactions the user needs to have with the underlying services.
 
@@ -98,10 +98,6 @@ curl http://localhost:50004/product
 {"title":"The Product Title.","productInventories":5}
 ```
 
-## Class diagram
-
-![Class diagram of the Aggregator Microservices Pattern](./aggregator-service/etc/aggregator-service.png "Aggregator Microservice")
-
 ## Applicability
 
 The Aggregator Microservices Design Pattern is particularly useful in scenarios where a client requires a composite response that is assembled from data provided by multiple microservices. Common use cases include e-commerce applications where product details, inventory, and reviews might be provided by separate services, or in dashboard applications where aggregated data from various services is displayed in a unified view.

ambassador/README.md

@@ -21,7 +21,7 @@ Provide a helper service instance on a client and offload common functionality a
 
 ## Explanation
 
-Real world example
+Real-world example
 
 > Imagine a busy hotel where guests frequently request restaurant reservations, event tickets, or transportation arrangements. Instead of each guest individually contacting these services, the hotel provides a concierge. The concierge handles these tasks on behalf of the guests, ensuring that reservations are made smoothly, tickets are booked on time, and transportation is scheduled efficiently.
 >
@@ -175,10 +175,6 @@ Failed to reach remote:(3)
 Service result:-1
 ```
 
-## Class diagram
-
-![Ambassador](./etc/ambassador.urm.png "Ambassador class diagram")
-
 ## Applicability
 
 * Cloud Native and Microservices Architectures: Especially useful in distributed systems where it's crucial to monitor, log, and secure inter-service communication.

anti-corruption-layer/README.md

@@ -129,10 +129,6 @@ public class LegacyShop {
 }
 ```
 
-## Class diagram
-
-![Anti-Corruption Layer](./etc/anti-corruption-layer.urm.png "Anti-Corruption Layer class diagram")
-
 ## Applicability
 
 Use this pattern when:

api-gateway/README.md

@@ -24,7 +24,7 @@ The API Gateway design pattern aims to provide a unified interface to a set of m
 
 ## Explanation
 
-Real world example
+Real-world example
 
 > In a large e-commerce platform, an API Gateway is used as the single entry point for all client requests. When a user visits the site or uses the mobile app, their requests for product information, user authentication, order processing, and payment are all routed through the API Gateway. The gateway handles tasks such as user authentication, rate limiting to prevent abuse, and logging for monitoring purposes. This setup simplifies the client interface and ensures that all backend microservices, like the product catalog service, user service, order service, and payment service, can evolve independently without affecting the client directly. This also enhances security by providing a centralized point to enforce policies and monitor traffic.
 
@@ -125,10 +125,6 @@ public class ApiGateway {
 }
 ```
 
-## Class diagram
-
-![API Gateway](./etc/api-gateway.png "API Gateway")
-
 ## Applicability
 
 * When building a microservices architecture, and there's a need to abstract the complexity of microservices from the client.

async-method-invocation/README.md

@@ -153,10 +153,6 @@ Here's the program console output.
 21:47:08.618[main]INFO com.iluwatar.async.method.invocation.App-Space rocket<50>launch complete
 ```
 
-# Class diagram
-
-![Async Method Invocation](./etc/async-method-invocation.urm.png "Async Method Invocation")
-
 ## Applicability
 
 Use the async method invocation pattern when

balking/README.md

@@ -15,7 +15,7 @@ Balking Pattern is used to prevent an object from executing a certain code if it
 
 ## Explanation
 
-Real world example
+Real-world example
 
 > A real-world analogy of the Balking design pattern can be seen in a laundry service. Imagine a washing machine at a laundromat that only starts washing clothes if the door is properly closed and locked. If a user tries to start the machine while the door is open, the machine balks and does nothing. This ensures that the washing process only begins when it is safe to do so, preventing water spillage and potential damage to the machine. Similarly, the Balking pattern in software design ensures that operations are only executed when the object is in an appropriate state, preventing erroneous actions and maintaining system stability.
 
@@ -31,7 +31,7 @@ Wikipedia says
 
 There's a start-button in a washing machine to initiate the laundry washing. When the washing machine is inactive the button works as expected, but if it's already washing the button does nothing.
 
-In this example implementation, `WashingMachine` is an object that has two states in which it can be: ENABLED and WASHING. If the machine is ENABLED, the state changes to WASHING using a thread-safe method. On the other hand, if it already has been washing and any other thread executes `wash()`it won't do that and returns without doing anything.
+In this example implementation, `WashingMachine` is an object that has two states in which it can be: ENABLED and WASHING. If the machine is ENABLED, the state changes to WASHING using a thread-safe method. On the other hand, if it already has been washing and any other thread executes `wash`it won't do that and returns without doing anything.
 
 Here are the relevant parts of the `WashingMachine` class.
 
@@ -114,10 +114,6 @@ Here is the console output of the program.
 14:02:52.324 [pool-1-thread-2] INFO com.iluwatar.balking.WashingMachine - 14: Washing completed.
 ```
 
-## Class diagram
-
-![Balking](./etc/balking.png "Balking")
-
 ## Applicability
 
 Use the Balking pattern when