Skip to content

Commit e3f608f

Browse files
rdmuellerrdmueller
authored
Merge pull request #159 from raifdmueller/feat/umbrella-anchors
feat: umbrella anchors with GoF sub-patterns
2 parents 5320e82 + 31ee434 commit e3f608f

35 files changed

Lines changed: 986 additions & 5 deletions

‎docs/anchors/gof-abstract-factory-pattern.adoc‎

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
= GoF-Abstract Factory Pattern
2+
:categories: design-principles
3+
:roles: software-developer, software-architect
4+
:umbrella: gof-design-patterns
5+
:tier: 2
6+
:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
7+
:tags: GoF, design pattern, creational, abstract factory, family, platform independence
8+
9+
[%collapsible]
10+
====
11+
Full Name:: GoF Abstract Factory Pattern (Creational)
12+
13+
Also known as:: Kit
14+
15+
[discrete]
16+
== *Intent*:
17+
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
18+
19+
[discrete]
20+
== *When to Use*:
21+
* When a system should be independent of how its products are created
22+
* When a system should be configured with one of multiple families of products
23+
* When related product objects are designed to be used together and you need to enforce this constraint
24+
25+
[discrete]
26+
== *Prompt Example*:
27+
"Erstelle eine Abstract Factory nach GoF, die UI-Komponenten für verschiedene Plattformen (Web, Mobile, Desktop) erzeugt, ohne dass der Client die konkreten Klassen kennen muss."
28+
29+
[discrete]
30+
== *Related Anchors*:
31+
* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
32+
====

‎docs/anchors/gof-adapter-pattern.adoc‎

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
= GoF-Adapter Pattern
2+
:categories: design-principles
3+
:roles: software-developer, software-architect
4+
:umbrella: gof-design-patterns
5+
:tier: 1
6+
:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
7+
:tags: GoF, design pattern, structural, adapter, wrapper, interface conversion, compatibility
8+
9+
[%collapsible]
10+
====
11+
Full Name:: GoF Adapter Pattern (Structural)
12+
13+
Also known as:: Wrapper
14+
15+
[discrete]
16+
== *Intent*:
17+
Convert the interface of a class into another interface clients expect.
18+
19+
[discrete]
20+
== *When to Use*:
21+
* When you want to use an existing class whose interface doesn't match what you need
22+
* When you want to create a reusable class that cooperates with unrelated classes
23+
24+
[discrete]
25+
== *Prompt Example*:
26+
"Erstelle einen Adapter nach GoF, der die Legacy-API auf unser neues Interface mappt, ohne den bestehenden Code zu ändern."
27+
28+
[discrete]
29+
== *Related Anchors*:
30+
* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
31+
====

‎docs/anchors/gof-bridge-pattern.adoc‎

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
= GoF-Bridge Pattern
2+
:categories: design-principles
3+
:roles: software-developer, software-architect
4+
:umbrella: gof-design-patterns
5+
:tier: 2
6+
:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
7+
:tags: GoF, design pattern, structural, bridge, abstraction, implementation, decoupling
8+
9+
[%collapsible]
10+
====
11+
Full Name:: GoF Bridge Pattern (Structural)
12+
13+
[discrete]
14+
== *Intent*:
15+
Decouple an abstraction from its implementation so that the two can vary independently.
16+
17+
[discrete]
18+
== *When to Use*:
19+
* When you want to avoid a permanent binding between an abstraction and its implementation
20+
* When both the abstractions and their implementations should be extensible by subclassing
21+
* When changes in the implementation should have no impact on clients
22+
23+
[discrete]
24+
== *Prompt Example*:
25+
"Trenne die Rendering-Abstraktion von der plattformspezifischen Implementierung nach dem GoF-Bridge Pattern, damit beide unabhängig erweitert werden können."
26+
27+
[discrete]
28+
== *Related Anchors*:
29+
* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
30+
====

‎docs/anchors/gof-builder-pattern.adoc‎

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
= GoF-Builder Pattern
2+
:categories: design-principles
3+
:roles: software-developer, software-architect
4+
:umbrella: gof-design-patterns
5+
:tier: 1
6+
:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
7+
:tags: GoF, design pattern, creational, builder, construction, fluent interface, complex objects
8+
9+
[%collapsible]
10+
====
11+
Full Name:: GoF Builder Pattern (Creational)
12+
13+
[discrete]
14+
== *Intent*:
15+
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
16+
17+
[discrete]
18+
== *When to Use*:
19+
* When the algorithm for creating a complex object should be independent of the parts and how they are assembled
20+
* When the construction process must allow different representations
21+
22+
[discrete]
23+
== *Prompt Example*:
24+
"Implementiere einen Builder nach GoF für das QueryObject, mit Fluent API für Filter, Sortierung und Pagination."
25+
26+
[discrete]
27+
== *Related Anchors*:
28+
* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
29+
====

‎docs/anchors/gof-chain-of-responsibility-pattern.adoc‎

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
= GoF-Chain of Responsibility Pattern
2+
:categories: design-principles
3+
:roles: software-developer, software-architect
4+
:umbrella: gof-design-patterns
5+
:tier: 2
6+
:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
7+
:tags: GoF, design pattern, behavioral, chain of responsibility, handler, pipeline, middleware
8+
9+
[%collapsible]
10+
====
11+
Full Name:: GoF Chain of Responsibility Pattern (Behavioral)
12+
13+
[discrete]
14+
== *Intent*:
15+
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.
16+
17+
[discrete]
18+
== *When to Use*:
19+
* When more than one object may handle a request, and the handler isn't known a priori
20+
* When you want to issue a request to one of several objects without specifying the receiver explicitly
21+
* When the set of objects that can handle a request should be specified dynamically
22+
23+
[discrete]
24+
== *Prompt Example*:
25+
"Implementiere eine Middleware-Pipeline nach dem GoF-Chain of Responsibility Pattern, bei der jeder Handler die Anfrage entweder verarbeitet oder an den nächsten weitergibt."
26+
27+
[discrete]
28+
== *Related Anchors*:
29+
* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
30+
====

