From f80cc468b24d0b2ab7e03b8951ed4bec59f8c5bb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ilkka=20Sepp=C3=A4l=C3=A4?= Date: Fri, 29 Mar 2024 14:13:26 +0200 Subject: [PATCH] docs: collecting parameter docs + formatting --- abstract-document/README.md | 121 +++++--- abstract-factory/README.md | 110 ++++--- active-object/README.md | 103 +++--- acyclic-visitor/README.md | 28 +- adapter/README.md | 51 +-- aggregator-microservices/README.md | 54 +++- ambassador/README.md | 139 +++++---- anti-corruption-layer/README.md | 129 +++++--- api-gateway/README.md | 64 ++-- arrange-act-assert/README.md | 13 +- async-method-invocation/README.md | 156 +++++----- balking/README.md | 60 ++-- bridge/README.md | 82 +++-- builder/README.md | 117 ++++--- business-delegate/README.md | 39 ++- bytecode/README.md | 51 ++- caching/README.md | 92 ++++-- callback/README.md | 36 ++- chain-of-responsibility/README.md | 86 ++--- circuit-breaker/README.md | 293 +++++++++--------- client-session/README.md | 43 ++- collecting-parameter/README.md | 116 ++++--- .../collectingparameter/PrinterQueueTest.java | 2 - 23 files changed, 1191 insertions(+), 794 deletions(-) diff --git a/abstract-document/README.md b/abstract-document/README.md index 7c30819c7..f5bc50d99 100644 --- a/abstract-document/README.md +++ b/abstract-document/README.md @@ -2,23 +2,27 @@ title: Abstract Document category: Structural language: en -tag: - - Abstraction - - Extensibility - - Decoupling +tag: + - Abstraction + - Extensibility + - Decoupling --- ## Intent -The Abstract Document design pattern is a structural design pattern that aims to provide a consistent way to handle hierarchical and tree-like data structures by defining a common interface for various document types. It separates the core document structure from specific data formats, enabling dynamic updates and simplified maintenance. +The Abstract Document design pattern is a structural design pattern that aims to provide a consistent way to handle +hierarchical and tree-like data structures by defining a common interface for various document types. It separates the +core document structure from specific data formats, enabling dynamic updates and simplified maintenance. ## Explanation -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. +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 -> Consider a car that consists of multiple parts. However, we don't know if the specific car really has all the parts, or just some of them. Our cars are dynamic and extremely flexible. +> Consider a car that consists of multiple parts. However, we don't know if the specific car really has all the parts, +> or just some of them. Our cars are dynamic and extremely flexible. In plain words @@ -26,11 +30,15 @@ In plain words Wikipedia says -> An object-oriented structural design pattern for organizing objects in loosely typed key-value stores and exposing the data using typed views. The purpose of the pattern is to achieve a high degree of flexibility between components in a strongly typed language where new properties can be added to the object-tree on the fly, without losing the support of type-safety. The pattern makes use of traits to separate different properties of a class into different interfaces. +> An object-oriented structural design pattern for organizing objects in loosely typed key-value stores and exposing the +> data using typed views. The purpose of the pattern is to achieve a high degree of flexibility between components in a +> strongly typed language where new properties can be added to the object-tree on the fly, without losing the support of +> type-safety. The pattern makes use of traits to separate different properties of a class into different interfaces. **Programmatic Example** -Let's first define the base classes `Document` and `AbstractDocument`. They basically make the object hold a property map and any amount of child objects. +Let's first define the base classes `Document` and `AbstractDocument`. They basically make the object hold a property +map and any amount of child objects. ```java public interface Document { @@ -75,7 +83,9 @@ public abstract class AbstractDocument implements Document { ... } ``` -Next we define an enum `Property` and a set of interfaces for type, price, model and parts. This allows us to create static looking interface to our `Car` class. + +Next we define an enum `Property` and a set of interfaces for type, price, model and parts. This allows us to create +static looking interface to our `Car` class. ```java public enum Property { @@ -96,6 +106,7 @@ public interface HasPrice extends Document { return Optional.ofNullable((Number) get(Property.PRICE.toString())); } } + public interface HasModel extends Document { default Optional getModel() { @@ -127,40 +138,40 @@ And finally here's how we construct and use the `Car` in a full example. ```java LOGGER.info("Constructing parts and car"); - var wheelProperties = Map.of( - Property.TYPE.toString(), "wheel", - Property.MODEL.toString(), "15C", - Property.PRICE.toString(), 100L); + var wheelProperties=Map.of( + Property.TYPE.toString(),"wheel", + Property.MODEL.toString(),"15C", + Property.PRICE.toString(),100L); - var doorProperties = Map.of( - Property.TYPE.toString(), "door", - Property.MODEL.toString(), "Lambo", - Property.PRICE.toString(), 300L); + var doorProperties=Map.of( + Property.TYPE.toString(),"door", + Property.MODEL.toString(),"Lambo", + Property.PRICE.toString(),300L); - var carProperties = Map.of( - Property.MODEL.toString(), "300SL", - Property.PRICE.toString(), 10000L, - Property.PARTS.toString(), List.of(wheelProperties, doorProperties)); + var carProperties=Map.of( + Property.MODEL.toString(),"300SL", + Property.PRICE.toString(),10000L, + Property.PARTS.toString(),List.of(wheelProperties,doorProperties)); - var car = new Car(carProperties); + var car=new Car(carProperties); LOGGER.info("Here is our car:"); - LOGGER.info("-> model: {}", car.getModel().orElseThrow()); - LOGGER.info("-> price: {}", car.getPrice().orElseThrow()); + LOGGER.info("-> model: {}",car.getModel().orElseThrow()); + LOGGER.info("-> price: {}",car.getPrice().orElseThrow()); LOGGER.info("-> parts: "); - car.getParts().forEach(p -> LOGGER.info("\t{}/{}/{}", - p.getType().orElse(null), - p.getModel().orElse(null), - p.getPrice().orElse(null)) + car.getParts().forEach(p->LOGGER.info("\t{}/{}/{}", + p.getType().orElse(null), + p.getModel().orElse(null), + p.getPrice().orElse(null)) ); - // Constructing parts and car - // Here is our car: - // model: 300SL - // price: 10000 - // parts: - // wheel/15C/100 - // door/Lambo/300 +// Constructing parts and car +// Here is our car: +// model: 300SL +// price: 10000 +// parts: +// wheel/15C/100 +// door/Lambo/300 ``` ## Class diagram @@ -169,21 +180,38 @@ And finally here's how we construct and use the `Car` in a full example. ## Applicability -This pattern is particularly useful in scenarios where you have different types of documents that share some common attributes or behaviors, but also have unique attributes or behaviors specific to their individual types. Here are some scenarios where the Abstract Document design pattern can be applicable: +This pattern is particularly useful in scenarios where you have different types of documents that share some common +attributes or behaviors, but also have unique attributes or behaviors specific to their individual types. Here are some +scenarios where the Abstract Document design pattern can be applicable: -* Content Management Systems (CMS): In a CMS, you might have various types of content such as articles, images, videos, etc. Each type of content could have shared attributes like creation date, author, and tags, while also having specific attributes like image dimensions for images or video duration for videos. +* Content Management Systems (CMS): In a CMS, you might have various types of content such as articles, images, videos, + etc. Each type of content could have shared attributes like creation date, author, and tags, while also having + specific attributes like image dimensions for images or video duration for videos. -* File Systems: If you're designing a file system where different types of files need to be managed, such as documents, images, audio files, and directories, the Abstract Document pattern can help provide a consistent way to access attributes like file size, creation date, etc., while allowing for specific attributes like image resolution or audio duration. +* File Systems: If you're designing a file system where different types of files need to be managed, such as documents, + images, audio files, and directories, the Abstract Document pattern can help provide a consistent way to access + attributes like file size, creation date, etc., while allowing for specific attributes like image resolution or audio + duration. -* E-commerce Systems: An e-commerce platform might have different product types such as physical products, digital downloads, and subscriptions. Each type could share common attributes like name, price, and description, while having unique attributes like shipping weight for physical products or download link for digital products. +* E-commerce Systems: An e-commerce platform might have different product types such as physical products, digital + downloads, and subscriptions. Each type could share common attributes like name, price, and description, while having + unique attributes like shipping weight for physical products or download link for digital products. -* Medical Records Systems: In healthcare, patient records might include various types of data such as demographics, medical history, test results, and prescriptions. The Abstract Document pattern can help manage shared attributes like patient ID and date of birth, while accommodating specialized attributes like test results or prescribed medications. +* Medical Records Systems: In healthcare, patient records might include various types of data such as demographics, + medical history, test results, and prescriptions. The Abstract Document pattern can help manage shared attributes like + patient ID and date of birth, while accommodating specialized attributes like test results or prescribed medications. -* Configuration Management: When dealing with configuration settings for software applications, there can be different types of configuration elements, each with its own set of attributes. The Abstract Document pattern can be used to manage these configuration elements while ensuring a consistent way to access and manipulate their attributes. +* Configuration Management: When dealing with configuration settings for software applications, there can be different + types of configuration elements, each with its own set of attributes. The Abstract Document pattern can be used to + manage these configuration elements while ensuring a consistent way to access and manipulate their attributes. -* Educational Platforms: Educational systems might have various types of learning materials such as text-based content, videos, quizzes, and assignments. Common attributes like title, author, and publication date can be shared, while unique attributes like video duration or assignment due dates can be specific to each type. +* Educational Platforms: Educational systems might have various types of learning materials such as text-based content, + videos, quizzes, and assignments. Common attributes like title, author, and publication date can be shared, while + unique attributes like video duration or assignment due dates can be specific to each type. -* Project Management Tools: In project management applications, you could have different types of tasks like to-do items, milestones, and issues. The Abstract Document pattern could be used to handle general attributes like task name and assignee, while allowing for specific attributes like milestone date or issue priority. +* Project Management Tools: In project management applications, you could have different types of tasks like to-do + items, milestones, and issues. The Abstract Document pattern could be used to handle general attributes like task name + and assignee, while allowing for specific attributes like milestone date or issue priority. * Documents have diverse and evolving attribute structures. @@ -193,7 +221,10 @@ This pattern is particularly useful in scenarios where you have different types * Maintainability and flexibility are critical for the codebase. -The key idea behind the Abstract Document design pattern is to provide a flexible and extensible way to manage different types of documents or entities with shared and distinct attributes. By defining a common interface and implementing it across various document types, you can achieve a more organized and consistent approach to handling complex data structures. +The key idea behind the Abstract Document design pattern is to provide a flexible and extensible way to manage different +types of documents or entities with shared and distinct attributes. By defining a common interface and implementing it +across various document types, you can achieve a more organized and consistent approach to handling complex data +structures. ## Consequences diff --git a/abstract-factory/README.md b/abstract-factory/README.md index 4d5ff98a2..c7db990bd 100644 --- a/abstract-factory/README.md +++ b/abstract-factory/README.md @@ -3,9 +3,9 @@ title: Abstract Factory category: Creational language: en tag: - - Abstraction - - Decoupling - - Gang of Four + - Abstraction + - Decoupling + - Gang of Four --- ## Also known as @@ -14,25 +14,32 @@ Kit ## Intent -The Abstract Factory design pattern provides a way to create families of related objects without specifying their concrete classes. This allows for code that is independent of the specific classes of objects it uses, promoting flexibility and maintainability. +The Abstract Factory design pattern provides a way to create families of related objects without specifying their +concrete classes. This allows for code that is independent of the specific classes of objects it uses, promoting +flexibility and maintainability. ## Explanation Real-world example -> To create a kingdom we need objects with a common theme. The elven kingdom needs an elven king, elven castle, and elven army whereas the orcish kingdom needs an orcish king, orcish castle, and orcish army. There is a dependency between the objects in the kingdom. +> To create a kingdom we need objects with a common theme. The elven kingdom needs an elven king, elven castle, and +> elven army whereas the orcish kingdom needs an orcish king, orcish castle, and orcish army. There is a dependency +> between the objects in the kingdom. In plain words -> A factory of factories; a factory that groups the individual but related/dependent factories together without specifying their concrete classes. +> A factory of factories; a factory that groups the individual but related/dependent factories together without +> specifying their concrete classes. Wikipedia says -> The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes +> The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme +> without specifying their concrete classes **Programmatic Example** -Translating the kingdom example above. First of all, we have some interfaces and implementation for the objects in the kingdom. +Translating the kingdom example above. First of all, we have some interfaces and implementation for the objects in the +kingdom. ```java public interface Castle { @@ -50,20 +57,25 @@ public interface Army { // Elven implementations -> public class ElfCastle implements Castle { static final String DESCRIPTION = "This is the elven castle!"; + @Override public String getDescription() { return DESCRIPTION; } } + public class ElfKing implements King { static final String DESCRIPTION = "This is the elven king!"; + @Override public String getDescription() { return DESCRIPTION; } } + public class ElfArmy implements Army { static final String DESCRIPTION = "This is the elven Army!"; + @Override public String getDescription() { return DESCRIPTION; @@ -79,7 +91,9 @@ Then we have the abstraction and implementations for the kingdom factory. ```java public interface KingdomFactory { Castle createCastle(); + King createKing(); + Army createArmy(); } @@ -112,7 +126,7 @@ public class OrcKingdomFactory implements KingdomFactory { public King createKing() { return new OrcKing(); } - + @Override public Army createArmy() { return new OrcArmy(); @@ -120,64 +134,68 @@ public class OrcKingdomFactory implements KingdomFactory { } ``` -Now we have the abstract factory that lets us make a family of related objects i.e. elven kingdom factory creates elven castle, king and army, etc. +Now we have the abstract factory that lets us make a family of related objects i.e. elven kingdom factory creates elven +castle, king and army, etc. ```java -var factory = new ElfKingdomFactory(); -var castle = factory.createCastle(); -var king = factory.createKing(); -var army = factory.createArmy(); +var factory=new ElfKingdomFactory(); + var castle=factory.createCastle(); + var king=factory.createKing(); + var army=factory.createArmy(); -castle.getDescription(); -king.getDescription(); -army.getDescription(); + castle.getDescription(); + king.getDescription(); + army.getDescription(); ``` Program output: ```java This is the elven castle! -This is the elven king! -This is the elven Army! + This is the elven king! + This is the elven Army! ``` -Now, we can design a factory for our different kingdom factories. In this example, we created `FactoryMaker`, responsible for returning an instance of either `ElfKingdomFactory` or `OrcKingdomFactory`. The client can use `FactoryMaker` to create the desired concrete factory which, in turn, will produce different concrete objects (derived from `Army`, `King`, `Castle`). In this example, we also used an enum to parameterize which type of kingdom factory the client will ask for. +Now, we can design a factory for our different kingdom factories. In this example, we created `FactoryMaker`, +responsible for returning an instance of either `ElfKingdomFactory` or `OrcKingdomFactory`. The client can +use `FactoryMaker` to create the desired concrete factory which, in turn, will produce different concrete objects ( +derived from `Army`, `King`, `Castle`). In this example, we also used an enum to parameterize which type of kingdom +factory the client will ask for. ```java public static class FactoryMaker { - public enum KingdomType { - ELF, ORC - } + public enum KingdomType { + ELF, ORC + } - public static KingdomFactory makeFactory(KingdomType type) { - return switch (type) { - case ELF -> new ElfKingdomFactory(); - case ORC -> new OrcKingdomFactory(); - }; - } + public static KingdomFactory makeFactory(KingdomType type) { + return switch (type) { + case ELF -> new ElfKingdomFactory(); + case ORC -> new OrcKingdomFactory(); + }; + } } - public static void main(String[] args) { - var app = new App(); + public static void main(String[] args) { + var app = new App(); - LOGGER.info("Elf Kingdom"); - app.createKingdom(FactoryMaker.makeFactory(KingdomType.ELF)); - LOGGER.info(app.getArmy().getDescription()); - LOGGER.info(app.getCastle().getDescription()); - LOGGER.info(app.getKing().getDescription()); + LOGGER.info("Elf Kingdom"); + app.createKingdom(FactoryMaker.makeFactory(KingdomType.ELF)); + LOGGER.info(app.getArmy().getDescription()); + LOGGER.info(app.getCastle().getDescription()); + LOGGER.info(app.getKing().getDescription()); - LOGGER.info("Orc Kingdom"); - app.createKingdom(FactoryMaker.makeFactory(KingdomType.ORC)); - --similar use of the orc factory - } + LOGGER.info("Orc Kingdom"); + app.createKingdom(FactoryMaker.makeFactory(KingdomType.ORC)); + --similar use of the orc factory + } ``` ## Class diagram ![alt text](./etc/abstract-factory.urm.png "Abstract Factory class diagram") - ## Applicability Use the Abstract Factory pattern when @@ -185,7 +203,8 @@ Use the Abstract Factory pattern when * The system should be independent of how its products are created, composed, and represented * The system should be configured with one of the multiple families of products * The family of related product objects is designed to be used together, and you need to enforce this constraint -* You want to provide a class library of products, and you want to reveal just their interfaces, not their implementations +* You want to provide a class library of products, and you want to reveal just their interfaces, not their + implementations * The lifetime of the dependency is conceptually shorter than the lifetime of the consumer. * You need a run-time value to construct a particular dependency * You want to decide which product to call from a family at runtime. @@ -193,9 +212,10 @@ Use the Abstract Factory pattern when * When you need consistency among products * You don’t want to change existing code when adding new products or families of products to the program. -Example use cases +Example use cases -* Selecting to call to the appropriate implementation of FileSystemAcmeService or DatabaseAcmeService or NetworkAcmeService at runtime. +* Selecting to call to the appropriate implementation of FileSystemAcmeService or DatabaseAcmeService or + NetworkAcmeService at runtime. * Unit test case writing becomes much easier * UI tools for different OS @@ -219,7 +239,7 @@ Trade-offs ## Tutorials -* [Abstract Factory Pattern Tutorial](https://www.journaldev.com/1418/abstract-factory-design-pattern-in-java) +* [Abstract Factory Pattern Tutorial](https://www.journaldev.com/1418/abstract-factory-design-pattern-in-java) * [Refactoring Guru - Abstract Factory](https://refactoring.guru/design-patterns/abstract-factory) ## Known uses diff --git a/active-object/README.md b/active-object/README.md index 26e3e816a..6dc70d806 100644 --- a/active-object/README.md +++ b/active-object/README.md @@ -3,84 +3,88 @@ title: Active Object category: Concurrency language: en tag: - - Performance + - Performance --- - ## Intent -The Active Object design pattern provides a safe and reliable way to implement asynchronous behavior in concurrent systems. It achieves this by encapsulating tasks within objects that have their own thread and message queue. This separation keeps the main thread responsive and avoids issues like direct thread manipulation or shared state access. +The Active Object design pattern provides a safe and reliable way to implement asynchronous behavior in concurrent +systems. It achieves this by encapsulating tasks within objects that have their own thread and message queue. This +separation keeps the main thread responsive and avoids issues like direct thread manipulation or shared state access. ## Explanation -The class that implements the active object pattern will contain a self-synchronization mechanism without using 'synchronized' methods. +The class that implements the active object pattern will contain a self-synchronization mechanism without using ' +synchronized' methods. Real-world example ->The Orcs are known for their wildness and untameable soul. It seems like they have their own thread of control based on previous behavior. - -To implement a creature that has its own thread of control mechanism and expose its API only and not the execution itself, we can use the Active Object pattern. +> The Orcs are known for their wildness and untameable soul. It seems like they have their own thread of control based +> on previous behavior. +To implement a creature that has its own thread of control mechanism and expose its API only and not the execution +itself, we can use the Active Object pattern. **Programmatic Example** ```java -public abstract class ActiveCreature{ +public abstract class ActiveCreature { private final Logger logger = LoggerFactory.getLogger(ActiveCreature.class.getName()); private BlockingQueue requests; - + private String name; - + private Thread thread; public ActiveCreature(String name) { this.name = name; this.requests = new LinkedBlockingQueue(); thread = new Thread(new Runnable() { - @Override - public void run() { - while (true) { - try { - requests.take().run(); - } catch (InterruptedException e) { - logger.error(e.getMessage()); - } + @Override + public void run() { + while (true) { + try { + requests.take().run(); + } catch (InterruptedException e) { + logger.error(e.getMessage()); } } } + } ); thread.start(); } - + public void eat() throws InterruptedException { requests.put(new Runnable() { - @Override - public void run() { - logger.info("{} is eating!",name()); - logger.info("{} has finished eating!",name()); - } - } + @Override + public void run() { + logger.info("{} is eating!", name()); + logger.info("{} has finished eating!", name()); + } + } ); } public void roam() throws InterruptedException { requests.put(new Runnable() { - @Override - public void run() { - logger.info("{} has started to roam the wastelands.",name()); - } - } + @Override + public void run() { + logger.info("{} has started to roam the wastelands.", name()); + } + } ); } - + public String name() { return this.name; } } ``` -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: @@ -94,29 +98,30 @@ public class Orc extends ActiveCreature { } ``` -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 static void main(String[] args) { - var app = new App(); + public static void main(String[]args){ + var app=new App(); app.run(); - } - - @Override - public void run() { + } + +@Override +public void run(){ ActiveCreature creature; - try { - for (int i = 0;i < creatures;i++) { - creature = new Orc(Orc.class.getSimpleName().toString() + i); - creature.eat(); - creature.roam(); - } - Thread.sleep(1000); - } catch (InterruptedException e) { - logger.error(e.getMessage()); + try{ + for(int i=0;i We have a hierarchy of modem classes. The modems in this hierarchy need to be visited by an external algorithm based -> on filtering criteria (is it Unix or DOS compatible modem). +> We have a hierarchy of modem classes. The modems in this hierarchy need to be visited by an external algorithm based +> on filtering criteria (is it Unix or DOS compatible modem). In plain words @@ -24,7 +25,7 @@ In plain words [WikiWikiWeb](https://wiki.c2.com/?AcyclicVisitor) says -> The Acyclic Visitor pattern allows new functions to be added to existing class hierarchies without affecting those +> The Acyclic Visitor pattern allows new functions to be added to existing class hierarchies without affecting those > hierarchies, and without creating the dependency cycles that are inherent to the GangOfFour VisitorPattern. **Programmatic Example** @@ -38,6 +39,7 @@ public abstract class Modem { public class Zoom extends Modem { ... + @Override public void accept(ModemVisitor modemVisitor) { if (modemVisitor instanceof ZoomVisitor) { @@ -50,6 +52,7 @@ public class Zoom extends Modem { public class Hayes extends Modem { ... + @Override public void accept(ModemVisitor modemVisitor) { if (modemVisitor instanceof HayesVisitor) { @@ -80,10 +83,12 @@ public interface AllModemVisitor extends ZoomVisitor, HayesVisitor { public class ConfigureForDosVisitor implements AllModemVisitor { ... + @Override public void visit(Hayes hayes) { LOGGER.info(hayes + " used with Dos configurator."); } + @Override public void visit(Zoom zoom) { LOGGER.info(zoom + " used with Dos configurator."); @@ -92,6 +97,7 @@ public class ConfigureForDosVisitor implements AllModemVisitor { public class ConfigureForUnixVisitor implements ZoomVisitor { ... + @Override public void visit(Zoom zoom) { LOGGER.info(zoom + " used with Unix configurator."); @@ -102,10 +108,10 @@ public class ConfigureForUnixVisitor implements ZoomVisitor { Finally, here are the visitors in action. ```java - var conUnix = new ConfigureForUnixVisitor(); - var conDos = new ConfigureForDosVisitor(); - var zoom = new Zoom(); - var hayes = new Hayes(); + var conUnix=new ConfigureForUnixVisitor(); + var conDos=new ConfigureForDosVisitor(); + var zoom=new Zoom(); + var hayes=new Hayes(); hayes.accept(conDos); zoom.accept(conDos); hayes.accept(conUnix); @@ -130,7 +136,8 @@ Program output: This pattern can be used: * When you need to add a new function to an existing hierarchy without the need to alter or affect that hierarchy. -* When there are functions that operate upon a hierarchy, but which do not belong in the hierarchy itself. e.g. the ConfigureForDOS / ConfigureForUnix / ConfigureForX issue. +* When there are functions that operate upon a hierarchy, but which do not belong in the hierarchy itself. e.g. the + ConfigureForDOS / ConfigureForUnix / ConfigureForX issue. * When you need to perform very different operations on an object depending upon its type. * When the visited class hierarchy will be frequently extended with new derivatives of the Element class. * When the recompilation, relinking, retesting or redistribution of the derivatives of Element is very expensive. @@ -149,7 +156,8 @@ Benefits: Trade-offs: -* Violates [Liskov's Substitution Principle](https://java-design-patterns.com/principles/#liskov-substitution-principle) by showing that it can accept all visitors but actually only being interested in particular visitors. +* Violates [Liskov's Substitution Principle](https://java-design-patterns.com/principles/#liskov-substitution-principle) + by showing that it can accept all visitors but actually only being interested in particular visitors. * Parallel hierarchy of visitors has to be created for all members in visitable class hierarchy. ## Related patterns diff --git a/adapter/README.md b/adapter/README.md index 8de9f4138..0796d30f7 100644 --- a/adapter/README.md +++ b/adapter/README.md @@ -14,14 +14,18 @@ Wrapper ## Intent -The Adapter pattern converts the interface of a class into another interface that clients expect, enabling compatibility. +The Adapter pattern converts the interface of a class into another interface that clients expect, enabling +compatibility. ## Explanation Real-world example -> Consider that you have some pictures on your memory card and you need to transfer them to your computer. To transfer them, you need some kind of adapter that is compatible with your computer ports so that you can attach a memory card to your computer. In this case card reader is an adapter. -> Another example would be the famous power adapter; a three-legged plug can't be connected to a two-pronged outlet, it needs to use a power adapter that makes it compatible with the two-pronged outlets. +> Consider that you have some pictures on your memory card and you need to transfer them to your computer. To transfer +> them, you need some kind of adapter that is compatible with your computer ports so that you can attach a memory card to +> your computer. In this case card reader is an adapter. +> Another example would be the famous power adapter; a three-legged plug can't be connected to a two-pronged outlet, it +> needs to use a power adapter that makes it compatible with the two-pronged outlets. > Yet another example would be a translator translating words spoken by one person to another In plain words @@ -30,7 +34,9 @@ In plain words Wikipedia says -> In software engineering, the adapter pattern is a software design pattern that allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code. +> In software engineering, the adapter pattern is a software design pattern that allows the interface of an existing +> class to be used as another interface. It is often used to make existing classes work with others without modifying +> their source code. **Programmatic Example** @@ -57,6 +63,7 @@ And captain expects an implementation of `RowingBoat` interface to be able to mo public class Captain { private final RowingBoat rowingBoat; + // default constructor and setter for rowingBoat public Captain(RowingBoat rowingBoat) { this.rowingBoat = rowingBoat; @@ -68,9 +75,11 @@ public class Captain { } ``` -Now let's say the pirates are coming and our captain needs to escape but there is only a fishing boat available. We need to create an adapter that allows the captain to operate the fishing boat with his rowing boat skills. +Now let's say the pirates are coming and our captain needs to escape but there is only a fishing boat available. We need +to create an adapter that allows the captain to operate the fishing boat with his rowing boat skills. ```java + @Slf4j public class FishingBoatAdapter implements RowingBoat { @@ -90,8 +99,8 @@ public class FishingBoatAdapter implements RowingBoat { And now the `Captain` can use the `FishingBoat` to escape the pirates. ```java -var captain = new Captain(new FishingBoatAdapter()); -captain.row(); +var captain=new Captain(new FishingBoatAdapter()); + captain.row(); ``` ## Class diagram @@ -103,9 +112,13 @@ captain.row(); Use the Adapter pattern when * You want to use an existing class, and its interface does not match the one you need -* You want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces -* You need to use several existing subclasses, but it's impractical to adapt their interface by subclassing everyone. An object adapter can adapt the interface of its parent class. -* Most of the applications using third-party libraries use adapters as a middle layer between the application and the 3rd party library to decouple the application from the library. If another library has to be used only an adapter for the new library is required without having to change the application code. +* You want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't + necessarily have compatible interfaces +* You need to use several existing subclasses, but it's impractical to adapt their interface by subclassing everyone. An + object adapter can adapt the interface of its parent class. +* Most of the applications using third-party libraries use adapters as a middle layer between the application and the + 3rd party library to decouple the application from the library. If another library has to be used only an adapter for + the new library is required without having to change the application code. ## Tutorials @@ -114,20 +127,21 @@ Use the Adapter pattern when * [Baeldung](https://www.baeldung.com/java-adapter-pattern) * [GeeksforGeeks](https://www.geeksforgeeks.org/adapter-pattern/) - ## Consequences Class and object adapters have different trade-offs. A class adapter -* Adapts Adaptee to Target by committing to a concrete Adaptee class. As a consequence, a class adapter won’t work when we want to adapt a class and all its subclasses. -* Lets Adapter override some of Adaptee’s behavior since Adapter is a subclass of Adaptee. -* Introduces only one object, and no additional pointer indirection is needed to get to the adaptee. +* Adapts Adaptee to Target by committing to a concrete Adaptee class. As a consequence, a class adapter won’t work when + we want to adapt a class and all its subclasses. +* Lets Adapter override some of Adaptee’s behavior since Adapter is a subclass of Adaptee. +* Introduces only one object, and no additional pointer indirection is needed to get to the adaptee. -An object adapter - -* Lets a single Adapter work with many Adaptees, that is, the Adaptee itself and all of its subclasses (if any). The Adapter can also add functionality to all Adaptees at once. -* Makes it harder to override Adaptee behavior. It will require subclassing Adaptee and making the Adapter refer to the subclass rather than the Adaptee itself. +An object adapter +* Lets a single Adapter work with many Adaptees, that is, the Adaptee itself and all of its subclasses (if any). The + Adapter can also add functionality to all Adaptees at once. +* Makes it harder to override Adaptee behavior. It will require subclassing Adaptee and making the Adapter refer to the + subclass rather than the Adaptee itself. ## Real-world examples @@ -136,7 +150,6 @@ An object adapter * [java.util.Collections#enumeration()](https://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#enumeration-java.util.Collection-) * [javax.xml.bind.annotation.adapters.XMLAdapter](http://docs.oracle.com/javase/8/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html#marshal-BoundType-) - ## Credits * [Design Patterns: Elements of Reusable Object-Oriented Software](https://www.amazon.com/gp/product/0201633612/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0201633612&linkCode=as2&tag=javadesignpat-20&linkId=675d49790ce11db99d90bde47f1aeb59) diff --git a/aggregator-microservices/README.md b/aggregator-microservices/README.md index 732129e17..2673862f2 100644 --- a/aggregator-microservices/README.md +++ b/aggregator-microservices/README.md @@ -3,25 +3,29 @@ title: Aggregator Microservices category: Architectural language: en tag: -- API design -- Cloud distributed -- Decoupling -- Microservices + - API design + - Cloud distributed + - Decoupling + - Microservices --- ## Intent -Streamline client's interactions with system's microservices by providing a single aggregation point that consolidates data and responses from multiple services. This simplifies the client's communication with the system, improving efficiency and reducing complexity. +Streamline client's interactions with system's microservices by providing a single aggregation point that consolidates +data and responses from multiple services. This simplifies the client's communication with the system, improving +efficiency and reducing complexity. ## Explanation Real world example -> Our web marketplace needs information about products and their current inventory. It makes a call to an aggregator service, which, in turn, calls the product information and product inventory microservices, returning the combined information. +> Our web marketplace needs information about products and their current inventory. It makes a call to an aggregator +> service, which, in turn, calls the product information and product inventory microservices, returning the combined +> information. In plain words -> Aggregator Microservice collects pieces of data from various microservices and returns an aggregate for processing. +> Aggregator Microservice collects pieces of data from various microservices and returns an aggregate for processing. Stack Overflow says @@ -44,6 +48,7 @@ Next we can introduce our `Aggregator` microservice. It contains clients `Produc `ProductInventoryClient` for calling respective microservices. ```java + @RestController public class Aggregator { @@ -75,6 +80,7 @@ Here's the essence of information microservice implementation. Inventory microse inventory counts. ```java + @RestController public class InformationController { @RequestMapping(value = "/information", method = RequestMethod.GET) @@ -97,27 +103,41 @@ curl http://localhost:50004/product ## 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. +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. ## Consequences Benefits: -* Simplified Client: Clients interact with just one service rather than managing calls to multiple microservices, which simplifies client-side logic. -* Reduced Latency: By aggregating responses, the number of network calls is reduced, which can improve the application's overall latency. -* Decoupling: Clients are decoupled from the individual microservices, allowing for more flexibility in changing the microservices landscape without impacting clients. -* Centralized Logic: Aggregation allows for centralized transformation and logic application on the data collected from various services, which can be more efficient than handling it in the client or spreading it across multiple services. +* Simplified Client: Clients interact with just one service rather than managing calls to multiple microservices, which + simplifies client-side logic. +* Reduced Latency: By aggregating responses, the number of network calls is reduced, which can improve the application's + overall latency. +* Decoupling: Clients are decoupled from the individual microservices, allowing for more flexibility in changing the + microservices landscape without impacting clients. +* Centralized Logic: Aggregation allows for centralized transformation and logic application on the data collected from + various services, which can be more efficient than handling it in the client or spreading it across multiple services. Trade-offs: -* Single Point of Failure: The aggregator service can become a bottleneck or a single point of failure if not designed with high availability and scalability in mind. -* Complexity: Implementing an aggregator can introduce complexity, especially in terms of data aggregation logic and error handling when dealing with multiple services. +* Single Point of Failure: The aggregator service can become a bottleneck or a single point of failure if not designed + with high availability and scalability in mind. +* Complexity: Implementing an aggregator can introduce complexity, especially in terms of data aggregation logic and + error handling when dealing with multiple services. ## Related Patterns -* [API Gateway](https://java-design-patterns.com/patterns/api-gateway/): The Aggregator Microservices pattern is often used in conjunction with an API Gateway, which provides a single entry point for clients to access multiple microservices. -* [Composite](https://java-design-patterns.com/patterns/composite/): The Aggregator Microservices pattern can be seen as a form of the Composite pattern, where the composite is the aggregated response from multiple microservices. -* [Facade](https://java-design-patterns.com/patterns/facade/): The Aggregator Microservices pattern can be seen as a form of the Facade pattern, where the facade is the aggregator service that provides a simplified interface to the client. +* [API Gateway](https://java-design-patterns.com/patterns/api-gateway/): The Aggregator Microservices pattern is often + used in conjunction with an API Gateway, which provides a single entry point for clients to access multiple + microservices. +* [Composite](https://java-design-patterns.com/patterns/composite/): The Aggregator Microservices pattern can be seen as + a form of the Composite pattern, where the composite is the aggregated response from multiple microservices. +* [Facade](https://java-design-patterns.com/patterns/facade/): The Aggregator Microservices pattern can be seen as a + form of the Facade pattern, where the facade is the aggregator service that provides a simplified interface to the + client. ## Credits diff --git a/ambassador/README.md b/ambassador/README.md index b2902d7dd..5bd535f07 100644 --- a/ambassador/README.md +++ b/ambassador/README.md @@ -19,68 +19,71 @@ Provide a helper service instance on a client and offload common functionality a Real world example -> A remote service has many clients accessing a function it provides. The service is a legacy application and is -> impossible to update. Large numbers of requests from users are causing connectivity issues. New rules for request +> A remote service has many clients accessing a function it provides. The service is a legacy application and is +> impossible to update. Large numbers of requests from users are causing connectivity issues. New rules for request > frequency should be implemented along with latency checks and client-side logging. In plain words -> With the Ambassador pattern, we can implement less-frequent polling from clients along with latency checks and +> With the Ambassador pattern, we can implement less-frequent polling from clients along with latency checks and > logging. Microsoft documentation states -> An ambassador service can be thought of as an out-of-process proxy which is co-located with the client. This pattern -> can be useful for offloading common client connectivity tasks such as monitoring, logging, routing, -> security (such as TLS), and resiliency patterns in a language agnostic way. It is often used with legacy applications, -> or other applications that are difficult to modify, in order to extend their networking capabilities. It can also +> An ambassador service can be thought of as an out-of-process proxy which is co-located with the client. This pattern +> can be useful for offloading common client connectivity tasks such as monitoring, logging, routing, +> security (such as TLS), and resiliency patterns in a language agnostic way. It is often used with legacy applications, +> or other applications that are difficult to modify, in order to extend their networking capabilities. It can also > enable a specialized team to implement those features. **Programmatic Example** -With the above introduction in mind we will imitate the functionality in this example. We have an interface implemented +With the above introduction in mind we will imitate the functionality in this example. We have an interface implemented by the remote service as well as the ambassador service: ```java interface RemoteServiceInterface { - long doRemoteFunction(int value) throws Exception; + long doRemoteFunction(int value) throws Exception; } ``` A remote services represented as a singleton. ```java + @Slf4j public class RemoteService implements RemoteServiceInterface { - private static RemoteService service = null; + private static RemoteService service = null; - static synchronized RemoteService getRemoteService() { - if (service == null) { - service = new RemoteService(); - } - return service; + static synchronized RemoteService getRemoteService() { + if (service == null) { + service = new RemoteService(); + } + return service; + } + + private RemoteService() { + } + + @Override + public long doRemoteFunction(int value) { + long waitTime = (long) Math.floor(Math.random() * 1000); + + try { + sleep(waitTime); + } catch (InterruptedException e) { + LOGGER.error("Thread sleep interrupted", e); } - private RemoteService() {} - - @Override - public long doRemoteFunction(int value) { - long waitTime = (long) Math.floor(Math.random() * 1000); - - try { - sleep(waitTime); - } catch (InterruptedException e) { - LOGGER.error("Thread sleep interrupted", e); - } - - return waitTime >= 200 ? value * 10 : -1; - } + return waitTime >= 200 ? value * 10 : -1; + } } ``` A service ambassador adding additional features such as logging, latency checks ```java + @Slf4j public class ServiceAmbassador implements RemoteServiceInterface { private static final int RETRIES = 3; @@ -132,6 +135,7 @@ public class ServiceAmbassador implements RemoteServiceInterface { A client has a local service ambassador used to interact with the remote service: ```java + @Slf4j public class Client { private final ServiceAmbassador serviceAmbassador = new ServiceAmbassador(); @@ -160,15 +164,15 @@ public class App { Here's the output for running the example: ```java -Time taken (ms): 111 -Service result: 120 -Time taken (ms): 931 -Failed to reach remote: (1) -Time taken (ms): 665 -Failed to reach remote: (2) -Time taken (ms): 538 -Failed to reach remote: (3) -Service result: -1 +Time taken(ms):111 + Service result:120 + Time taken(ms):931 + Failed to reach remote:(1) + Time taken(ms):665 + Failed to reach remote:(2) + Time taken(ms):538 + Failed to reach remote:(3) + Service result:-1 ``` ## Class diagram @@ -177,8 +181,10 @@ Service result: -1 ## Applicability -* Cloud Native and Microservices Architectures: Especially useful in distributed systems where it's crucial to monitor, log, and secure inter-service communication. -* Legacy System Integration: Facilitates communication with newer services by handling necessary but non-core functionalities. +* Cloud Native and Microservices Architectures: Especially useful in distributed systems where it's crucial to monitor, + log, and secure inter-service communication. +* Legacy System Integration: Facilitates communication with newer services by handling necessary but non-core + functionalities. * Performance Enhancement: Can be used to cache results or compress data to improve communication efficiency. Typical use cases include: @@ -193,34 +199,57 @@ Typical use cases include: Benefits: -* Separation of Concerns: Offloads cross-cutting concerns from the service logic, leading to cleaner, more maintainable code. -* Reusable Infrastructure Logic: The ambassador pattern allows the same logic (e.g., logging, monitoring) to be reused across multiple services. -* Improved Security: Centralizes security features like SSL termination or authentication, reducing the risk of misconfiguration. +* Separation of Concerns: Offloads cross-cutting concerns from the service logic, leading to cleaner, more maintainable + code. +* Reusable Infrastructure Logic: The ambassador pattern allows the same logic (e.g., logging, monitoring) to be reused + across multiple services. +* Improved Security: Centralizes security features like SSL termination or authentication, reducing the risk of + misconfiguration. * Flexibility: Makes it easier to update or replace infrastructure concerns without modifying the service code. Trade-offs: * Increased Complexity: Adds another layer to the architecture, which can complicate the system design and debugging. -* Potential Performance Overhead: The additional network hop can introduce latency and overhead, particularly if not optimized. +* Potential Performance Overhead: The additional network hop can introduce latency and overhead, particularly if not + optimized. * Deployment Overhead: Requires additional resources and management for deploying and scaling ambassador services. ## Known uses -* Service Mesh Implementations: In a service mesh architecture, like Istio or Linkerd, the Ambassador pattern is often employed as a sidecar proxy that handles inter-service communications. This includes tasks such as service discovery, routing, load balancing, telemetry (metrics and tracing), and security (authentication and authorization). -* API Gateways: API gateways can use the Ambassador pattern to encapsulate common functionalities like rate limiting, caching, request shaping, and authentication. This allows backend services to focus on their core business logic without being burdened by these cross-cutting concerns. -* Logging and Monitoring: An Ambassador can aggregate logs and metrics from various services and forward them to centralized monitoring tools like Prometheus or ELK Stack (Elasticsearch, Logstash, Kibana). This simplifies the logging and monitoring setup for each service and provides a unified view of the system's health. -* Security: Security-related functionalities such as SSL/TLS termination, identity verification, and encryption can be managed by an Ambassador. This ensures consistent security practices across services and reduces the likelihood of security breaches due to misconfigurations. -* Resilience: The Ambassador can implement resilience patterns like circuit breakers, retries, and timeouts. For instance, Netflix's Hystrix library can be used within an Ambassador to prevent cascading failures in a microservices ecosystem. -* Database Proxy: Ambassadors can act as proxies for database connections, providing functionalities like connection pooling, read/write splitting for replicas, and query caching. This offloads significant complexity from the application services. -* Legacy System Integration: In scenarios where modern microservices need to communicate with legacy systems, an Ambassador can serve as an intermediary that translates protocols, handles necessary transformations, and implements modern security practices, easing the integration process. -* Network Optimization: For services deployed across different geographical locations or cloud regions, Ambassadors can optimize communication by compressing data, batching requests, or even implementing smart routing to reduce latency and costs. +* Service Mesh Implementations: In a service mesh architecture, like Istio or Linkerd, the Ambassador pattern is often + employed as a sidecar proxy that handles inter-service communications. This includes tasks such as service discovery, + routing, load balancing, telemetry (metrics and tracing), and security (authentication and authorization). +* API Gateways: API gateways can use the Ambassador pattern to encapsulate common functionalities like rate limiting, + caching, request shaping, and authentication. This allows backend services to focus on their core business logic + without being burdened by these cross-cutting concerns. +* Logging and Monitoring: An Ambassador can aggregate logs and metrics from various services and forward them to + centralized monitoring tools like Prometheus or ELK Stack (Elasticsearch, Logstash, Kibana). This simplifies the + logging and monitoring setup for each service and provides a unified view of the system's health. +* Security: Security-related functionalities such as SSL/TLS termination, identity verification, and encryption can be + managed by an Ambassador. This ensures consistent security practices across services and reduces the likelihood of + security breaches due to misconfigurations. +* Resilience: The Ambassador can implement resilience patterns like circuit breakers, retries, and timeouts. For + instance, Netflix's Hystrix library can be used within an Ambassador to prevent cascading failures in a microservices + ecosystem. +* Database Proxy: Ambassadors can act as proxies for database connections, providing functionalities like connection + pooling, read/write splitting for replicas, and query caching. This offloads significant complexity from the + application services. +* Legacy System Integration: In scenarios where modern microservices need to communicate with legacy systems, an + Ambassador can serve as an intermediary that translates protocols, handles necessary transformations, and implements + modern security practices, easing the integration process. +* Network Optimization: For services deployed across different geographical locations or cloud regions, Ambassadors can + optimize communication by compressing data, batching requests, or even implementing smart routing to reduce latency + and costs. * [Kubernetes-native API gateway for microservices](https://github.com/datawire/ambassador) ## Related patterns -* [Proxy](https://java-design-patterns.com/patterns/proxy/): Shares similarities with the proxy pattern, but the ambassador pattern specifically focuses on offloading ancillary functionalities. -* Sidecar: A similar pattern used in the context of containerized applications, where a sidecar container provides additional functionality to the main application container. -* [Decorator](https://java-design-patterns.com/patterns/decorator/): The decorator pattern is used to add functionality to an object dynamically, while the ambassador pattern is used to offload functionality to a separate object. +* [Proxy](https://java-design-patterns.com/patterns/proxy/): Shares similarities with the proxy pattern, but the + ambassador pattern specifically focuses on offloading ancillary functionalities. +* Sidecar: A similar pattern used in the context of containerized applications, where a sidecar container provides + additional functionality to the main application container. +* [Decorator](https://java-design-patterns.com/patterns/decorator/): The decorator pattern is used to add functionality + to an object dynamically, while the ambassador pattern is used to offload functionality to a separate object. ## Credits diff --git a/anti-corruption-layer/README.md b/anti-corruption-layer/README.md index bcffc3595..015dd0c45 100644 --- a/anti-corruption-layer/README.md +++ b/anti-corruption-layer/README.md @@ -16,21 +16,34 @@ tag: ## Intent -Implement a façade or adapter layer between different subsystems that don't share the same semantics. It translates between different data formats and systems, ensuring that the integration between systems does not lead to corruption of business logic or data integrity. +Implement a façade or adapter layer between different subsystems that don't share the same semantics. It translates +between different data formats and systems, ensuring that the integration between systems does not lead to corruption of +business logic or data integrity. ## Explanation ### Context and problem -Most applications rely on other systems for some data or functionality. For example, when a legacy application is migrated to a modern system, it may still need existing legacy resources. New features must be able to call the legacy system. This is especially true of gradual migrations, where different features of a larger application are moved to a modern system over time. +Most applications rely on other systems for some data or functionality. For example, when a legacy application is +migrated to a modern system, it may still need existing legacy resources. New features must be able to call the legacy +system. This is especially true of gradual migrations, where different features of a larger application are moved to a +modern system over time. -Often these legacy systems suffer from quality issues such as convoluted data schemas or obsolete APIs. The features and technologies used in legacy systems can vary widely from more modern systems. To interoperate with the legacy system, the new application may need to support outdated infrastructure, protocols, data models, APIs, or other features that you wouldn't otherwise put into a modern application. +Often these legacy systems suffer from quality issues such as convoluted data schemas or obsolete APIs. The features and +technologies used in legacy systems can vary widely from more modern systems. To interoperate with the legacy system, +the new application may need to support outdated infrastructure, protocols, data models, APIs, or other features that +you wouldn't otherwise put into a modern application. -Maintaining access between new and legacy systems can force the new system to adhere to at least some of the legacy system's APIs or other semantics. When these legacy features have quality issues, supporting them "corrupts" what might otherwise be a cleanly designed modern application. Similar issues can arise with any external system that your development team doesn't control, not just legacy systems. +Maintaining access between new and legacy systems can force the new system to adhere to at least some of the legacy +system's APIs or other semantics. When these legacy features have quality issues, supporting them "corrupts" what might +otherwise be a cleanly designed modern application. Similar issues can arise with any external system that your +development team doesn't control, not just legacy systems. ### Solution -Isolate the different subsystems by placing an anti-corruption layer between them. This layer translates communications between the two systems, allowing one system to remain unchanged while the other can avoid compromising its design and technological approach. +Isolate the different subsystems by placing an anti-corruption layer between them. This layer translates communications +between the two systems, allowing one system to remain unchanged while the other can avoid compromising its design and +technological approach. ### Programmatic example @@ -40,19 +53,25 @@ The example shows why the anti-corruption layer is needed. Here are 2 shop-ordering systems: `Legacy` and `Modern`. -The aforementioned systems have different domain models and have to operate simultaneously. Since they work independently the orders can come either from the `Legacy` or `Modern` system. Therefore, the system that receives the legacyOrder needs to check if the legacyOrder is valid and not present in the other system. Then it can place the legacyOrder in its own system. +The aforementioned systems have different domain models and have to operate simultaneously. Since they work +independently the orders can come either from the `Legacy` or `Modern` system. Therefore, the system that receives the +legacyOrder needs to check if the legacyOrder is valid and not present in the other system. Then it can place the +legacyOrder in its own system. -But for that, the system needs to know the domain model of the other system and to avoid that, the anti-corruption layer(ACL) is introduced. The ACL is a layer that translates the domain model of the `Legacy` system to the domain model of the `Modern` system and vice versa. Also, it hides all other operations with the other system, uncoupling the systems. +But for that, the system needs to know the domain model of the other system and to avoid that, the anti-corruption +layer(ACL) is introduced. The ACL is a layer that translates the domain model of the `Legacy` system to the domain model +of the `Modern` system and vice versa. Also, it hides all other operations with the other system, uncoupling the +systems. #### Domain model of the `Legacy` system ```java public class LegacyOrder { - private String id; - private String customer; - private String item; - private String qty; - private String price; + private String id; + private String customer; + private String item; + private String qty; + private String price; } ``` @@ -60,20 +79,22 @@ public class LegacyOrder { ```java public class ModernOrder { - private String id; - private Customer customer; + private String id; + private Customer customer; - private Shipment shipment; + private Shipment shipment; - private String extra; + private String extra; } + public class Customer { - private String address; + private String address; } + public class Shipment { - private String item; - private String qty; - private String price; + private String item; + private String qty; + private String price; } ``` @@ -82,44 +103,46 @@ public class Shipment { ```java public class AntiCorruptionLayer { - @Autowired - private ModernShop modernShop; + @Autowired + private ModernShop modernShop; - @Autowired - private LegacyShop legacyShop; + @Autowired + private LegacyShop legacyShop; - public Optional findOrderInModernSystem(String id) { - return modernShop.findOrder(id).map(o -> /* map to legacyOrder*/); - } + public Optional findOrderInModernSystem(String id) { + return modernShop.findOrder(id).map(o -> /* map to legacyOrder*/); + } - public Optional findOrderInLegacySystem(String id) { - return legacyShop.findOrder(id).map(o -> /* map to modernOrder*/); - } + public Optional findOrderInLegacySystem(String id) { + return legacyShop.findOrder(id).map(o -> /* map to modernOrder*/); + } } ``` #### The connection -Wherever the `Legacy` or `Modern` system needs to communicate with the counterpart the ACL needs to be used to avoid corrupting the current domain model. The example below shows how the `Legacy` system places an order with a validation from the `Modern` system. +Wherever the `Legacy` or `Modern` system needs to communicate with the counterpart the ACL needs to be used to avoid +corrupting the current domain model. The example below shows how the `Legacy` system places an order with a validation +from the `Modern` system. ```java public class LegacyShop { - @Autowired - private AntiCorruptionLayer acl; + @Autowired + private AntiCorruptionLayer acl; - public void placeOrder(LegacyOrder legacyOrder) throws ShopException { + public void placeOrder(LegacyOrder legacyOrder) throws ShopException { - String id = legacyOrder.getId(); + String id = legacyOrder.getId(); - Optional orderInModernSystem = acl.findOrderInModernSystem(id); + Optional orderInModernSystem = acl.findOrderInModernSystem(id); - if (orderInModernSystem.isPresent()) { - // order is already in the modern system - } else { - // place order in the current system - } + if (orderInModernSystem.isPresent()) { + // order is already in the modern system + } else { + // place order in the current system } + } } ``` @@ -127,11 +150,14 @@ public class LegacyShop { Use this pattern when: -* A migration is planned to happen over multiple stages, but integration between new and legacy systems needs to be maintained +* A migration is planned to happen over multiple stages, but integration between new and legacy systems needs to be + maintained * Two or more subsystems have different semantics, but still need to communicate -* When integrating with legacy systems or external systems where direct integration might pollute the domain model of the new system +* When integrating with legacy systems or external systems where direct integration might pollute the domain model of + the new system * In scenarios where different subsystems within a larger system use different data formats or structures -* When there is a need to ensure loose coupling between different subsystems or external services to facilitate easier maintenance and scalability +* When there is a need to ensure loose coupling between different subsystems or external services to facilitate easier + maintenance and scalability ## Tutorials @@ -140,9 +166,11 @@ Use this pattern when: ## Known Uses -* Microservices architectures where individual services must communicate without being tightly coupled to each other’s data schemas +* Microservices architectures where individual services must communicate without being tightly coupled to each other’s + data schemas * Enterprise systems integration, especially when integrating modern systems with legacy systems -* In bounded contexts within Domain-Driven Design (DDD) to maintain the integrity of a domain model when interacting with external systems or subsystems +* In bounded contexts within Domain-Driven Design (DDD) to maintain the integrity of a domain model when interacting + with external systems or subsystems ## Consequences @@ -160,9 +188,12 @@ Trade-offs: ## Related Patterns -* [Facade](https://java-design-patterns.com/patterns/facade/): The Anti-Corruption Layer can be seen as a specialized form of the Facade pattern that is used to isolate different subsystems -* [Adapter](https://java-design-patterns.com/patterns/adapter/): The Anti-Corruption Layer can be implemented using the Adapter pattern to translate between different data formats or structures -* [Gateway](https://java-design-patterns.com/patterns/gateway/): The Anti-Corruption Layer can be used as a Gateway to external systems to provide a unified interface +* [Facade](https://java-design-patterns.com/patterns/facade/): The Anti-Corruption Layer can be seen as a specialized + form of the Facade pattern that is used to isolate different subsystems +* [Adapter](https://java-design-patterns.com/patterns/adapter/): The Anti-Corruption Layer can be implemented using the + Adapter pattern to translate between different data formats or structures +* [Gateway](https://java-design-patterns.com/patterns/gateway/): The Anti-Corruption Layer can be used as a Gateway to + external systems to provide a unified interface ## Credits diff --git a/api-gateway/README.md b/api-gateway/README.md index 40d5f4dc4..9c60d54f6 100644 --- a/api-gateway/README.md +++ b/api-gateway/README.md @@ -11,7 +11,9 @@ tag: ## Intent -The API Gateway design pattern aims to provide a unified interface to a set of microservices. It acts as a single entry point for clients, routing requests to the appropriate microservices and aggregating results, thereby simplifying the client-side code. +The API Gateway design pattern aims to provide a unified interface to a set of microservices. It acts as a single entry +point for clients, routing requests to the appropriate microservices and aggregating results, thereby simplifying the +client-side code. ## Also known as @@ -19,47 +21,47 @@ The API Gateway design pattern aims to provide a unified interface to a set of m ## Explanation -With the Microservices pattern, a client may need data from multiple different microservices. If the -client called each microservice directly, that could contribute to longer load times, since the -client would have to make a network request for each microservice called. Moreover, having the -client call each microservice directly ties the client to that microservice - if the internal -implementations of the microservices change (for example, if two microservices are combined sometime -in the future) or if the location (host and port) of a microservice changes, then every client that +With the Microservices pattern, a client may need data from multiple different microservices. If the +client called each microservice directly, that could contribute to longer load times, since the +client would have to make a network request for each microservice called. Moreover, having the +client call each microservice directly ties the client to that microservice - if the internal +implementations of the microservices change (for example, if two microservices are combined sometime +in the future) or if the location (host and port) of a microservice changes, then every client that makes use of those microservices must be updated. -The intent of the API Gateway pattern is to alleviate some of these issues. In the API Gateway -pattern, an additional entity (the API Gateway) is placed between the client and the microservices. -The job of the API Gateway is to aggregate the calls to the microservices. Rather than the client -calling each microservice individually, the client calls the API Gateway a single time. The API +The intent of the API Gateway pattern is to alleviate some of these issues. In the API Gateway +pattern, an additional entity (the API Gateway) is placed between the client and the microservices. +The job of the API Gateway is to aggregate the calls to the microservices. Rather than the client +calling each microservice individually, the client calls the API Gateway a single time. The API Gateway then calls each of the microservices that the client needs. Real world example -> We are implementing microservices and API Gateway pattern for an e-commerce site. In this system +> We are implementing microservices and API Gateway pattern for an e-commerce site. In this system > the API Gateway makes calls to the Image and Price microservices. In plain words -> For a system implemented using microservices architecture, API Gateway is the single entry point -> that aggregates the calls to the individual microservices. +> For a system implemented using microservices architecture, API Gateway is the single entry point +> that aggregates the calls to the individual microservices. Wikipedia says -> API Gateway is a server that acts as an API front-end, receives API requests, enforces throttling -> and security policies, passes requests to the back-end service and then passes the response back -> to the requester. A gateway often includes a transformation engine to orchestrate and modify the -> requests and responses on the fly. A gateway can also provide functionality such as collecting -> analytics data and providing caching. The gateway can provide functionality to support +> API Gateway is a server that acts as an API front-end, receives API requests, enforces throttling +> and security policies, passes requests to the back-end service and then passes the response back +> to the requester. A gateway often includes a transformation engine to orchestrate and modify the +> requests and responses on the fly. A gateway can also provide functionality such as collecting +> analytics data and providing caching. The gateway can provide functionality to support > authentication, authorization, security, audit and regulatory compliance. **Programmatic Example** -This implementation shows what the API Gateway pattern could look like for an e-commerce site. The -`ApiGateway` makes calls to the Image and Price microservices using the `ImageClientImpl` and -`PriceClientImpl` respectively. Customers viewing the site on a desktop device can see both price -information and an image of a product, so the `ApiGateway` calls both of the microservices and -aggregates the data in the `DesktopProduct` model. However, mobile users only see price information; -they do not see a product image. For mobile users, the `ApiGateway` only retrieves price +This implementation shows what the API Gateway pattern could look like for an e-commerce site. The +`ApiGateway` makes calls to the Image and Price microservices using the `ImageClientImpl` and +`PriceClientImpl` respectively. Customers viewing the site on a desktop device can see both price +information and an image of a product, so the `ApiGateway` calls both of the microservices and +aggregates the data in the `DesktopProduct` model. However, mobile users only see price information; +they do not see a product image. For mobile users, the `ApiGateway` only retrieves price information, which it uses to populate the `MobileProduct`. Here's the Image microservice implementation. @@ -153,7 +155,8 @@ public class ApiGateway { ## Applicability -* When building a microservices architecture, and there's a need to abstract the complexity of microservices from the client. +* When building a microservices architecture, and there's a need to abstract the complexity of microservices from the + client. * When multiple microservices need to be consumed in a single request. * For authentication, authorization, and security enforcement at a single point. * To optimize communication between clients and services, especially in a cloud environment. @@ -181,9 +184,12 @@ Trade-offs: ## Related patterns -* [Aggregator Microservice](../aggregator-microservices/README.md) - The API Gateway pattern is often used in conjunction with the Aggregator Microservice pattern to provide a unified interface to a set of microservices. -* [Proxy](../proxy/README.md) - The API Gateway pattern is a specialized form of the Proxy pattern, where the gateway acts as a single entry point for clients, routing requests to the appropriate microservices and aggregating results. -* [Circuit Breaker](../circuit-breaker/README.md) - API Gateways can use the Circuit Breaker pattern to prevent cascading failures when calling multiple microservices. +* [Aggregator Microservice](../aggregator-microservices/README.md) - The API Gateway pattern is often used in + conjunction with the Aggregator Microservice pattern to provide a unified interface to a set of microservices. +* [Proxy](../proxy/README.md) - The API Gateway pattern is a specialized form of the Proxy pattern, where the gateway + acts as a single entry point for clients, routing requests to the appropriate microservices and aggregating results. +* [Circuit Breaker](../circuit-breaker/README.md) - API Gateways can use the Circuit Breaker pattern to prevent + cascading failures when calling multiple microservices. ## Tutorials diff --git a/arrange-act-assert/README.md b/arrange-act-assert/README.md index 9c6d614b9..ee2e72921 100644 --- a/arrange-act-assert/README.md +++ b/arrange-act-assert/README.md @@ -42,7 +42,7 @@ In plain words WikiWikiWeb says -> Arrange/Act/Assert is a pattern for arranging and formatting code in UnitTest methods. +> Arrange/Act/Assert is a pattern for arranging and formatting code in UnitTest methods. **Programmatic Example** @@ -132,13 +132,14 @@ class CashAAATest { Use Arrange/Act/Assert pattern when -* Unit testing, especially within the context of TDD and BDD +* Unit testing, especially within the context of TDD and BDD * Anywhere clarity and structure are needed in test cases ## Known uses * Widely adopted in software projects using TDD and BDD methodologies. -* Utilized in various programming languages and testing frameworks, such as JUnit (Java), NUnit (.NET), and xUnit frameworks. +* Utilized in various programming languages and testing frameworks, such as JUnit (Java), NUnit (.NET), and xUnit + frameworks. ## Consequences @@ -151,11 +152,13 @@ Benefits: Trade-offs: * May introduce redundancy in tests, as similar arrangements may be repeated across tests. -* Some complex tests might not fit neatly into this structure, requiring additional context or setup outside these three phases. +* Some complex tests might not fit neatly into this structure, requiring additional context or setup outside these three + phases. ## Related patterns -* [Page Object](https://java-design-patterns.com/patterns/page-object/): A pattern for organizing UI tests that can be used in conjunction with Arrange/Act/Assert. +* [Page Object](https://java-design-patterns.com/patterns/page-object/): A pattern for organizing UI tests that can be + used in conjunction with Arrange/Act/Assert. ## Credits diff --git a/async-method-invocation/README.md b/async-method-invocation/README.md index 950b95861..60f4c7110 100644 --- a/async-method-invocation/README.md +++ b/async-method-invocation/README.md @@ -3,17 +3,16 @@ title: Async Method Invocation category: Concurrency language: en tag: - - Asynchronous - - Reactive - - Scalability + - Asynchronous + - Reactive + - Scalability --- ## Intent -Asynchronous method invocation is a pattern where the calling thread -is not blocked while waiting results of tasks. The pattern provides parallel -processing of multiple independent tasks and retrieving the results via -callbacks or waiting until everything is done. +Asynchronous method invocation is a pattern where the calling thread is not blocked while waiting results of tasks. The +pattern provides parallel processing of multiple independent tasks and retrieving the results via callbacks or waiting +until everything is done. ## Also known as @@ -23,54 +22,59 @@ callbacks or waiting until everything is done. Real world example -> Launching space rockets is an exciting business. The mission command gives an order to launch and +> Launching space rockets is an exciting business. The mission command gives an order to launch and > after some undetermined time, the rocket either launches successfully or fails miserably. In plain words -> Asynchronous method invocation starts task processing and returns immediately before the task is +> Asynchronous method invocation starts task processing and returns immediately before the task is > ready. The results of the task processing are returned to the caller later. Wikipedia says -> In multithreaded computer programming, asynchronous method invocation (AMI), also known as -> asynchronous method calls or the asynchronous pattern is a design pattern in which the call site -> is not blocked while waiting for the called code to finish. Instead, the calling thread is +> In multithreaded computer programming, asynchronous method invocation (AMI), also known as +> asynchronous method calls or the asynchronous pattern is a design pattern in which the call site +> is not blocked while waiting for the called code to finish. Instead, the calling thread is > notified when the reply arrives. Polling for a reply is an undesired option. **Programmatic Example** In this example, we are launching space rockets and deploying lunar rovers. -The application demonstrates the async method invocation pattern. The key parts of the pattern are -`AsyncResult` which is an intermediate container for an asynchronously evaluated value, -`AsyncCallback` which can be provided to be executed on task completion and `AsyncExecutor` that +The application demonstrates the async method invocation pattern. The key parts of the pattern are +`AsyncResult` which is an intermediate container for an asynchronously evaluated value, +`AsyncCallback` which can be provided to be executed on task completion and `AsyncExecutor` that manages the execution of the async tasks. ```java public interface AsyncResult { boolean isCompleted(); + T getValue() throws ExecutionException; + void await() throws InterruptedException; } ``` ```java public interface AsyncCallback { - void onComplete(T value); - void onError(Exception ex); + void onComplete(T value); + + void onError(Exception ex); } ``` ```java public interface AsyncExecutor { AsyncResult startProcess(Callable task); + AsyncResult startProcess(Callable task, AsyncCallback callback); + T endProcess(AsyncResult asyncResult) throws ExecutionException, InterruptedException; } ``` -`ThreadAsyncExecutor` is an implementation of `AsyncExecutor`. Some of its key parts are highlighted +`ThreadAsyncExecutor` is an implementation of `AsyncExecutor`. Some of its key parts are highlighted next. ```java @@ -85,14 +89,14 @@ public class ThreadAsyncExecutor implements AsyncExecutor { public AsyncResult startProcess(Callable task, AsyncCallback callback) { var result = new CompletableResult<>(callback); new Thread( - () -> { - try { - result.setValue(task.call()); - } catch (Exception ex) { - result.setException(ex); - } - }, - "executor-" + idx.incrementAndGet()) + () -> { + try { + result.setValue(task.call()); + } catch (Exception ex) { + result.setException(ex); + } + }, + "executor-" + idx.incrementAndGet()) .start(); return result; } @@ -111,50 +115,50 @@ public class ThreadAsyncExecutor implements AsyncExecutor { Then we are ready to launch some rockets to see how everything works together. ```java -public static void main(String[] args) throws Exception { - // construct a new executor that will run async tasks - var executor = new ThreadAsyncExecutor(); +public static void main(String[]args)throws Exception{ + // construct a new executor that will run async tasks + var executor=new ThreadAsyncExecutor(); - // start few async tasks with varying processing times, two last with callback handlers - final var asyncResult1 = executor.startProcess(lazyval(10, 500)); - final var asyncResult2 = executor.startProcess(lazyval("test", 300)); - final var asyncResult3 = executor.startProcess(lazyval(50L, 700)); - final var asyncResult4 = executor.startProcess(lazyval(20, 400), callback("Deploying lunar rover")); - final var asyncResult5 = - executor.startProcess(lazyval("callback", 600), callback("Deploying lunar rover")); +// start few async tasks with varying processing times, two last with callback handlers +final var asyncResult1=executor.startProcess(lazyval(10,500)); +final var asyncResult2=executor.startProcess(lazyval("test",300)); +final var asyncResult3=executor.startProcess(lazyval(50L,700)); +final var asyncResult4=executor.startProcess(lazyval(20,400),callback("Deploying lunar rover")); +final var asyncResult5= + executor.startProcess(lazyval("callback",600),callback("Deploying lunar rover")); - // emulate processing in the current thread while async tasks are running in their own threads - Thread.sleep(350); // Oh boy, we are working hard here - log("Mission command is sipping coffee"); + // emulate processing in the current thread while async tasks are running in their own threads + Thread.sleep(350); // Oh boy, we are working hard here + log("Mission command is sipping coffee"); - // wait for completion of the tasks - final var result1 = executor.endProcess(asyncResult1); - final var result2 = executor.endProcess(asyncResult2); - final var result3 = executor.endProcess(asyncResult3); - asyncResult4.await(); - asyncResult5.await(); +// wait for completion of the tasks +final var result1=executor.endProcess(asyncResult1); +final var result2=executor.endProcess(asyncResult2); +final var result3=executor.endProcess(asyncResult3); + asyncResult4.await(); + asyncResult5.await(); - // log the results of the tasks, callbacks log immediately when complete - log("Space rocket <" + result1 + "> launch complete"); - log("Space rocket <" + result2 + "> launch complete"); - log("Space rocket <" + result3 + "> launch complete"); -} + // log the results of the tasks, callbacks log immediately when complete + log("Space rocket <"+result1+"> launch complete"); + log("Space rocket <"+result2+"> launch complete"); + log("Space rocket <"+result3+"> launch complete"); + } ``` Here's the program console output. ```java -21:47:08.227 [executor-2] INFO com.iluwatar.async.method.invocation.App - Space rocket launched successfully -21:47:08.269 [main] INFO com.iluwatar.async.method.invocation.App - Mission command is sipping coffee -21:47:08.318 [executor-4] INFO com.iluwatar.async.method.invocation.App - Space rocket <20> launched successfully -21:47:08.335 [executor-4] INFO com.iluwatar.async.method.invocation.App - Deploying lunar rover <20> -21:47:08.414 [executor-1] INFO com.iluwatar.async.method.invocation.App - Space rocket <10> launched successfully -21:47:08.519 [executor-5] INFO com.iluwatar.async.method.invocation.App - Space rocket launched successfully -21:47:08.519 [executor-5] INFO com.iluwatar.async.method.invocation.App - Deploying lunar rover -21:47:08.616 [executor-3] INFO com.iluwatar.async.method.invocation.App - Space rocket <50> launched successfully -21:47:08.617 [main] INFO com.iluwatar.async.method.invocation.App - Space rocket <10> launch complete -21:47:08.617 [main] INFO com.iluwatar.async.method.invocation.App - Space rocket launch complete -21:47:08.618 [main] INFO com.iluwatar.async.method.invocation.App - Space rocket <50> launch complete +21:47:08.227[executor-2]INFO com.iluwatar.async.method.invocation.App-Space rocket launched successfully + 21:47:08.269[main]INFO com.iluwatar.async.method.invocation.App-Mission command is sipping coffee + 21:47:08.318[executor-4]INFO com.iluwatar.async.method.invocation.App-Space rocket<20>launched successfully + 21:47:08.335[executor-4]INFO com.iluwatar.async.method.invocation.App-Deploying lunar rover<20> + 21:47:08.414[executor-1]INFO com.iluwatar.async.method.invocation.App-Space rocket<10>launched successfully + 21:47:08.519[executor-5]INFO com.iluwatar.async.method.invocation.App-Space rocket launched successfully + 21:47:08.519[executor-5]INFO com.iluwatar.async.method.invocation.App-Deploying lunar rover +21:47:08.616[executor-3]INFO com.iluwatar.async.method.invocation.App-Space rocket<50>launched successfully + 21:47:08.617[main]INFO com.iluwatar.async.method.invocation.App-Space rocket<10>launch complete + 21:47:08.617[main]INFO com.iluwatar.async.method.invocation.App-Space rocket launch complete + 21:47:08.618[main]INFO com.iluwatar.async.method.invocation.App-Space rocket<50>launch complete ``` # Class diagram @@ -166,14 +170,16 @@ Here's the program console output. Use the async method invocation pattern when * When operations do not need to complete before proceeding with the next steps in a program. -* For tasks that are resource-intensive or time-consuming, such as IO operations, network requests, or complex computations, where making the operation synchronous would significantly impact performance or user experience. +* For tasks that are resource-intensive or time-consuming, such as IO operations, network requests, or complex + computations, where making the operation synchronous would significantly impact performance or user experience. * In GUI applications to prevent freezing or unresponsiveness during long-running tasks. * In web applications for non-blocking IO operations. ## Known Uses * Web servers handling HTTP requests asynchronously to improve throughput and reduce latency. -* Desktop and mobile applications using background threads to perform time-consuming operations without blocking the user interface. +* Desktop and mobile applications using background threads to perform time-consuming operations without blocking the + user interface. * Microservices architectures where services perform asynchronous communications via messaging queues or event streams. * [FutureTask](http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/FutureTask.html) * [CompletableFuture](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html) @@ -184,21 +190,29 @@ Use the async method invocation pattern when Benefits: -* Improved Responsiveness: The main thread or application flow remains unblocked, improving the user experience in GUI applications and overall responsiveness. -* Better Resource Utilization: By enabling parallel execution, system resources (like CPU and IO) are utilized more efficiently, potentially improving the application's throughput. +* Improved Responsiveness: The main thread or application flow remains unblocked, improving the user experience in GUI + applications and overall responsiveness. +* Better Resource Utilization: By enabling parallel execution, system resources (like CPU and IO) are utilized more + efficiently, potentially improving the application's throughput. * Scalability: Easier to scale applications, as tasks can be distributed across available resources more effectively. Trade-offs: -* Complexity: Introducing asynchronous operations can complicate the codebase, making it more challenging to understand, debug, and maintain. -* Resource Management: Requires careful management of threads or execution contexts, which can introduce overhead and potential resource exhaustion issues. -* Error Handling: Asynchronous operations can make error handling more complex, as exceptions may occur in different threads or at different times. +* Complexity: Introducing asynchronous operations can complicate the codebase, making it more challenging to understand, + debug, and maintain. +* Resource Management: Requires careful management of threads or execution contexts, which can introduce overhead and + potential resource exhaustion issues. +* Error Handling: Asynchronous operations can make error handling more complex, as exceptions may occur in different + threads or at different times. Related Patterns: -* [Command](https://java-design-patterns.com/patterns/command/): Asynchronous method invocation can be used to implement the Command pattern, where commands are executed asynchronously. -* [Observer](https://java-design-patterns.com/patterns/observer/): Asynchronous method invocation can be used to notify observers asynchronously when a subject's state changes. -* [Promise](https://java-design-patterns.com/patterns/promise/): The AsyncResult interface can be considered a form of Promise, representing a value that may not be available yet. +* [Command](https://java-design-patterns.com/patterns/command/): Asynchronous method invocation can be used to implement + the Command pattern, where commands are executed asynchronously. +* [Observer](https://java-design-patterns.com/patterns/observer/): Asynchronous method invocation can be used to notify + observers asynchronously when a subject's state changes. +* [Promise](https://java-design-patterns.com/patterns/promise/): The AsyncResult interface can be considered a form of + Promise, representing a value that may not be available yet. ## Credits diff --git a/balking/README.md b/balking/README.md index 486439c68..0fa525396 100644 --- a/balking/README.md +++ b/balking/README.md @@ -3,18 +3,19 @@ title: Balking category: Concurrency language: en tag: - - Decoupling + - Decoupling --- ## Intent -Balking Pattern is used to prevent an object from executing a certain code if it is in an incomplete or inappropriate state. If the state is not suitable for the action, the method call is ignored (or "balked"). +Balking Pattern is used to prevent an object from executing a certain code if it is in an incomplete or inappropriate +state. If the state is not suitable for the action, the method call is ignored (or "balked"). ## Explanation Real world example -> There's a start-button in a washing machine to initiate the laundry washing. When the washing +> 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. @@ -24,21 +25,22 @@ In plain words Wikipedia says -> The balking pattern is a software design pattern that only executes an action on an object when -> the object is in a particular state. For example, if an object reads ZIP files and a calling -> method invokes a get method on the object when the ZIP file is not open, the object would "balk" +> The balking pattern is a software design pattern that only executes an action on an object when +> the object is in a particular state. For example, if an object reads ZIP files and a calling +> method invokes a get method on the object when the ZIP file is not open, the object would "balk" > at the request. **Programmatic Example** -In this example implementation, `WashingMachine` is an object that has two states in which it can +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()` +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. ```java + @Slf4j public class WashingMachine { @@ -86,20 +88,20 @@ public interface DelayProvider { Now we introduce the application using the `WashingMachine`. ```java - public static void main(String... args) { - final var washingMachine = new WashingMachine(); - var executorService = Executors.newFixedThreadPool(3); - for (int i = 0; i < 3; i++) { - executorService.execute(washingMachine::wash); + public static void main(String...args){ +final var washingMachine=new WashingMachine(); + var executorService=Executors.newFixedThreadPool(3); + for(int i=0;i< 3;i++){ + executorService.execute(washingMachine::wash); } executorService.shutdown(); - try { - executorService.awaitTermination(10, TimeUnit.SECONDS); - } catch (InterruptedException ie) { - LOGGER.error("ERROR: Waiting on executor service shutdown!"); - Thread.currentThread().interrupt(); + try{ + executorService.awaitTermination(10,TimeUnit.SECONDS); + }catch(InterruptedException ie){ + LOGGER.error("ERROR: Waiting on executor service shutdown!"); + Thread.currentThread().interrupt(); + } } - } ``` Here is the console output of the program. @@ -123,27 +125,33 @@ Here is the console output of the program. Use the Balking pattern when * You want to invoke an action on an object only when it is in a particular state -* Objects are generally only in a state that is prone to balking temporarily but for an unknown +* Objects are generally only in a state that is prone to balking temporarily but for an unknown amount of time -* In multithreaded applications where certain actions should only proceed when specific conditions are met, and those conditions are expected to change over time due to external factors or concurrent operations. +* In multithreaded applications where certain actions should only proceed when specific conditions are met, and those + conditions are expected to change over time due to external factors or concurrent operations. ## Known Uses: * Resource pooling, where resources are only allocated if they are in a valid state for allocation. -* Thread management, where threads only proceed with tasks if certain conditions (like task availability or resource locks) are met. +* Thread management, where threads only proceed with tasks if certain conditions (like task availability or resource + locks) are met. ## Consequences: Benefits: -* Reduces unnecessary lock acquisitions in situations where actions cannot proceed, enhancing performance in concurrent applications. +* Reduces unnecessary lock acquisitions in situations where actions cannot proceed, enhancing performance in concurrent + applications. * Encourages clear separation of state management and behavior, leading to cleaner code. -* Simplifies the handling of operations that should only be performed under certain conditions without cluttering the caller code with state checks. +* Simplifies the handling of operations that should only be performed under certain conditions without cluttering the + caller code with state checks. Trade-offs: -* Can introduce complexity by obscuring the conditions under which actions are taken or ignored, potentially making the system harder to debug and understand. -* May lead to missed opportunities or actions if the state changes are not properly monitored or if the balking condition is too restrictive. +* Can introduce complexity by obscuring the conditions under which actions are taken or ignored, potentially making the + system harder to debug and understand. +* May lead to missed opportunities or actions if the state changes are not properly monitored or if the balking + condition is too restrictive. ## Related patterns diff --git a/bridge/README.md b/bridge/README.md index a679df25f..894688765 100644 --- a/bridge/README.md +++ b/bridge/README.md @@ -20,15 +20,20 @@ Decouple an abstraction from its implementation so that the two can vary indepen Real-world example -> Consider you have a weapon with different enchantments, and you are supposed to allow mixing different weapons with different enchantments. What would you do? Create multiple copies of each of the weapons for each of the enchantments or would you just create separate enchantment and set it for the weapon as needed? Bridge pattern allows you to do the second. +> Consider you have a weapon with different enchantments, and you are supposed to allow mixing different weapons with +> different enchantments. What would you do? Create multiple copies of each of the weapons for each of the enchantments or +> would you just create separate enchantment and set it for the weapon as needed? Bridge pattern allows you to do the +> second. In Plain Words -> Bridge pattern is about preferring composition to inheritance. Implementation details are pushed from a hierarchy to another object with a separate hierarchy. +> Bridge pattern is about preferring composition to inheritance. Implementation details are pushed from a hierarchy to +> another object with a separate hierarchy. Wikipedia says -> The bridge pattern is a design pattern used in software engineering that is meant to "decouple an abstraction from its implementation so that the two can vary independently" +> The bridge pattern is a design pattern used in software engineering that is meant to "decouple an abstraction from its +> implementation so that the two can vary independently" **Programmatic Example** @@ -37,8 +42,11 @@ Translating our weapon example from above. Here we have the `Weapon` hierarchy: ```java public interface Weapon { void wield(); + void swing(); + void unwield(); + Enchantment getEnchantment(); } @@ -112,7 +120,9 @@ Here's the separate enchantment hierarchy: ```java public interface Enchantment { void onActivate(); + void apply(); + void onDeactivate(); } @@ -157,16 +167,16 @@ Here are both hierarchies in action: ```java LOGGER.info("The knight receives an enchanted sword."); -var enchantedSword = new Sword(new SoulEatingEnchantment()); -enchantedSword.wield(); -enchantedSword.swing(); -enchantedSword.unwield(); + var enchantedSword=new Sword(new SoulEatingEnchantment()); + enchantedSword.wield(); + enchantedSword.swing(); + enchantedSword.unwield(); -LOGGER.info("The valkyrie receives an enchanted hammer."); -var hammer = new Hammer(new FlyingEnchantment()); -hammer.wield(); -hammer.swing(); -hammer.unwield(); + LOGGER.info("The valkyrie receives an enchanted hammer."); + var hammer=new Hammer(new FlyingEnchantment()); + hammer.wield(); + hammer.swing(); + hammer.unwield(); ``` Here's the console output. @@ -196,37 +206,55 @@ The item's glow fades. Use the Bridge pattern when -* You want to avoid a permanent binding between an abstraction and its implementation. This might be the case, for example, when the implementation must be selected or switched at run-time. -* Both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently. -* Changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled. -* You have a proliferation of classes. Such a class hierarchy indicates the need for splitting an object into two parts. Rumbaugh uses the term "nested generalizations" to refer to such class hierarchies. -* You want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be hidden from the client. A simple example is Coplien's String class, in which multiple objects can share the same string representation. +* You want to avoid a permanent binding between an abstraction and its implementation. This might be the case, for + example, when the implementation must be selected or switched at run-time. +* Both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern + lets you combine the different abstractions and implementations and extend them independently. +* Changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have + to be recompiled. +* You have a proliferation of classes. Such a class hierarchy indicates the need for splitting an object into two parts. + Rumbaugh uses the term "nested generalizations" to refer to such class hierarchies. +* You want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be + hidden from the client. A simple example is Coplien's String class, in which multiple objects can share the same + string representation. ## Known uses -* GUI Frameworks where the abstraction is the window, and the implementation could be the underlying OS windowing system. -* Database Drivers where the abstraction is a generic database interface, and the implementations are database-specific drivers. -* Device Drivers where the abstraction is the device-independent code, and the implementation is the device-dependent code. +* GUI Frameworks where the abstraction is the window, and the implementation could be the underlying OS windowing + system. +* Database Drivers where the abstraction is a generic database interface, and the implementations are database-specific + drivers. +* Device Drivers where the abstraction is the device-independent code, and the implementation is the device-dependent + code. ## Consequences Benefits: -* Decoupling Interface and Implementation: The Bridge pattern enhances modularity by separating the interface (the high-level operations) from the implementation (the low-level operations). +* Decoupling Interface and Implementation: The Bridge pattern enhances modularity by separating the interface (the + high-level operations) from the implementation (the low-level operations). * Improved Extensibility: You can extend the abstraction and implementation hierarchies independently. * Hiding Implementation Details: Clients only see the abstraction's interface, not its implementation. Trade-offs: -* Increased Complexity: The pattern can complicate the system architecture and code, especially for clients unfamiliar with the pattern. -* Runtime Overhead: The extra layer of abstraction can introduce a performance penalty, although it is often negligible in practice. +* Increased Complexity: The pattern can complicate the system architecture and code, especially for clients unfamiliar + with the pattern. +* Runtime Overhead: The extra layer of abstraction can introduce a performance penalty, although it is often negligible + in practice. ## Related Patterns -* [Adapter](https://java-design-patterns.com/patterns/adapter/): The Adapter pattern is used to provide a different interface to an object, while the Bridge pattern is used to separate an object's interface from its implementation. -* [Strategy](https://java-design-patterns.com/patterns/strategy/): The Strategy pattern is like the Bridge pattern, but with a different intent. Both patterns are based on composition: Strategy uses composition to change the behavior of a class, while Bridge uses composition to separate an abstraction from its implementation. -* [Abstract Factory](https://java-design-patterns.com/patterns/abstract-factory/): The Abstract Factory pattern can be used along with the Bridge pattern to create platforms that are independent of the concrete classes used to create their objects. -* [Composite](https://java-design-patterns.com/patterns/composite/): The Bridge pattern is often used with the Composite pattern to model the implementation details of a component. +* [Adapter](https://java-design-patterns.com/patterns/adapter/): The Adapter pattern is used to provide a different + interface to an object, while the Bridge pattern is used to separate an object's interface from its implementation. +* [Strategy](https://java-design-patterns.com/patterns/strategy/): The Strategy pattern is like the Bridge pattern, but + with a different intent. Both patterns are based on composition: Strategy uses composition to change the behavior of a + class, while Bridge uses composition to separate an abstraction from its implementation. +* [Abstract Factory](https://java-design-patterns.com/patterns/abstract-factory/): The Abstract Factory pattern can be + used along with the Bridge pattern to create platforms that are independent of the concrete classes used to create + their objects. +* [Composite](https://java-design-patterns.com/patterns/composite/): The Bridge pattern is often used with the Composite + pattern to model the implementation details of a component. ## Tutorials diff --git a/builder/README.md b/builder/README.md index 930bca0f4..c9f63f471 100644 --- a/builder/README.md +++ b/builder/README.md @@ -3,35 +3,43 @@ title: Builder category: Creational language: en tag: - - Gang of Four + - Gang of Four --- ## Intent -Separate the construction of a complex object from its representation so that the same construction process can create different representations. +Separate the construction of a complex object from its representation so that the same construction process can create +different representations. ## Explanation Real-world example -> Imagine a character generator for a role-playing game. The easiest option is to let the computer create the character for you. If you want to manually select the character details like profession, gender, hair color, etc. the character generation becomes a step-by-step process that completes when all the selections are ready. +> Imagine a character generator for a role-playing game. The easiest option is to let the computer create the character +> for you. If you want to manually select the character details like profession, gender, hair color, etc. the character +> generation becomes a step-by-step process that completes when all the selections are ready. In plain words -> Allows you to create different flavors of an object while avoiding constructor pollution. Useful when there could be several flavors of an object. Or when there are a lot of steps involved in creation of an object. +> Allows you to create different flavors of an object while avoiding constructor pollution. Useful when there could be +> several flavors of an object. Or when there are a lot of steps involved in creation of an object. Wikipedia says -> The builder pattern is an object creation software design pattern with the intentions of finding a solution to the telescoping constructor antipattern. +> The builder pattern is an object creation software design pattern with the intentions of finding a solution to the +> telescoping constructor antipattern. -Having said that let me add a bit about what telescoping constructor antipattern is. At one point or the other, we have all seen a constructor like below: +Having said that let me add a bit about what telescoping constructor antipattern is. At one point or the other, we have +all seen a constructor like below: ```java -public Hero(Profession profession, String name, HairType hairType, HairColor hairColor, Armor armor, Weapon weapon) { -} +public Hero(Profession profession,String name,HairType hairType,HairColor hairColor,Armor armor,Weapon weapon){ + } ``` -As you can see the number of constructor parameters can quickly get out of hand, and it may become difficult to understand the arrangement of parameters. Plus this parameter list could keep on growing if you would want to add more options in the future. This is called telescoping constructor antipattern. +As you can see the number of constructor parameters can quickly get out of hand, and it may become difficult to +understand the arrangement of parameters. Plus this parameter list could keep on growing if you would want to add more +options in the future. This is called telescoping constructor antipattern. **Programmatic Example** @@ -61,51 +69,51 @@ Then we have the builder: ```java public static class Builder { - private final Profession profession; - private final String name; - private HairType hairType; - private HairColor hairColor; - private Armor armor; - private Weapon weapon; + private final Profession profession; + private final String name; + private HairType hairType; + private HairColor hairColor; + private Armor armor; + private Weapon weapon; - public Builder(Profession profession, String name) { - if (profession == null || name == null) { - throw new IllegalArgumentException("profession and name can not be null"); - } - this.profession = profession; - this.name = name; - } - - public Builder withHairType(HairType hairType) { - this.hairType = hairType; - return this; - } - - public Builder withHairColor(HairColor hairColor) { - this.hairColor = hairColor; - return this; - } - - public Builder withArmor(Armor armor) { - this.armor = armor; - return this; - } - - public Builder withWeapon(Weapon weapon) { - this.weapon = weapon; - return this; - } - - public Hero build() { - return new Hero(this); + public Builder(Profession profession, String name) { + if (profession == null || name == null) { + throw new IllegalArgumentException("profession and name can not be null"); } + this.profession = profession; + this.name = name; } + + public Builder withHairType(HairType hairType) { + this.hairType = hairType; + return this; + } + + public Builder withHairColor(HairColor hairColor) { + this.hairColor = hairColor; + return this; + } + + public Builder withArmor(Armor armor) { + this.armor = armor; + return this; + } + + public Builder withWeapon(Weapon weapon) { + this.weapon = weapon; + return this; + } + + public Hero build() { + return new Hero(this); + } +} ``` Then it can be used as: ```java -var mage = new Hero.Builder(Profession.MAGE, "Riobard").withHairColor(HairColor.BLACK).withWeapon(Weapon.DAGGER).build(); +var mage=new Hero.Builder(Profession.MAGE,"Riobard").withHairColor(HairColor.BLACK).withWeapon(Weapon.DAGGER).build(); ``` ## Class diagram @@ -116,9 +124,11 @@ var mage = new Hero.Builder(Profession.MAGE, "Riobard").withHairColor(HairColor. Use the Builder pattern when -* The algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled +* The algorithm for creating a complex object should be independent of the parts that make up the object and how they're + assembled * The construction process must allow different representations for the object that's constructed -* It's particularly useful when a product requires a lot of steps to be created and when these steps need to be executed in a specific sequence +* It's particularly useful when a product requires a lot of steps to be created and when these steps need to be executed + in a specific sequence ## Known Uses @@ -132,7 +142,8 @@ Benefits: * More control over the construction process compared to other creational patterns * Supports constructing objects step-by-step, defer construction steps or run steps recursively -* Can construct objects that require a complex assembly of sub-objects. The final product is detached from the parts that make it up, as well as their assembly process +* Can construct objects that require a complex assembly of sub-objects. The final product is detached from the parts + that make it up, as well as their assembly process * Single Responsibility Principle. You can isolate complex construction code from the business logic of the product Trade-offs: @@ -148,7 +159,8 @@ Trade-offs: ## Known uses * [java.lang.StringBuilder](http://docs.oracle.com/javase/8/docs/api/java/lang/StringBuilder.html) -* [java.nio.ByteBuffer](http://docs.oracle.com/javase/8/docs/api/java/nio/ByteBuffer.html#put-byte-) as well as similar buffers such as FloatBuffer, IntBuffer and so on. +* [java.nio.ByteBuffer](http://docs.oracle.com/javase/8/docs/api/java/nio/ByteBuffer.html#put-byte-) as well as similar + buffers such as FloatBuffer, IntBuffer and so on. * [java.lang.StringBuffer](http://docs.oracle.com/javase/8/docs/api/java/lang/StringBuffer.html#append-boolean-) * All implementations of [java.lang.Appendable](http://docs.oracle.com/javase/8/docs/api/java/lang/Appendable.html) * [Apache Camel builders](https://github.com/apache/camel/tree/0e195428ee04531be27a0b659005e3aa8d159d23/camel-core/src/main/java/org/apache/camel/builder) @@ -156,7 +168,10 @@ Trade-offs: ## Related patterns -* [Step Builder](https://java-design-patterns.com/patterns/step-builder/) is a variation of the Builder pattern that generates a complex object using a step-by-step approach. The Step Builder pattern is a good choice when you need to build an object with a large number of optional parameters, and you want to avoid the telescoping constructor antipattern. +* [Step Builder](https://java-design-patterns.com/patterns/step-builder/) is a variation of the Builder pattern that + generates a complex object using a step-by-step approach. The Step Builder pattern is a good choice when you need to + build an object with a large number of optional parameters, and you want to avoid the telescoping constructor + antipattern. ## Credits diff --git a/business-delegate/README.md b/business-delegate/README.md index 87534b869..e35546dcb 100644 --- a/business-delegate/README.md +++ b/business-delegate/README.md @@ -3,12 +3,14 @@ title: Business Delegate category: Structural language: en tag: - - Decoupling + - Decoupling --- ## Intent -The Business Delegate pattern adds an abstraction layer between presentation and business tiers. By using the pattern we gain loose coupling between the tiers and encapsulate knowledge about how to locate, connect to, and interact with the business objects that make up the application. +The Business Delegate pattern adds an abstraction layer between presentation and business tiers. By using the pattern we +gain loose coupling between the tiers and encapsulate knowledge about how to locate, connect to, and interact with the +business objects that make up the application. ## Also known as @@ -18,7 +20,9 @@ Service Representative Real world example -> A mobile phone application promises to stream any movie in existence to your device. It captures the user's search string and passes this on to the Business Delegate. The Business Delegate selects the most suitable video streaming service and plays the video from there. +> A mobile phone application promises to stream any movie in existence to your device. It captures the user's search +> string and passes this on to the Business Delegate. The Business Delegate selects the most suitable video streaming +> service and plays the video from there. In Plain Words @@ -26,7 +30,10 @@ In Plain Words Wikipedia says -> Business Delegate is a Java EE design pattern. This pattern is directing to reduce the coupling in between business services and the connected presentation tier, and to hide the implementation details of services (including lookup and accessibility of EJB architecture). Business Delegates acts as an adaptor to invoke business objects from the presentation tier. +> Business Delegate is a Java EE design pattern. This pattern is directing to reduce the coupling in between business +> services and the connected presentation tier, and to hide the implementation details of services (including lookup and +> accessibility of EJB architecture). Business Delegates acts as an adaptor to invoke business objects from the +> presentation tier. **Programmatic Example** @@ -57,6 +64,7 @@ public class YouTubeService implements VideoStreamingService { Then, we have a lookup service that decides which video streaming service to use. ```java + @Setter public class BusinessLookup { @@ -77,6 +85,7 @@ The Business Delegate uses a business lookup to route movie playback requests to video streaming service. ```java + @Setter public class BusinessDelegate { @@ -109,20 +118,20 @@ public class MobileClient { Finally, we can demonstrate the complete example in action. ```java - public static void main(String[] args) { + public static void main(String[]args){ // prepare the objects - var businessDelegate = new BusinessDelegate(); - var businessLookup = new BusinessLookup(); + var businessDelegate=new BusinessDelegate(); + var businessLookup=new BusinessLookup(); businessLookup.setNetflixService(new NetflixService()); businessLookup.setYouTubeService(new YouTubeService()); businessDelegate.setLookupService(businessLookup); // create the client and use the Business Delegate - var client = new MobileClient(businessDelegate); + var client=new MobileClient(businessDelegate); client.playbackMovie("Die Hard 2"); client.playbackMovie("Maradona: The Greatest Ever"); - } + } ``` Here is the console output. @@ -164,7 +173,8 @@ Benefits: * Decoupling of Presentation and Business Tiers: Allows the client tier and business services to evolve independently. * Location Transparency: Clients remain unaffected by changes in the location or the instantiation of business services. -* Reuse and Scalability: Business Delegate objects can be reused by multiple clients, and the pattern supports load balancing and scalability. +* Reuse and Scalability: Business Delegate objects can be reused by multiple clients, and the pattern supports load + balancing and scalability. Trade-offs: @@ -173,9 +183,12 @@ Trade-offs: ## Related patterns -* [Service Locator](https://java-design-patterns.com/patterns/service-locator/): Business Delegate uses Service Locator to locate business services. -* [Session Facade](https://java-design-patterns.com/patterns/session-facade/): Business Delegate may use Session Facade to provide a unified interface to a set of business services. -* [Composite Entity](https://java-design-patterns.com/patterns/composite-entity/): Business Delegate may use Composite Entity to manage the state of business services. +* [Service Locator](https://java-design-patterns.com/patterns/service-locator/): Business Delegate uses Service Locator + to locate business services. +* [Session Facade](https://java-design-patterns.com/patterns/session-facade/): Business Delegate may use Session Facade + to provide a unified interface to a set of business services. +* [Composite Entity](https://java-design-patterns.com/patterns/composite-entity/): Business Delegate may use Composite + Entity to manage the state of business services. ## Credits diff --git a/bytecode/README.md b/bytecode/README.md index c13565eb1..e4a459b58 100644 --- a/bytecode/README.md +++ b/bytecode/README.md @@ -3,7 +3,7 @@ title: Bytecode category: Behavioral language: en tag: - - Game programming + - Game programming --- ## Intent @@ -14,22 +14,28 @@ Allows encoding behavior as instructions for a virtual machine. Real world example -> A team is working on a new game where wizards battle against each other. The wizard behavior needs to be carefully adjusted and iterated hundreds of times through playtesting. It's not optimal to ask the programmer to make changes each time the game designer wants to vary the behavior, so the wizard behavior is implemented as a data-driven virtual machine. +> A team is working on a new game where wizards battle against each other. The wizard behavior needs to be carefully +> adjusted and iterated hundreds of times through playtesting. It's not optimal to ask the programmer to make changes each +> time the game designer wants to vary the behavior, so the wizard behavior is implemented as a data-driven virtual +> machine. In plain words > Bytecode pattern enables behavior driven by data instead of code. -[Gameprogrammingpatterns.com](https://gameprogrammingpatterns.com/bytecode.html) documentation +[Gameprogrammingpatterns.com](https://gameprogrammingpatterns.com/bytecode.html) documentation states: -> An instruction set defines the low-level operations that can be performed. A series of instructions is encoded as a sequence of bytes. A virtual machine executes these instructions one at a time, using a stack for intermediate values. By combining instructions, complex high-level behavior can be defined. +> An instruction set defines the low-level operations that can be performed. A series of instructions is encoded as a +> sequence of bytes. A virtual machine executes these instructions one at a time, using a stack for intermediate values. +> By combining instructions, complex high-level behavior can be defined. **Programmatic Example** One of the most important game objects is the `Wizard` class. ```java + @AllArgsConstructor @Setter @Getter @@ -54,9 +60,12 @@ public class Wizard { } ``` -Next, we show the available instructions for our virtual machine. Each of the instructions has its own semantics on how it operates with the stack data. For example, the ADD instruction takes the top two items from the stack, adds them together and pushes the result to the stack. +Next, we show the available instructions for our virtual machine. Each of the instructions has its own semantics on how +it operates with the stack data. For example, the ADD instruction takes the top two items from the stack, adds them +together and pushes the result to the stack. ```java + @AllArgsConstructor @Getter public enum Instruction { @@ -76,9 +85,11 @@ public enum Instruction { } ``` -At the heart of our example is the `VirtualMachine` class. It takes instructions as input and executes them to provide the game object behavior. +At the heart of our example is the `VirtualMachine` class. It takes instructions as input and executes them to provide +the game object behavior. ```java + @Getter @Slf4j public class VirtualMachine { @@ -172,11 +183,11 @@ public class VirtualMachine { Now we can show the full example utilizing the virtual machine. ```java - public static void main(String[] args) { + public static void main(String[]args){ - var vm = new VirtualMachine( - new Wizard(45, 7, 11, 0, 0), - new Wizard(36, 18, 8, 0, 0)); + var vm=new VirtualMachine( + new Wizard(45,7,11,0,0), + new Wizard(36,18,8,0,0)); vm.execute(InstructionConverterUtil.convertToByteCode("LITERAL 0")); vm.execute(InstructionConverterUtil.convertToByteCode("LITERAL 0")); @@ -190,7 +201,7 @@ Now we can show the full example utilizing the virtual machine. vm.execute(InstructionConverterUtil.convertToByteCode("DIVIDE")); vm.execute(InstructionConverterUtil.convertToByteCode("ADD")); vm.execute(InstructionConverterUtil.convertToByteCode("SET_HEALTH")); - } + } ``` Here is the console output. @@ -216,11 +227,13 @@ Here is the console output. ## Applicability -Use the Bytecode pattern when you have a lot of behavior you need to define and your game’s implementation language isn’t a good fit because: +Use the Bytecode pattern when you have a lot of behavior you need to define and your game’s implementation language +isn’t a good fit because: * It’s too low-level, making it tedious or error-prone to program in. * Iterating on it takes too long due to slow compile times or other tooling issues. -* It has too much trust. If you want to ensure the behavior being defined can’t break the game, you need to sandbox it from the rest of the codebase. +* It has too much trust. If you want to ensure the behavior being defined can’t break the game, you need to sandbox it + from the rest of the codebase. ## Known Uses @@ -238,14 +251,18 @@ Benefits: Trade-offs: -* Overhead: Running bytecode typically involves more overhead than running native code, potentially affecting performance. +* Overhead: Running bytecode typically involves more overhead than running native code, potentially affecting + performance. * Complexity: Implementing and maintaining a VM adds complexity to the system. ## Related patterns -* [Interpreter](https://java-design-patterns.com/patterns/interpreter/) is often used within the implementation of VMs to interpret bytecode instructions -* [Command](https://java-design-patterns.com/patterns/command/): Bytecode instructions can be seen as commands executed by the VM. -* [Factory Method](https://java-design-patterns.com/patterns/factory-method/): VMs may use factory methods to instantiate operations or instructions defined in the bytecode. +* [Interpreter](https://java-design-patterns.com/patterns/interpreter/) is often used within the implementation of VMs + to interpret bytecode instructions +* [Command](https://java-design-patterns.com/patterns/command/): Bytecode instructions can be seen as commands executed + by the VM. +* [Factory Method](https://java-design-patterns.com/patterns/factory-method/): VMs may use factory methods to + instantiate operations or instructions defined in the bytecode. ## Credits diff --git a/caching/README.md b/caching/README.md index 001b6ec1c..a3442a2b9 100644 --- a/caching/README.md +++ b/caching/README.md @@ -10,7 +10,9 @@ tag: ## Intent -The caching pattern avoids expensive re-acquisition of resources by not releasing them immediately after use. The resources retain their identity, are kept in some fast-access storage, and are re-used to avoid having to acquire them again. +The caching pattern avoids expensive re-acquisition of resources by not releasing them immediately after use. The +resources retain their identity, are kept in some fast-access storage, and are re-used to avoid having to acquire them +again. ## Also known as @@ -21,7 +23,10 @@ The caching pattern avoids expensive re-acquisition of resources by not releasin Real world example -> A team is working on a website that provides new homes for abandoned cats. People can post their cats on the website after registering, but all the new posts require approval from one of the site moderators. The user accounts of the site moderators contain a specific flag and the data is stored in a MongoDB database. Checking for the moderator flag each time a post is viewed becomes expensive, and it's a good idea to utilize caching here. +> A team is working on a website that provides new homes for abandoned cats. People can post their cats on the website +> after registering, but all the new posts require approval from one of the site moderators. The user accounts of the site +> moderators contain a specific flag and the data is stored in a MongoDB database. Checking for the moderator flag each +> time a post is viewed becomes expensive, and it's a good idea to utilize caching here. In plain words @@ -29,13 +34,20 @@ In plain words Wikipedia says: -> In computing, a cache is a hardware or software component that stores data so that future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation or a copy of data stored elsewhere. A cache hit occurs when the requested data can be found in a cache, while a cache miss occurs when it cannot. Cache hits are served by reading data from the cache, which is faster than recomputing a result or reading from a slower data store; thus, the more requests that can be served from the cache, the faster the system performs. +> In computing, a cache is a hardware or software component that stores data so that future requests for that data can +> be served faster; the data stored in a cache might be the result of an earlier computation or a copy of data stored +> elsewhere. A cache hit occurs when the requested data can be found in a cache, while a cache miss occurs when it cannot. +> Cache hits are served by reading data from the cache, which is faster than recomputing a result or reading from a slower +> data store; thus, the more requests that can be served from the cache, the faster the system performs. **Programmatic Example** -Let's first look at the data layer of our application. The interesting classes are `UserAccount` which is a simple Java object containing the user account details, and `DbManager` interface which handles reading and writing of these objects to/from database. +Let's first look at the data layer of our application. The interesting classes are `UserAccount` which is a simple Java +object containing the user account details, and `DbManager` interface which handles reading and writing of these objects +to/from database. ```java + @Data @AllArgsConstructor @ToString @@ -49,11 +61,15 @@ public class UserAccount { public interface DbManager { void connect(); + void disconnect(); - + UserAccount readFromDb(String userId); + UserAccount writeToDb(UserAccount userAccount); + UserAccount updateDb(UserAccount userAccount); + UserAccount upsertDb(UserAccount userAccount); } ``` @@ -62,17 +78,21 @@ In the example, we are demonstrating various different caching policies * Write-through writes data to the cache and DB in a single transaction * Write-around writes data immediately into the DB instead of the cache -* Write-behind writes data into the cache initially whilst the data is only written into the DB +* Write-behind writes data into the cache initially whilst the data is only written into the DB when the cache is full -* Cache-aside pushes the responsibility of keeping the data synchronized in both data sources to +* Cache-aside pushes the responsibility of keeping the data synchronized in both data sources to the application itself -* Read-through strategy is also included in the aforementioned strategies, and it returns data from - the cache to the caller if it exists, otherwise queries from DB and stores it into the cache for +* Read-through strategy is also included in the aforementioned strategies, and it returns data from + the cache to the caller if it exists, otherwise queries from DB and stores it into the cache for future use. - -The cache implementation in `LruCache` is a hash table accompanied by a doubly linked-list. The linked-list helps in capturing and maintaining the LRU data in the cache. When data is queried (from the cache), added (to the cache), or updated, the data is moved to the front of the list to depict itself as the most-recently-used data. The LRU data is always at the end of the list. + +The cache implementation in `LruCache` is a hash table accompanied by a doubly linked-list. The linked-list helps in +capturing and maintaining the LRU data in the cache. When data is queried (from the cache), added (to the cache), or +updated, the data is moved to the front of the list to depict itself as the most-recently-used data. The LRU data is +always at the end of the list. ```java + @Slf4j public class LruCache { @@ -87,7 +107,7 @@ public class LruCache { this.userAccount = userAccount; } } - + /* ... omitted details ... */ public LruCache(int capacity) { @@ -127,14 +147,21 @@ public class LruCache { public boolean contains(String userId) { return cache.containsKey(userId); } - + public void remove(Node node) { /* ... */ } + public void setHead(Node node) { /* ... */ } + public void invalidate(String userId) { /* ... */ } + public boolean isFull() { /* ... */ } + public UserAccount getLruData() { /* ... */ } + public void clear() { /* ... */ } + public List getCacheDataInListForm() { /* ... */ } + public void setCapacity(int newCapacity) { /* ... */ } } ``` @@ -142,6 +169,7 @@ public class LruCache { The next layer we are going to look at is `CacheStore` which implements the different caching strategies. ```java + @Slf4j public class CacheStore { @@ -201,9 +229,13 @@ public class CacheStore { } ``` -`AppManager` helps to bridge the gap in communication between the main class and the application's back-end. DB connection is initialized through this class. The chosen caching strategy/policy is also initialized here. Before the cache can be used, the size of the cache has to be set. Depending on the chosen caching policy, `AppManager` will call the appropriate function in the `CacheStore` class. +`AppManager` helps to bridge the gap in communication between the main class and the application's back-end. DB +connection is initialized through this class. The chosen caching strategy/policy is also initialized here. Before the +cache can be used, the size of the cache has to be set. Depending on the chosen caching policy, `AppManager` will call +the appropriate function in the `CacheStore` class. ```java + @Slf4j public final class AppManager { @@ -223,7 +255,7 @@ public final class AppManager { public UserAccount find(final String userId) { LOGGER.info("Trying to find {} in cache", userId); if (cachingPolicy == CachingPolicy.THROUGH - || cachingPolicy == CachingPolicy.AROUND) { + || cachingPolicy == CachingPolicy.AROUND) { return cacheStore.readThrough(userId); } else if (cachingPolicy == CachingPolicy.BEHIND) { return cacheStore.readThroughWithWriteBackPolicy(userId); @@ -257,12 +289,13 @@ public final class AppManager { Here is what we do in the main class of the application. ```java + @Slf4j public class App { public static void main(final String[] args) { boolean isDbMongo = isDbMongo(args); - if(isDbMongo){ + if (isDbMongo) { LOGGER.info("Using the Mongo database engine to run the application."); } else { LOGGER.info("Using the 'in Memory' database to run the application."); @@ -308,7 +341,8 @@ public class App { Use the Caching pattern when * Repetitious acquisition, initialization, and release of the same resource cause unnecessary performance overhead -* In scenarios where the cost of recomputing or re-fetching data is significantly higher than storing and retrieving it from cache +* In scenarios where the cost of recomputing or re-fetching data is significantly higher than storing and retrieving it + from cache * For read-heavy applications with relatively static data or data that changes infrequently ## Known Uses @@ -316,28 +350,36 @@ Use the Caching pattern when * Web page caching to reduce server load and improve response time * Database query caching to avoid repeated expensive SQL queries * Caching results of CPU-intensive computations -* Content Delivery Networks (CDNs) for caching static resources like images, CSS, and JavaScript files closer to the end users +* Content Delivery Networks (CDNs) for caching static resources like images, CSS, and JavaScript files closer to the end + users ## Consequences Benefits: * Improved Performance: Significantly reduces data access latency, leading to faster application performance -* Reduced Load: Decreases the load on the underlying data source, which can lead to cost savings and increased longevity of the resource -* Scalability: Enhances the scalability of applications by efficiently handling increases in load without proportional increases in resource utilization +* Reduced Load: Decreases the load on the underlying data source, which can lead to cost savings and increased longevity + of the resource +* Scalability: Enhances the scalability of applications by efficiently handling increases in load without proportional + increases in resource utilization Trade-Offs: * Complexity: Introduces complexity in terms of cache invalidation, consistency, and synchronization * Resource Utilization: Requires additional memory or storage resources to maintain the cache -* Stale Data: There's a risk of serving outdated data if the cache is not properly invalidated or updated when the underlying data changes +* Stale Data: There's a risk of serving outdated data if the cache is not properly invalidated or updated when the + underlying data changes ## Related patterns -* [Proxy](https://java-design-patterns.com/patterns/proxy/): Caching can be implemented using the Proxy pattern, where the proxy object intercepts requests and returns cached data if available -* [Observer](https://java-design-patterns.com/patterns/observer/): Can be used to notify the cache when the underlying data changes, so that it can be updated or invalidated accordingly -* [Decorator](https://java-design-patterns.com/patterns/decorator/): Can be used to add caching behavior to an existing object without modifying its code -* [Strategy](https://java-design-patterns.com/patterns/strategy/): Different caching strategies can be implemented using the Strategy pattern, allowing the application to switch between them at runtime +* [Proxy](https://java-design-patterns.com/patterns/proxy/): Caching can be implemented using the Proxy pattern, where + the proxy object intercepts requests and returns cached data if available +* [Observer](https://java-design-patterns.com/patterns/observer/): Can be used to notify the cache when the underlying + data changes, so that it can be updated or invalidated accordingly +* [Decorator](https://java-design-patterns.com/patterns/decorator/): Can be used to add caching behavior to an existing + object without modifying its code +* [Strategy](https://java-design-patterns.com/patterns/strategy/): Different caching strategies can be implemented using + the Strategy pattern, allowing the application to switch between them at runtime ## Credits diff --git a/callback/README.md b/callback/README.md index 543b8626f..3af2f2d60 100644 --- a/callback/README.md +++ b/callback/README.md @@ -11,7 +11,8 @@ tag: ## 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. ## Also known as @@ -22,15 +23,17 @@ Callback is a piece of executable code that is passed as an argument to other co Real world example -> We need to be notified after the 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 the 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 an executor which will be called at a defined moment. +> Callback is a method passed to an executor which will be called at a 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** @@ -69,8 +72,8 @@ public final class SimpleTask extends Task { 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.")); + var task=new SimpleTask(); + task.executeWith(()->LOGGER.info("I'm done now.")); ``` ## Class diagram @@ -89,13 +92,15 @@ Use the Callback pattern when * GUI frameworks often use callbacks for event handling, such as user interactions (clicks, key presses) * Node.js heavily relies on callbacks for non-blocking I/O operations -* Frameworks that deal with asynchronous operations, like Promises in JavaScript, use callbacks to handle the resolution or rejection of asynchronous tasks +* Frameworks that deal with asynchronous operations, like Promises in JavaScript, use callbacks to handle the resolution + or rejection of asynchronous tasks ## Consequences Benefits: -* Decouples the execution logic of an operation from the signaling or notification logic, enhancing modularity and reusability +* Decouples the execution logic of an operation from the signaling or notification logic, enhancing modularity and + reusability * Facilitates asynchronous processing, improving the responsiveness and scalability of applications * Enables a reactive programming model where components can react to events as they occur @@ -103,16 +108,21 @@ Trade-offs: * Callback hell or pyramid of doom: Deeply nested callbacks can lead to code that is hard to read and maintain * Inversion of control can lead to harder-to-follow code flow, making debugging more challenging -* Potential issues with error handling, especially in languages or environments where exceptions are used, as errors might need to be propagated through callbacks +* Potential issues with error handling, especially in languages or environments where exceptions are used, as errors + might need to be propagated through callbacks ## Related patterns -[Observer](https://java-design-patterns.com/patterns/observer/): Callbacks can be seen as a more dynamic and lightweight form of the Observer pattern, with the ability to subscribe and unsubscribe callback functions dynamically -[Command](https://java-design-patterns.com/patterns/command/): Callbacks can be implemented as Command objects in scenarios where more flexibility or statefulness is required in the callback operation -[Promise](https://java-design-patterns.com/patterns/promise/): In some languages or frameworks, Promises or Futures can be used to handle asynchronous operations more cleanly, often using callbacks for success or failure cases +[Observer](https://java-design-patterns.com/patterns/observer/): Callbacks can be seen as a more dynamic and lightweight +form of the Observer pattern, with the ability to subscribe and unsubscribe callback functions dynamically +[Command](https://java-design-patterns.com/patterns/command/): Callbacks can be implemented as Command objects in +scenarios where more flexibility or statefulness is required in the callback operation +[Promise](https://java-design-patterns.com/patterns/promise/): In some languages or frameworks, Promises or Futures can +be used to handle asynchronous operations more cleanly, often using callbacks for success or failure cases ## 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 a callback that will be triggered every time a 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. * [JavaScript: The Good Parts](https://amzn.to/3TiQV61) * [Node.js Design Patterns - Third edition: Design and implement production-grade Node.js applications using proven patterns and techniques](https://amzn.to/3VssjKG) diff --git a/chain-of-responsibility/README.md b/chain-of-responsibility/README.md index 175143491..e33a88cd5 100644 --- a/chain-of-responsibility/README.md +++ b/chain-of-responsibility/README.md @@ -15,27 +15,27 @@ tag: ## 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 +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 +> The Orc King gives loud orders to his army. The closest one to react is the commander, then > an officer, and then a soldier. The commander, officer, and soldier form a chain of responsibility. In plain words -> It helps to build a chain of objects. A request enters from one end and keeps going from an object +> 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 +> 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** @@ -56,11 +56,11 @@ public class Request { this.requestType = Objects.requireNonNull(requestType); this.requestDescription = Objects.requireNonNull(requestDescription); } - + public void markHandled() { this.handled = true; } - + @Override public String toString() { return getRequestDescription(); @@ -77,37 +77,37 @@ Next, we show the request handler hierarchy. ```java public interface RequestHandler { - boolean canHandleRequest(Request req); + boolean canHandleRequest(Request req); - int getPriority(); + int getPriority(); - void handle(Request req); + void handle(Request req); - String name(); + String name(); } @Slf4j public class OrcCommander implements RequestHandler { - @Override - public boolean canHandleRequest(Request req) { - return req.getRequestType() == RequestType.DEFEND_CASTLE; - } + @Override + public boolean canHandleRequest(Request req) { + return req.getRequestType() == RequestType.DEFEND_CASTLE; + } - @Override - public int getPriority() { - return 2; - } + @Override + public int getPriority() { + return 2; + } - @Override - public void handle(Request req) { - req.markHandled(); - LOGGER.info("{} handling request \"{}\"", name(), req); - } + @Override + public void handle(Request req) { + req.markHandled(); + LOGGER.info("{} handling request \"{}\"", name(), req); + } - @Override - public String name() { - return "Orc commander"; - } + @Override + public String name() { + return "Orc commander"; + } } // OrcOfficer and OrcSoldier are defined similarly as OrcCommander @@ -143,10 +143,10 @@ public class OrcKing { The chain of responsibility in action. ```java -var king = new OrcKing(); -king.makeRequest(new Request(RequestType.DEFEND_CASTLE, "defend castle")); -king.makeRequest(new Request(RequestType.TORTURE_PRISONER, "torture prisoner")); -king.makeRequest(new Request(RequestType.COLLECT_TAX, "collect tax")); +var king=new OrcKing(); + king.makeRequest(new Request(RequestType.DEFEND_CASTLE,"defend castle")); + king.makeRequest(new Request(RequestType.TORTURE_PRISONER,"torture prisoner")); + king.makeRequest(new Request(RequestType.COLLECT_TAX,"collect tax")); ``` The console output. @@ -165,7 +165,8 @@ Orc soldier handling request "collect tax" 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. +* 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. @@ -183,20 +184,25 @@ Use Chain of Responsibility when Benefits: * Reduced coupling. The sender of a request does not need to know the concrete handler that will process the request. -* Increased flexibility in assigning responsibilities to objects. You can add or change responsibilities for handling a request by changing the members and order of the chain. +* Increased flexibility in assigning responsibilities to objects. You can add or change responsibilities for handling a + request by changing the members and order of the chain. * Allows you to set a default handler if no concrete handler can handle the request. Trade-Offs: * It can be challenging to debug and understand the flow, especially if the chain is long and complex. * The request might end up unhandled if the chain doesn't include a catch-all handler. -* Performance concerns might arise due to potentially going through several handlers before finding the right one, or not finding it at all. +* Performance concerns might arise due to potentially going through several handlers before finding the right one, or + not finding it at all. ## Related Patterns -[Command](https://java-design-patterns.com/patterns/command/): can be used to encapsulate a request as an object, which might be passed along the chain. -[Composite](https://java-design-patterns.com/patterns/composite/): the Chain of Responsibility is often applied in conjunction with the Composite pattern. -[Decorator](https://java-design-patterns.com/patterns/decorator/): decorators can be chained in a similar manner as responsibilities in the Chain of Responsibility pattern. +[Command](https://java-design-patterns.com/patterns/command/): can be used to encapsulate a request as an object, which +might be passed along the chain. +[Composite](https://java-design-patterns.com/patterns/composite/): the Chain of Responsibility is often applied in +conjunction with the Composite pattern. +[Decorator](https://java-design-patterns.com/patterns/decorator/): decorators can be chained in a similar manner as +responsibilities in the Chain of Responsibility pattern. ## Credits diff --git a/circuit-breaker/README.md b/circuit-breaker/README.md index 9d43ac892..394d5d1d5 100644 --- a/circuit-breaker/README.md +++ b/circuit-breaker/README.md @@ -14,38 +14,41 @@ tag: ## Intent -The Circuit Breaker pattern aims to prevent a software system from making calls to a part of the system that is either failing or showing signs of distress. It is a way to gracefully degrade functionality when a dependent service is not responding, rather than failing completely. +The Circuit Breaker pattern aims to prevent a software system from making calls to a part of the system that is either +failing or showing signs of distress. It is a way to gracefully degrade functionality when a dependent service is not +responding, rather than failing completely. ## Explanation Real world example -> Imagine a web application that has both local files/images and remote services that are used for -> fetching data. These remote services may be either healthy and responsive at times, or may become -> slow and unresponsive at some point of time due to variety of reasons. So if one of the remote -> services is slow or not responding successfully, our application will try to fetch response from -> the remote service using multiple threads/processes, soon all of them will hang (also called -> [thread starvation](https://en.wikipedia.org/wiki/Starvation_(computer_science))) causing our entire web application to 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 remote service failure. Meanwhile, the other services that are working +> Imagine a web application that has both local files/images and remote services that are used for +> fetching data. These remote services may be either healthy and responsive at times, or may become +> slow and unresponsive at some point of time due to variety of reasons. So if one of the remote +> services is slow or not responding successfully, our application will try to fetch response from +> the remote service using multiple threads/processes, soon all of them will hang (also called +> [thread starvation](https://en.wikipedia.org/wiki/Starvation_(computer_science))) causing our entire web application +> to 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 remote service failure. Meanwhile, the other services that are working > normally, should keep functioning unaffected by this failure. In plain words -> 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 +> 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 +> 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 -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 +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: @@ -55,6 +58,7 @@ The service architecture is as follows: In terms of code, the end user application is: ```java + @Slf4j public class App { @@ -114,7 +118,7 @@ public class App { } ``` -The monitoring service: +The monitoring service: ```java public class MonitoringService { @@ -160,147 +164,154 @@ public class MonitoringService { } } ``` -As it can be seen, it does the call to get local resources directly, but it wraps the call to + +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 DefaultCircuitBreaker implements CircuitBreaker { - private final long timeout; - private final long retryTimePeriod; - private final RemoteService service; - long lastFailureTime; - private String lastFailureResponse; - int failureCount; - private final int failureThreshold; - private State state; - // Future time offset, in nanoseconds - private final long futureTime = 1_000_000_000_000L; + private final long timeout; + private final long retryTimePeriod; + private final RemoteService service; + long lastFailureTime; + private String lastFailureResponse; + int failureCount; + private final int failureThreshold; + private State state; + // Future time offset, in nanoseconds + private final long futureTime = 1_000_000_000_000L; - /** - * Constructor to create an instance of Circuit Breaker. - * - * @param timeout Timeout for the API request. Not necessary for this simple example - * @param failureThreshold Number of failures we receive from the depended service before changing - * state to 'OPEN' - * @param retryTimePeriod Time period after which a new request is made to remote service for - * status check. - */ - DefaultCircuitBreaker(RemoteService serviceToCall, long timeout, int failureThreshold, - long retryTimePeriod) { - this.service = serviceToCall; - // We start in a closed state hoping that everything is fine - this.state = State.CLOSED; - this.failureThreshold = failureThreshold; - // Timeout for the API request. - // Used to break the calls made to remote resource if it exceeds the limit - this.timeout = timeout; - this.retryTimePeriod = retryTimePeriod; - //An absurd amount of time in future which basically indicates the last failure never happened - this.lastFailureTime = System.nanoTime() + futureTime; - this.failureCount = 0; + /** + * Constructor to create an instance of Circuit Breaker. + * + * @param timeout Timeout for the API request. Not necessary for this simple example + * @param failureThreshold Number of failures we receive from the depended service before changing + * state to 'OPEN' + * @param retryTimePeriod Time period after which a new request is made to remote service for + * status check. + */ + DefaultCircuitBreaker(RemoteService serviceToCall, long timeout, int failureThreshold, + long retryTimePeriod) { + this.service = serviceToCall; + // We start in a closed state hoping that everything is fine + this.state = State.CLOSED; + this.failureThreshold = failureThreshold; + // Timeout for the API request. + // Used to break the calls made to remote resource if it exceeds the limit + this.timeout = timeout; + this.retryTimePeriod = retryTimePeriod; + //An absurd amount of time in future which basically indicates the last failure never happened + this.lastFailureTime = System.nanoTime() + futureTime; + this.failureCount = 0; + } + + // Reset everything to defaults + @Override + public void recordSuccess() { + this.failureCount = 0; + this.lastFailureTime = System.nanoTime() + futureTime; + this.state = State.CLOSED; + } + + @Override + public void recordFailure(String response) { + failureCount = failureCount + 1; + this.lastFailureTime = System.nanoTime(); + // Cache the failure response for returning on open state + this.lastFailureResponse = response; + } + + // Evaluate the current state based on failureThreshold, failureCount and lastFailureTime. + protected void evaluateState() { + if (failureCount >= failureThreshold) { //Then something is wrong with remote service + if ((System.nanoTime() - lastFailureTime) > retryTimePeriod) { + //We have waited long enough and should try checking if service is up + state = State.HALF_OPEN; + } else { + //Service would still probably be down + state = State.OPEN; + } + } else { + //Everything is working fine + state = State.CLOSED; } + } - // Reset everything to defaults - @Override - public void recordSuccess() { - this.failureCount = 0; - this.lastFailureTime = System.nanoTime() + futureTime; - this.state = State.CLOSED; - } + @Override + public String getState() { + evaluateState(); + return state.name(); + } - @Override - public void recordFailure(String response) { - failureCount = failureCount + 1; + /** + * Break the circuit beforehand if it is known service is down Or connect the circuit manually if + * service comes online before expected. + * + * @param state State at which circuit is in + */ + @Override + public void setState(State state) { + this.state = state; + switch (state) { + case OPEN -> { + this.failureCount = failureThreshold; this.lastFailureTime = System.nanoTime(); - // Cache the failure response for returning on open state - this.lastFailureResponse = response; + } + case HALF_OPEN -> { + this.failureCount = failureThreshold; + this.lastFailureTime = System.nanoTime() - retryTimePeriod; + } + default -> this.failureCount = 0; } + } - // Evaluate the current state based on failureThreshold, failureCount and lastFailureTime. - protected void evaluateState() { - if (failureCount >= failureThreshold) { //Then something is wrong with remote service - if ((System.nanoTime() - lastFailureTime) > retryTimePeriod) { - //We have waited long enough and should try checking if service is up - state = State.HALF_OPEN; - } else { - //Service would still probably be down - state = State.OPEN; - } - } else { - //Everything is working fine - state = State.CLOSED; - } - } - - @Override - public String getState() { - evaluateState(); - return state.name(); - } - - /** - * Break the circuit beforehand if it is known service is down Or connect the circuit manually if - * service comes online before expected. - * - * @param state State at which circuit is in - */ - @Override - public void setState(State state) { - this.state = state; - switch (state) { - case OPEN -> { - this.failureCount = failureThreshold; - this.lastFailureTime = System.nanoTime(); - } - case HALF_OPEN -> { - this.failureCount = failureThreshold; - this.lastFailureTime = System.nanoTime() - retryTimePeriod; - } - default -> this.failureCount = 0; - } - } - - /** - * Executes service call. - * - * @return Value from the remote resource, stale response or a custom exception - */ - @Override - public String attemptRequest() throws RemoteServiceException { - evaluateState(); - if (state == State.OPEN) { - // return cached response if the circuit is in OPEN state - return this.lastFailureResponse; - } else { - // Make the API request if the circuit is not OPEN - try { - //In a real application, this would be run in a thread and the timeout - //parameter of the circuit breaker would be utilized to know if service - //is working. Here, we simulate that based on server response itself - var response = service.call(); - // Yay!! the API responded fine. Let's reset everything. - recordSuccess(); - return response; - } catch (RemoteServiceException ex) { - recordFailure(ex.getMessage()); - throw ex; - } - } + /** + * Executes service call. + * + * @return Value from the remote resource, stale response or a custom exception + */ + @Override + public String attemptRequest() throws RemoteServiceException { + evaluateState(); + if (state == State.OPEN) { + // return cached response if the circuit is in OPEN state + return this.lastFailureResponse; + } else { + // Make the API request if the circuit is not OPEN + try { + //In a real application, this would be run in a thread and the timeout + //parameter of the circuit breaker would be utilized to know if service + //is working. Here, we simulate that based on server response itself + var response = service.call(); + // Yay!! the API responded fine. Let's reset everything. + recordSuccess(); + return response; + } catch (RemoteServiceException ex) { + recordFailure(ex.getMessage()); + throw ex; + } } + } } ``` -How does the above pattern prevent failures? Let's understand via this finite state machine +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. +- 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 @@ -330,14 +341,18 @@ Benefits: Trade-Offs: -* The complexity of the system increases as the pattern requires additional logic to detect failures and manage the state of the circuit breaker -* May lead to system degradation if not properly configured, as legitimate requests might be blocked if the circuit is open +* The complexity of the system increases as the pattern requires additional logic to detect failures and manage the + state of the circuit breaker +* May lead to system degradation if not properly configured, as legitimate requests might be blocked if the circuit is + open * Requires careful tuning of thresholds and timeout periods to balance between responsiveness and protection ## Related Patterns -- [Retry Pattern](https://github.com/iluwatar/java-design-patterns/tree/master/retry): Can be used in conjunction with the Circuit Breaker pattern to retry failed operations before opening the circuit -- [Bulkhead Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead): Can be used to isolate different parts of the system to prevent failures from spreading across the system +- [Retry Pattern](https://github.com/iluwatar/java-design-patterns/tree/master/retry): Can be used in conjunction with + the Circuit Breaker pattern to retry failed operations before opening the circuit +- [Bulkhead Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead): Can be used to isolate + different parts of the system to prevent failures from spreading across the system ## Credits diff --git a/client-session/README.md b/client-session/README.md index c88c019fe..bd1fbc9fe 100644 --- a/client-session/README.md +++ b/client-session/README.md @@ -13,21 +13,35 @@ tags: ## Intent -The Client Session design pattern aims to maintain a user's state and data across multiple requests within a web application, ensuring a continuous and personalized user experience. +The Client Session design pattern aims to maintain a user's state and data across multiple requests within a web +application, ensuring a continuous and personalized user experience. ## Explanation Real-World Example -> You're looking to create a data management app allowing users to send requests to the server to modify and make changes to data stored on their devices. These requests are small and the data is individual to each user, negating the need for a large scale database implementation. Using the client session pattern, you are able to handle multiple concurrent requests, load balancing clients across different servers with ease due to servers remaining stateless. You also remove the need to store session IDs on the server side due to clients providing all the information that a server needs to perform their process. +> You're looking to create a data management app allowing users to send requests to the server to modify and make +> changes to data stored on their devices. These requests are small and the data is individual to each user, negating the +> need for a large scale database implementation. Using the client session pattern, you are able to handle multiple +> concurrent requests, load balancing clients across different servers with ease due to servers remaining stateless. You +> also remove the need to store session IDs on the server side due to clients providing all the information that a server +> needs to perform their process. In Plain words -> Instead of storing information about the current client and the information being accessed on the server, it is maintained client side only. Client has to send session data with each request to the server and has to send an updated state back to the client, which is stored on the clients machine. The server doesn't have to store the client information. ([ref](https://dzone.com/articles/practical-php-patterns/practical-php-patterns-client)) +> Instead of storing information about the current client and the information being accessed on the server, it is +> maintained client side only. Client has to send session data with each request to the server and has to send an updated +> state back to the client, which is stored on the clients machine. The server doesn't have to store the client +> information. ([ref](https://dzone.com/articles/practical-php-patterns/practical-php-patterns-client)) **Programmatic Example** -Here is the sample code to describe the client-session pattern. In the below code we are first creating an instance of the Server. This server instance will then be used to get Session objects for two clients. As you can see from the code below the Session object can be used to store any relevant information that are required by the server to process the client request. These session objects will then be passed on with every Request to the server. The Request will have the Session object that stores the relevant client details along with the required data for processing the request. The session information in every request helps the server identify the client and process the request accordingly. +Here is the sample code to describe the client-session pattern. In the below code we are first creating an instance of +the Server. This server instance will then be used to get Session objects for two clients. As you can see from the code +below the Session object can be used to store any relevant information that are required by the server to process the +client request. These session objects will then be passed on with every Request to the server. The Request will have the +Session object that stores the relevant client details along with the required data for processing the request. The +session information in every request helps the server identify the client and process the request accordingly. ```java public class App { @@ -93,20 +107,27 @@ Use the client state pattern when: Benefits: * Improved server performance by reducing the need to store user state on the server. -* Enhanced user experience through personalized content and seamless navigation across different parts of the application. +* Enhanced user experience through personalized content and seamless navigation across different parts of the + application. * Flexibility in managing sessions through various client-side storage mechanisms (e.g., cookies, Web Storage API). Trade-offs: -* Potential security risks if sensitive information is stored in client sessions without proper encryption and validation. -* Dependence on client-side capabilities and settings, such as cookie policies, which can vary across browsers and user configurations. -* Increased complexity in session management logic, especially in handling session expiration, renewal, and synchronization across multiple devices or tabs. +* Potential security risks if sensitive information is stored in client sessions without proper encryption and + validation. +* Dependence on client-side capabilities and settings, such as cookie policies, which can vary across browsers and user + configurations. +* Increased complexity in session management logic, especially in handling session expiration, renewal, and + synchronization across multiple devices or tabs. ## Related Patterns -* Server Session: Often used in conjunction with the Client Session pattern to provide a balance between client-side efficiency and server-side control. -* [Singleton](https://java-design-patterns.com/patterns/singleton/): Ensuring a single instance of a user's session throughout the application. -* [State](https://java-design-patterns.com/patterns/state/): Managing state transitions in a session, such as authenticated, guest, or expired states. +* Server Session: Often used in conjunction with the Client Session pattern to provide a balance between client-side + efficiency and server-side control. +* [Singleton](https://java-design-patterns.com/patterns/singleton/): Ensuring a single instance of a user's session + throughout the application. +* [State](https://java-design-patterns.com/patterns/state/): Managing state transitions in a session, such as + authenticated, guest, or expired states. ## Credits diff --git a/collecting-parameter/README.md b/collecting-parameter/README.md index 99e7bea35..34b8bf545 100644 --- a/collecting-parameter/README.md +++ b/collecting-parameter/README.md @@ -1,44 +1,59 @@ --- -title: Collecting Parameter -category: Idiom +title: Collecting Parameter +category: Behavioral language: en tag: -- Generic + - Accumulation + - Generic --- -## Name -Collecting Parameter +## Also known as + +* Collector +* Accumulator ## Intent -To store the collaborative result of numerous methods within a collection. + +Aims to simplify methods that collect information by passing a single collection object through various method calls, +allowing them to add results to this collection rather than each method creating its own collection. ## Explanation + ### Real-world example + Within a large corporate building, there exists a global printer queue that is a collection of all the printing jobs that are currently pending. Various floors contain different models of printers, each having a different printing -policy. We must construct a program that can continually add appropriate printing jobs to a collection, which is called the *collecting parameter*. +policy. We must construct a program that can continually add appropriate printing jobs to a collection, which is called +the *collecting parameter*. ### In plain words + Instead of having one giant method that contains numerous policies for collecting information into a variable, we can -create numerous smaller functions that each take parameter, and append new information. We can pass the parameter to -all of these smaller functions and by the end, we will have what we wanted originally. This time, the code is cleaner -and easier to understand. Because the larger function has been broken down, the code is also easier to modify as changes -are localised to the smaller functions. +create numerous smaller functions that each take parameter, and append new information. We can pass the parameter to all +of these smaller functions and by the end, we will have what we wanted originally. This time, the code is cleaner and +easier to understand. Because the larger function has been broken down, the code is also easier to modify as changes are +localised to the smaller functions. ### Wikipedia says -In the Collecting Parameter idiom a collection (list, map, etc.) is passed repeatedly as a parameter to a method which adds items to the collection. + +In the Collecting Parameter idiom a collection (list, map, etc.) is passed repeatedly as a parameter to a method which +adds items to the collection. ### Programmatic example + Coding our example from above, we may use the collection `result` as a collecting parameter. The following restrictions are implemented: + - If an A4 paper is coloured, it must also be single-sided. All other non-coloured papers are accepted - A3 papers must be non-coloured and single-sided - A2 papers must be single-page, single-sided, and non-coloured ```java package com.iluwatar.collectingparameter; + import java.util.LinkedList; import java.util.Queue; + public class App { static PrinterQueue printerQueue = PrinterQueue.getInstance(); @@ -57,10 +72,10 @@ public class App { /* This variable is the collecting parameter. - */ + */ var result = new LinkedList(); - /* + /* * Using numerous sub-methods to collaboratively add information to the result collecting parameter */ addA4Papers(result); @@ -76,6 +91,7 @@ appropriate print jobs as per the policy described previously. The three policie ```java public class App { static PrinterQueue printerQueue = PrinterQueue.getInstance(); + /** * Adds A4 document jobs to the collecting parameter according to some policy that can be whatever the client * (the print center) wants. @@ -132,7 +148,7 @@ public class App { // Encoding the policy into a Boolean: the A2 paper must be single page, single-sided, and non-coloured. var isNotColouredSingleSidedAndOnePage = nextItem.pageCount == 1 && !nextItem.isDoubleSided - && !nextItem.isColour; + && !nextItem.isColour; if (isNotColouredSingleSidedAndOnePage) { printerItemsCollection.add(nextItem); } @@ -142,8 +158,9 @@ public class App { } ``` -Each method takes a collecting parameter as an argument. It then adds elements, taken from a global variable, -to this collecting parameter if each element satisfies a given criteria. These methods can have whatever policy the client desires. +Each method takes a collecting parameter as an argument. It then adds elements, taken from a global variable, to this +collecting parameter if each element satisfies a given criteria. These methods can have whatever policy the client +desires. In this programmatic example, three print jobs are added to the queue. Only the first two print jobs should be added to the collecting parameter as per the policy. The elements of the `result` variable after execution are, @@ -156,42 +173,69 @@ the collecting parameter as per the policy. The elements of the `result` variabl which is what we expected. ## Class diagram + ![alt text](./etc/collecting-parameter.urm.png "Collecting Parameter") ## Applicability + Use the Collecting Parameter design pattern when -- you want to return a collection or object that is the collaborative result of several methods -- You want to simplify a method that accumulates data as the original method is too complex + +- When multiple methods produce a collection of results and you want to aggregate these results in a unified manner. +- In scenarios where reducing the number of collections created by methods can improve memory efficiency and + performance. +- When you're refactoring large methods that perform multiple tasks, including the collection of results from various + operations. ## Tutorials + Tutorials for this method are found in: + - [Refactoring To Patterns](http://www.tarrani.net/RefactoringToPatterns.pdf) by Joshua Kerivsky -- [Smalltalk Best Practice Patterns](https://ptgmedia.pearsoncmg.com/images/9780134769042/samplepages/013476904X.pdf) by Kent Beck +- [Smalltalk Best Practice Patterns](https://ptgmedia.pearsoncmg.com/images/9780134769042/samplepages/013476904X.pdf) by + Kent Beck ## Known uses + Joshua Kerivsky gives a real-world example in his book 'Refactoring to Patterns'. He gives an example of using the Collecting Parameter Design Pattern to create a `toString()` method for an XML tree. Without using this design pattern, -this would require a bulky function with conditionals and concatenation that would worsen code readability. Such a method -can be broken down into smaller methods, each appending their own set of information to the collecting parameter. - +this would require a bulky function with conditionals and concatenation that would worsen code readability. Such a +method can be broken down into smaller methods, each appending their own set of information to the collecting parameter. See this in [Refactoring To Patterns](http://www.tarrani.net/RefactoringToPatterns.pdf). -## Consequences -Pros: -- Makes code more readable -- Avoids 'linkages', where numerous methods reference the same global variable -- Increases maintainability by decomposing larger functions +Other examples include: -Cons: -- May increase code length -- Adds 'layers' of methods +- Aggregating error messages or validation failures across a complex validation process. +- Collecting elements or information while traversing a complex data structure. +- Refactoring complex reporting functionalities where various parts of a report are generated by different methods. + +## Consequences + +Benefits: + +- Reduces code duplication by centralizing collection handling in a single place. +- Enhances clarity and maintainability by making it explicit where and how results are collected. +- Improves performance by minimizing the creation and management of multiple collection objects. + +Trade-offs: + +- Increases coupling between the caller and the methods being called since they must agree on the collection to use. +- May introduce side effects in methods if not carefully managed, as methods are no longer self-contained in their + result handling. ## Related patterns -- [Compose Methods](https://www.geeksforgeeks.org/composite-design-pattern/) + +- [Composite](https://java-design-patterns.com/patterns/composite/): Can be used in tandem with Collecting Parameter + when dealing with hierarchical structures, allowing results to be collected across a composite structure. +- [Visitor](https://java-design-patterns.com/patterns/visitor/): Often used together, where Visitor handles traversal + and operations on a structure, and Collecting Parameter accumulates the results. +- [Command](https://java-design-patterns.com/patterns/command/): Commands may utilize Collecting Parameter to aggregate + results from multiple operations executed by the command objects. ## Credits -Following books were used: -- [Refactoring To Patterns](http://www.tarrani.net/RefactoringToPatterns.pdf) by Joshua Kerivsky -- [Smalltalk Best Practice Patterns](https://ptgmedia.pearsoncmg.com/images/9780134769042/samplepages/013476904X.pdf) by Kent Beck -Sites: + +- [Refactoring To Patterns](http://www.tarrani.net/RefactoringToPatterns.pdf) by Joshua Kerivsky +- [Smalltalk Best Practice Patterns](https://ptgmedia.pearsoncmg.com/images/9780134769042/samplepages/013476904X.pdf) by + Kent Beck - [Wiki](https://wiki.c2.com/?CollectingParameter) +- [Refactoring: Improving the Design of Existing Code](https://amzn.to/3TVEgaB) +- [Clean Code: A Handbook of Agile Software Craftsmanship](https://amzn.to/4aApLP0) diff --git a/collecting-parameter/src/test/java/com/iluwatar/collectingparameter/PrinterQueueTest.java b/collecting-parameter/src/test/java/com/iluwatar/collectingparameter/PrinterQueueTest.java index 8cbe071a5..fc633108b 100644 --- a/collecting-parameter/src/test/java/com/iluwatar/collectingparameter/PrinterQueueTest.java +++ b/collecting-parameter/src/test/java/com/iluwatar/collectingparameter/PrinterQueueTest.java @@ -27,8 +27,6 @@ package com.iluwatar.collectingparameter; import org.junit.jupiter.api.Assertions; import org.junit.jupiter.api.Test; import org.junit.jupiter.api.Timeout; -import java.util.LinkedList; -import java.util.Queue; import static org.junit.jupiter.api.Assertions.*;