From a258bcc1eb4a7e6c2bd51d69cd1fdd0fabc618b3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ilkka=20Sepp=C3=A4l=C3=A4?= Date: Mon, 12 Feb 2024 19:28:48 +0200 Subject: [PATCH] docs: fix line endings --- abstract-document/README.md | 29 +++++++---------------------- abstract-factory/README.md | 21 ++++++--------------- active-object/README.md | 16 +++++----------- 3 files changed, 18 insertions(+), 48 deletions(-) diff --git a/abstract-document/README.md b/abstract-document/README.md index 09d1d2732..7c30819c7 100644 --- a/abstract-document/README.md +++ b/abstract-document/README.md @@ -10,15 +10,11 @@ tag: ## 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 @@ -30,16 +26,11 @@ 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 { @@ -84,8 +75,7 @@ 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 { @@ -179,9 +169,7 @@ 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. @@ -205,10 +193,7 @@ some scenarios where the Abstract Document design pattern can be applicable: * 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 906f243fe..4d5ff98a2 100644 --- a/abstract-factory/README.md +++ b/abstract-factory/README.md @@ -14,32 +14,25 @@ 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 { @@ -148,9 +141,7 @@ 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 { diff --git a/active-object/README.md b/active-object/README.md index a3fbc6695..26e3e816a 100644 --- a/active-object/README.md +++ b/active-object/README.md @@ -9,21 +9,17 @@ tag: ## 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. +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** @@ -84,8 +80,7 @@ public abstract class ActiveCreature{ } ``` -We can see that any class that will extend the ActiveCreature class will have its own thread of control to invoke and -execute methods. +We can see that any class that will extend the ActiveCreature class will have its own thread of control to invoke and execute methods. For example, the Orc class: @@ -99,8 +94,7 @@ 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) {