‎docs/anchors/gof-command-pattern.adoc‎

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
= GoF-Command Pattern
2+
:categories: design-principles
3+
:roles: software-developer, software-architect
4+
:umbrella: gof-design-patterns
5+
:tier: 1
6+
:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
7+
:tags: GoF, design pattern, behavioral, command, undo, queue, encapsulation, action
8+
9+
[%collapsible]
10+
====
11+
Full Name:: GoF Command Pattern (Behavioral)
12+
13+
[discrete]
14+
== *Intent*:
15+
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
16+
17+
[discrete]
18+
== *When to Use*:
19+
* When you want to parameterize objects with an action to perform
20+
* When you need undo/redo functionality
21+
* When you need to queue, log, or schedule requests
22+
23+
[discrete]
24+
== *Prompt Example*:
25+
"Implementiere ein Undo/Redo-System nach dem GoF-Command Pattern, bei dem jede Benutzeraktion als Command-Objekt gekapselt wird."
26+
27+
[discrete]
28+
== *Related Anchors*:
29+
* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
30+
====

‎docs/anchors/gof-composite-pattern.adoc‎

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
= GoF-Composite Pattern
2+
:categories: design-principles
3+
:roles: software-developer, software-architect
4+
:umbrella: gof-design-patterns
5+
:tier: 2
6+
:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
7+
:tags: GoF, design pattern, structural, composite, tree, hierarchy, part-whole
8+
9+
[%collapsible]
10+
====
11+
Full Name:: GoF Composite Pattern (Structural)
12+
13+
[discrete]
14+
== *Intent*:
15+
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly.
16+
17+
[discrete]
18+
== *When to Use*:
19+
* When you want to represent part-whole hierarchies of objects
20+
* When you want clients to be able to ignore the difference between compositions of objects and individual objects
21+
22+
[discrete]
23+
== *Prompt Example*:
24+
"Modelliere das Dateisystem nach dem GoF-Composite Pattern, sodass Dateien und Ordner einheitlich behandelt werden können."
25+
26+
[discrete]
27+
== *Related Anchors*:
28+
* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
29+
====

‎docs/anchors/gof-decorator-pattern.adoc‎

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
= GoF-Decorator Pattern
2+
:categories: design-principles
3+
:roles: software-developer, software-architect
4+
:umbrella: gof-design-patterns
5+
:tier: 1
6+
:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
7+
:tags: GoF, design pattern, structural, decorator, wrapper, dynamic behavior, composition
8+
9+
[%collapsible]
10+
====
11+
Full Name:: GoF Decorator Pattern (Structural)
12+
13+
Also known as:: Wrapper
14+
15+
[discrete]
16+
== *Intent*:
17+
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing.
18+
19+
[discrete]
20+
== *When to Use*:
21+
* To add responsibilities to objects dynamically and transparently
22+
* When extension by subclassing is impractical
23+
24+
[discrete]
25+
== *Prompt Example*:
26+
"Verwende das GoF-Decorator Pattern, um dem Logger dynamisch Formatierung, Timestamp und Filterung hinzuzufügen."
27+
28+
[discrete]
29+
== *Related Anchors*:
30+
* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
31+
====

‎docs/anchors/gof-design-patterns.adoc‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,7 @@
44
:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
55
:related: solid-principles, fowler-patterns, clean-architecture
66
:tags: design-patterns, gang-of-four, oop, creational, structural, behavioral
7+
:sub-anchors: gof-strategy-pattern, gof-observer-pattern, gof-factory-method-pattern, gof-singleton-pattern, gof-adapter-pattern, gof-decorator-pattern, gof-command-pattern, gof-facade-pattern, gof-template-method-pattern, gof-builder-pattern, gof-state-pattern, gof-proxy-pattern, gof-abstract-factory-pattern, gof-composite-pattern, gof-iterator-pattern, gof-mediator-pattern, gof-chain-of-responsibility-pattern, gof-bridge-pattern, gof-prototype-pattern, gof-flyweight-pattern, gof-interpreter-pattern, gof-memento-pattern, gof-visitor-pattern
78

89
[%collapsible]
910
====

‎docs/anchors/gof-facade-pattern.adoc‎

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
= GoF-Facade Pattern
2+
:categories: design-principles
3+
:roles: software-developer, software-architect
4+
:umbrella: gof-design-patterns
5+
:tier: 1
6+
:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
7+
:tags: GoF, design pattern, structural, facade, simplification, subsystem, unified interface
8+
9+
[%collapsible]
10+
====
11+
Full Name:: GoF Facade Pattern (Structural)
12+
13+
[discrete]
14+
== *Intent*:
15+
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
16+
17+
[discrete]
18+
== *When to Use*:
19+
* When you want to provide a simple interface to a complex subsystem
20+
* When there are many dependencies between clients and implementation classes
21+
22+
[discrete]
23+
== *Prompt Example*:
24+
"Erstelle eine Facade nach GoF für das Payment-Subsystem, die Validierung, Autorisierung und Abrechnung hinter einem einfachen Interface kapselt."
25+
26+
[discrete]
27+
== *Related Anchors*:
28+
* <<gof-design-patterns,GoF Design Patterns>> (Umbrella)
29+
====

0 commit comments

Comments
 (0)