diff --git a/docs/anchors/bdd-given-when-then.de.adoc b/docs/anchors/bdd-given-when-then.de.adoc new file mode 100644 index 0000000..a7d7106 --- /dev/null +++ b/docs/anchors/bdd-given-when-then.de.adoc @@ -0,0 +1,48 @@ += BDD (Behavior-Driven Development) +:categories: testing-quality +:roles: software-developer, qa-engineer, business-analyst, product-owner +:proponents: Dan North +:related: tdd-london-school, tdd-chicago-school, user-story-mapping +:tags: bdd, gherkin, cucumber, specification-by-example, three-amigos, given-when-then, living-documentation + +[%collapsible] +==== +Auch bekannt als:: Specification by Example, Executable Specifications + +[discrete] +== *Kernkonzepte*: + +Given-When-Then:: Strukturiertes Szenarioformat — Given eine Vorbedingung, When eine Aktion auftritt, Then ein erwartetes Ergebnis eintritt + +Specification by Example:: Konkrete Beispiele als ausführbare Spezifikationen, die das Systemverhalten definieren + +Three Amigos:: Kollaborative Entdeckungssitzungen zwischen Entwickler, Tester und Fachvertreter + +Gherkin-Syntax:: Domänenspezifische Sprache zum Schreiben menschenlesbarer, maschinenausführbarer Szenarien + +Living Documentation:: Tests, die als stets aktuelle Systemdokumentation dienen + +Outside-in-Spezifikation:: Vom gewünschten Geschäftsverhalten ausgehen, zur Implementierung hinarbeiten + +Ubiquitous Language:: Gemeinsames Vokabular, das technische und fachliche Stakeholder in Szenarien verbindet + +Discovery Workshops:: Strukturierte Gespräche, um Anforderungen durch Beispiele vor der Implementierung aufzudecken + + +Schlüsselvertreter:: Dan North ("Introducing BDD", 2006), Entwickler von JBehave, das Cucumbers Design beeinflusste (Cucumber erstellt von Aslak Hellesøy, 2008) + +[discrete] +== *Wann zu verwenden*: + +* Cross-funktionale Teams, die ein gemeinsames Verständnis der Anforderungen benötigen +* Systeme, in denen Geschäftsregeln komplex sind und klare Dokumentation erfordern +* Projekte, die ausführbare Akzeptanzkriterien benötigen +* Überbrückung von Kommunikationslücken zwischen technischen und nicht-technischen Stakeholdern + +[discrete] +== *Verwandte Anker*: + +* <> - Outside-in-Entwicklungsansatz, der BDD ergänzt +* <> - Entwicklerfokussierte TDD-Praxis +* <> - Anforderungsermittlung, die BDD-Szenarien speist +==== diff --git a/docs/anchors/cqrs.de.adoc b/docs/anchors/cqrs.de.adoc new file mode 100644 index 0000000..f76d208 --- /dev/null +++ b/docs/anchors/cqrs.de.adoc @@ -0,0 +1,49 @@ += CQRS (Command Query Responsibility Segregation) +:categories: software-architecture +:roles: software-architect, software-developer +:proponents: Greg Young, Bertrand Meyer, Udi Dahan +:related: domain-driven-design, hexagonal-architecture, fowler-patterns +:tags: cqrs, cqs, architecture, commands, queries, read-write-separation + +[%collapsible] +==== +Auch bekannt als:: CQS auf Architekturebene + +[discrete] +== *Kernkonzepte*: + +Command Query Separation (CQS):: Bertrand Meyers Prinzip — Methoden ändern entweder den Zustand (Commands) oder geben Daten zurück (Queries), niemals beides + +Commands:: Schreiboperationen, die den Zustand ändern und void zurückgeben; repräsentieren Absichten als unveränderliche Command-Objekte + +Queries:: Leseoperationen, die Daten ohne Seiteneffekte zurückgeben; sicher wiederholbar und cachebar + +Getrennte Lese-/Schreibmodelle:: Unabhängige Datenmodelle, die für ihren jeweiligen Zweck optimiert sind + +Eventual Consistency:: Das Lesemodell kann hinter dem Schreibmodell zurückbleiben; akzeptabler Kompromiss für Skalierbarkeit + +Ereignisbasierte Synchronisation:: Domain Events propagieren Änderungen von der Schreibseite zu Lesemodell-Projektionen + +Unabhängige Skalierbarkeit:: Lese- und Schreibseite können unabhängig skaliert, deployt und optimiert werden + +Event Sourcing optional:: CQRS erfordert kein Event Sourcing; die Muster sind komplementär, aber unabhängig + + +Schlüsselvertreter:: Greg Young (prägte CQRS), Bertrand Meyer (CQS-Ursprung, "Object-Oriented Software Construction", 1988), Udi Dahan + +[discrete] +== *Wann zu verwenden*: + +* Systeme mit asymmetrischer Lese-/Schreiblast +* Komplexe Domänen, in denen Lese- und Schreibmodelle erheblich voneinander abweichen +* Event-Sourced-Systeme, die materialisierte Views erfordern +* Hochperformante Systeme, die unabhängige Skalierung von Lese- und Schreibzugriffen benötigen +* Kollaborative Domänen mit aufgabenbasierten UIs + +[discrete] +== *Verwandte Anker*: + +* <> - Wird oft mit CQRS für komplexe Domänen kombiniert +* <> - Ports und Adapter ergänzen die CQRS-Trennung +* <> - CQRS baut auf Enterprise-Application-Patterns auf +==== diff --git a/docs/anchors/event-driven-architecture.de.adoc b/docs/anchors/event-driven-architecture.de.adoc new file mode 100644 index 0000000..7f1348b --- /dev/null +++ b/docs/anchors/event-driven-architecture.de.adoc @@ -0,0 +1,50 @@ += Event-Driven Architecture +:categories: software-architecture +:roles: software-architect, software-developer, devops-engineer +:proponents: Gregor Hohpe, Bobby Woolf, Martin Fowler +:related: domain-driven-design, hexagonal-architecture, clean-architecture +:tags: eda, events, async, messaging, publish-subscribe, decoupling, eventual-consistency + +[%collapsible] +==== +Auch bekannt als:: EDA, Message-Driven Architecture + +[discrete] +== *Kernkonzepte*: + +Event Producers und Consumers:: Komponenten kommunizieren durch das Aussenden und Reagieren auf Events statt durch direkte Aufrufe + +Publish-Subscribe:: Produzenten veröffentlichen Events, ohne zu wissen, welche Konsumenten sie verarbeiten werden + +Asynchrone Entkopplung:: Sender und Empfänger arbeiten zeitlich unabhängig; kein blockierendes Request-Response + +Message Queue:: Vermittler, der Events zwischen Produzenten und Konsumenten puffert (SQS, RabbitMQ, Kafka) + +At-least-once Delivery:: Die meisten Messaging-Systeme garantieren Zustellung, können aber Duplikate liefern, was idempotente Konsumenten erfordert + +Eventual Consistency:: Der Systemzustand konvergiert über die Zeit, anstatt nach jeder Operation sofort konsistent zu sein + +Event Notification:: Leichtgewichtiges Event-Signal, dass etwas passiert ist; Konsumenten entscheiden, ob sie handeln + +Event-Carried State Transfer:: Events tragen genug Daten, damit Konsumenten verarbeiten können, ohne den Produzenten zurückzurufen + +Choreographie vs. Orchestrierung:: Events können verteilte Workflows implizit (Choreographie) oder über einen zentralen Koordinator (Orchestrierung) auslösen + + +Schlüsselvertreter:: Gregor Hohpe, Bobby Woolf ("Enterprise Integration Patterns", 2003), Martin Fowler ("What do you mean by Event-Driven?", 2017) + +[discrete] +== *Wann zu verwenden*: + +* Systeme, die lose Kopplung zwischen Komponenten erfordern +* Workloads mit asynchronen Verarbeitungspipelines +* Architekturen, die unabhängige Skalierung von Produzenten und Konsumenten benötigen +* Verteilte Systeme, in denen Komponenten sich unabhängig weiterentwickeln müssen + +[discrete] +== *Verwandte Anker*: + +* <> - Domain Events sind ein DDD-Baustein +* <> - Message Queues als Driven Adapters +* <> - Events überqueren Architekturgrenzen über Interfaces +==== diff --git a/docs/anchors/gof-abstract-factory-pattern.de.adoc b/docs/anchors/gof-abstract-factory-pattern.de.adoc new file mode 100644 index 0000000..271acdc --- /dev/null +++ b/docs/anchors/gof-abstract-factory-pattern.de.adoc @@ -0,0 +1,32 @@ += GoF-Abstract Factory Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 2 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, creational, abstract factory, family, platform independence + +[%collapsible] +==== +Vollständiger Name:: GoF Abstract Factory Pattern (Creational) + +Auch bekannt als:: Kit + +[discrete] +== *Absicht*: +Biete ein Interface zur Erzeugung von Familien verwandter oder abhängiger Objekte, ohne deren konkrete Klassen zu spezifizieren. + +[discrete] +== *Wann zu verwenden*: +* Wenn ein System unabhängig davon sein soll, wie seine Produkte erzeugt werden +* Wenn ein System mit einer von mehreren Produktfamilien konfiguriert werden soll +* Wenn verwandte Produktobjekte für die gemeinsame Verwendung entworfen sind und du diese Einschränkung durchsetzen musst + +[discrete] +== *Prompt-Beispiel*: +"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." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-adapter-pattern.de.adoc b/docs/anchors/gof-adapter-pattern.de.adoc new file mode 100644 index 0000000..4685559 --- /dev/null +++ b/docs/anchors/gof-adapter-pattern.de.adoc @@ -0,0 +1,31 @@ += GoF-Adapter Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 1 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, structural, adapter, wrapper, interface conversion, compatibility + +[%collapsible] +==== +Vollständiger Name:: GoF Adapter Pattern (Structural) + +Auch bekannt als:: Wrapper + +[discrete] +== *Absicht*: +Konvertiere das Interface einer Klasse in ein anderes Interface, das Clients erwarten. + +[discrete] +== *Wann zu verwenden*: +* Wenn du eine existierende Klasse verwenden möchtest, deren Interface nicht zu deinen Anforderungen passt +* Wenn du eine wiederverwendbare Klasse erstellen möchtest, die mit nicht verwandten Klassen zusammenarbeitet + +[discrete] +== *Prompt-Beispiel*: +"Erstelle einen Adapter nach GoF, der die Legacy-API auf unser neues Interface mappt, ohne den bestehenden Code zu ändern." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-bridge-pattern.de.adoc b/docs/anchors/gof-bridge-pattern.de.adoc new file mode 100644 index 0000000..ca8bdba --- /dev/null +++ b/docs/anchors/gof-bridge-pattern.de.adoc @@ -0,0 +1,30 @@ += GoF-Bridge Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 2 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, structural, bridge, abstraction, implementation, decoupling + +[%collapsible] +==== +Vollständiger Name:: GoF Bridge Pattern (Structural) + +[discrete] +== *Absicht*: +Entkopple eine Abstraktion von ihrer Implementierung, sodass beide unabhängig voneinander variieren können. + +[discrete] +== *Wann zu verwenden*: +* Wenn du eine permanente Bindung zwischen einer Abstraktion und ihrer Implementierung vermeiden möchtest +* Wenn sowohl die Abstraktionen als auch ihre Implementierungen durch Unterklassenbildung erweiterbar sein sollen +* Wenn Änderungen in der Implementierung keine Auswirkungen auf Clients haben sollen + +[discrete] +== *Prompt-Beispiel*: +"Trenne die Rendering-Abstraktion von der plattformspezifischen Implementierung nach dem GoF-Bridge Pattern, damit beide unabhängig erweitert werden können." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-builder-pattern.de.adoc b/docs/anchors/gof-builder-pattern.de.adoc new file mode 100644 index 0000000..c5dc555 --- /dev/null +++ b/docs/anchors/gof-builder-pattern.de.adoc @@ -0,0 +1,29 @@ += GoF-Builder Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 1 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, creational, builder, construction, fluent interface, complex objects + +[%collapsible] +==== +Vollständiger Name:: GoF Builder Pattern (Creational) + +[discrete] +== *Absicht*: +Trenne die Konstruktion eines komplexen Objekts von seiner Repräsentation, sodass derselbe Konstruktionsprozess verschiedene Repräsentationen erzeugen kann. + +[discrete] +== *Wann zu verwenden*: +* Wenn der Algorithmus zur Erzeugung eines komplexen Objekts unabhängig von den Teilen und ihrer Zusammensetzung sein soll +* Wenn der Konstruktionsprozess verschiedene Repräsentationen ermöglichen muss + +[discrete] +== *Prompt-Beispiel*: +"Implementiere einen Builder nach GoF für das QueryObject, mit Fluent API für Filter, Sortierung und Pagination." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-chain-of-responsibility-pattern.de.adoc b/docs/anchors/gof-chain-of-responsibility-pattern.de.adoc new file mode 100644 index 0000000..93b4e25 --- /dev/null +++ b/docs/anchors/gof-chain-of-responsibility-pattern.de.adoc @@ -0,0 +1,30 @@ += GoF-Chain of Responsibility Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 2 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, behavioral, chain of responsibility, handler, pipeline, middleware + +[%collapsible] +==== +Vollständiger Name:: GoF Chain of Responsibility Pattern (Behavioral) + +[discrete] +== *Absicht*: +Vermeide die Kopplung des Senders einer Anfrage an seinen Empfänger, indem mehr als ein Objekt die Möglichkeit erhält, die Anfrage zu bearbeiten. Verkette die empfangenden Objekte und leite die Anfrage entlang der Kette weiter. + +[discrete] +== *Wann zu verwenden*: +* Wenn mehr als ein Objekt eine Anfrage bearbeiten kann und der Handler nicht im Voraus bekannt ist +* Wenn du eine Anfrage an eines von mehreren Objekten senden möchtest, ohne den Empfänger explizit anzugeben +* Wenn die Menge der Objekte, die eine Anfrage bearbeiten können, dynamisch festgelegt werden soll + +[discrete] +== *Prompt-Beispiel*: +"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." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-command-pattern.de.adoc b/docs/anchors/gof-command-pattern.de.adoc new file mode 100644 index 0000000..5681ab4 --- /dev/null +++ b/docs/anchors/gof-command-pattern.de.adoc @@ -0,0 +1,30 @@ += GoF-Command Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 1 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, behavioral, command, undo, queue, encapsulation, action + +[%collapsible] +==== +Vollständiger Name:: GoF Command Pattern (Behavioral) + +[discrete] +== *Absicht*: +Kapsle eine Anfrage als Objekt, sodass du Clients mit verschiedenen Anfragen parametrisieren, Anfragen in Warteschlangen stellen oder protokollieren und rückgängig machbare Operationen unterstützen kannst. + +[discrete] +== *Wann zu verwenden*: +* Wenn du Objekte mit einer auszuführenden Aktion parametrisieren möchtest +* Wenn du Undo/Redo-Funktionalität benötigst +* Wenn du Anfragen in Warteschlangen stellen, protokollieren oder zeitlich planen musst + +[discrete] +== *Prompt-Beispiel*: +"Implementiere ein Undo/Redo-System nach dem GoF-Command Pattern, bei dem jede Benutzeraktion als Command-Objekt gekapselt wird." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-composite-pattern.de.adoc b/docs/anchors/gof-composite-pattern.de.adoc new file mode 100644 index 0000000..7fd69ac --- /dev/null +++ b/docs/anchors/gof-composite-pattern.de.adoc @@ -0,0 +1,29 @@ += GoF-Composite Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 2 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, structural, composite, tree, hierarchy, part-whole + +[%collapsible] +==== +Vollständiger Name:: GoF Composite Pattern (Structural) + +[discrete] +== *Absicht*: +Setze Objekte zu Baumstrukturen zusammen, um Teil-Ganzes-Hierarchien darzustellen. Composite ermöglicht es Clients, einzelne Objekte und Kompositionen einheitlich zu behandeln. + +[discrete] +== *Wann zu verwenden*: +* Wenn du Teil-Ganzes-Hierarchien von Objekten darstellen möchtest +* Wenn Clients den Unterschied zwischen Kompositionen von Objekten und einzelnen Objekten ignorieren können sollen + +[discrete] +== *Prompt-Beispiel*: +"Modelliere das Dateisystem nach dem GoF-Composite Pattern, sodass Dateien und Ordner einheitlich behandelt werden können." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-decorator-pattern.de.adoc b/docs/anchors/gof-decorator-pattern.de.adoc new file mode 100644 index 0000000..2fddd42 --- /dev/null +++ b/docs/anchors/gof-decorator-pattern.de.adoc @@ -0,0 +1,31 @@ += GoF-Decorator Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 1 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, structural, decorator, wrapper, dynamic behavior, composition + +[%collapsible] +==== +Vollständiger Name:: GoF Decorator Pattern (Structural) + +Auch bekannt als:: Wrapper + +[discrete] +== *Absicht*: +Füge einem Objekt dynamisch zusätzliche Verantwortlichkeiten hinzu. Decorators bieten eine flexible Alternative zur Unterklassenbildung. + +[discrete] +== *Wann zu verwenden*: +* Um Objekten dynamisch und transparent Verantwortlichkeiten hinzuzufügen +* Wenn Erweiterung durch Unterklassenbildung unpraktisch ist + +[discrete] +== *Prompt-Beispiel*: +"Verwende das GoF-Decorator Pattern, um dem Logger dynamisch Formatierung, Timestamp und Filterung hinzuzufügen." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-design-patterns.de.adoc b/docs/anchors/gof-design-patterns.de.adoc new file mode 100644 index 0000000..f344156 --- /dev/null +++ b/docs/anchors/gof-design-patterns.de.adoc @@ -0,0 +1,49 @@ += GoF Design Patterns +:categories: design-principles +:roles: software-developer, software-architect, educator +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:related: solid-principles, fowler-patterns, clean-architecture +:tags: design-patterns, gang-of-four, oop, creational, structural, behavioral +: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 + +[%collapsible] +==== +Vollständiger Name:: Gang of Four Design Patterns + +Auch bekannt als:: Design Patterns, Gang of Four Patterns + +[discrete] +== *Kernkonzepte*: + +Erzeugungsmuster:: Abstract Factory, Builder, Factory Method, Prototype, Singleton — Mechanismen zur Objekterzeugung + +Strukturmuster:: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy — Objektkomposition und Beziehungen + +Verhaltensmuster:: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor — Objektinteraktion und Verantwortlichkeiten + +Pattern-Sprache:: Gemeinsames Vokabular zur Kommunikation wiederkehrender Entwurfsprobleme und bewährter Lösungen + +Komposition vor Vererbung:: Objektkomposition für Flexibilität gegenüber starren Klassenhierarchien bevorzugen + +Gegen ein Interface programmieren:: Von Abstraktionen abhängen statt von konkreten Implementierungen + +Für Veränderung entwerfen:: Identifiziere, was sich in deinem Entwurf ändert, und kapsle es + + +Schlüsselvertreter:: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides ("Design Patterns: Elements of Reusable Object-Oriented Software", 1994) + +[discrete] +== *Wann zu verwenden*: + +* Objektorientierter Entwurf, der bewährte Lösungen für wiederkehrende Probleme erfordert +* Kommunikation von Entwurfsentscheidungen mit einem gemeinsamen Vokabular +* Vermittlung objektorientierter Entwurfsprinzipien anhand konkreter Beispiele +* Refactoring von Code zur Erhöhung von Flexibilität und Wiederverwendbarkeit + +[discrete] +== *Verwandte Anker*: + +* <> - Entwurfsprinzipien, deren Umsetzung GoF-Patterns unterstützen +* <> - Architekturmuster für Unternehmensanwendungen (komplementärer Umfang) +* <> - Architekturstil, der GoF-Prinzipien nutzt +==== diff --git a/docs/anchors/gof-facade-pattern.de.adoc b/docs/anchors/gof-facade-pattern.de.adoc new file mode 100644 index 0000000..e7ea185 --- /dev/null +++ b/docs/anchors/gof-facade-pattern.de.adoc @@ -0,0 +1,29 @@ += GoF-Facade Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 1 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, structural, facade, simplification, subsystem, unified interface + +[%collapsible] +==== +Vollständiger Name:: GoF Facade Pattern (Structural) + +[discrete] +== *Absicht*: +Biete ein einheitliches Interface zu einer Menge von Interfaces in einem Subsystem. Facade definiert ein höheres Interface, das die Nutzung des Subsystems vereinfacht. + +[discrete] +== *Wann zu verwenden*: +* Wenn du ein einfaches Interface zu einem komplexen Subsystem bereitstellen möchtest +* Wenn es viele Abhängigkeiten zwischen Clients und Implementierungsklassen gibt + +[discrete] +== *Prompt-Beispiel*: +"Erstelle eine Facade nach GoF für das Payment-Subsystem, die Validierung, Autorisierung und Abrechnung hinter einem einfachen Interface kapselt." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-factory-method-pattern.de.adoc b/docs/anchors/gof-factory-method-pattern.de.adoc new file mode 100644 index 0000000..7fdeba6 --- /dev/null +++ b/docs/anchors/gof-factory-method-pattern.de.adoc @@ -0,0 +1,31 @@ += GoF-Factory Method Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 1 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, creational, factory, polymorphism, instantiation + +[%collapsible] +==== +Vollständiger Name:: GoF Factory Method Pattern (Creational) + +Auch bekannt als:: Virtual Constructor + +[discrete] +== *Absicht*: +Definiere ein Interface zur Erzeugung eines Objekts, aber lasse Unterklassen entscheiden, welche Klasse instanziiert wird. + +[discrete] +== *Wann zu verwenden*: +* Wenn eine Klasse die Klasse der zu erzeugenden Objekte nicht voraussehen kann +* Wenn eine Klasse möchte, dass ihre Unterklassen die zu erzeugenden Objekte spezifizieren + +[discrete] +== *Prompt-Beispiel*: +"Extrahiere die Objekterzeugung in eine Factory Method nach GoF, damit neue Typen ohne Änderung des bestehenden Codes hinzugefügt werden können." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-flyweight-pattern.de.adoc b/docs/anchors/gof-flyweight-pattern.de.adoc new file mode 100644 index 0000000..8adb3e7 --- /dev/null +++ b/docs/anchors/gof-flyweight-pattern.de.adoc @@ -0,0 +1,16 @@ += GoF-Flyweight Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 3 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, structural, flyweight, memory optimization, sharing + +[%collapsible] +==== +Vollständiger Name:: GoF Flyweight Pattern (Structural) + +[discrete] +== *Absicht*: +Nutze gemeinsame Verwendung, um große Mengen feingranularer Objekte effizient zu unterstützen. +==== diff --git a/docs/anchors/gof-interpreter-pattern.de.adoc b/docs/anchors/gof-interpreter-pattern.de.adoc new file mode 100644 index 0000000..47a6ff5 --- /dev/null +++ b/docs/anchors/gof-interpreter-pattern.de.adoc @@ -0,0 +1,16 @@ += GoF-Interpreter Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 3 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, behavioral, interpreter, grammar, DSL, parsing + +[%collapsible] +==== +Vollständiger Name:: GoF Interpreter Pattern (Behavioral) + +[discrete] +== *Absicht*: +Definiere für eine gegebene Sprache eine Repräsentation ihrer Grammatik zusammen mit einem Interpreter, der diese Repräsentation nutzt, um Sätze in der Sprache zu interpretieren. +==== diff --git a/docs/anchors/gof-iterator-pattern.de.adoc b/docs/anchors/gof-iterator-pattern.de.adoc new file mode 100644 index 0000000..25fa71a --- /dev/null +++ b/docs/anchors/gof-iterator-pattern.de.adoc @@ -0,0 +1,30 @@ += GoF-Iterator Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 2 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, behavioral, iterator, traversal, collection, aggregate + +[%collapsible] +==== +Vollständiger Name:: GoF Iterator Pattern (Behavioral) + +[discrete] +== *Absicht*: +Biete eine Möglichkeit, sequenziell auf die Elemente eines Aggregatobjekts zuzugreifen, ohne dessen zugrunde liegende Repräsentation offenzulegen. + +[discrete] +== *Wann zu verwenden*: +* Wenn du auf den Inhalt eines Aggregatobjekts zugreifen musst, ohne dessen interne Repräsentation offenzulegen +* Wenn du mehrere Traversierungen von Aggregatobjekten unterstützen möchtest +* Wenn du ein einheitliches Interface zur Traversierung verschiedener Aggregatstrukturen bereitstellen möchtest + +[discrete] +== *Prompt-Beispiel*: +"Implementiere einen Iterator nach GoF für die benutzerdefinierte Baumstruktur, der verschiedene Traversierungsstrategien (Tiefe, Breite) unterstützt." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-mediator-pattern.de.adoc b/docs/anchors/gof-mediator-pattern.de.adoc new file mode 100644 index 0000000..c0bd4d4 --- /dev/null +++ b/docs/anchors/gof-mediator-pattern.de.adoc @@ -0,0 +1,30 @@ += GoF-Mediator Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 2 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, behavioral, mediator, loose coupling, coordination, hub + +[%collapsible] +==== +Vollständiger Name:: GoF Mediator Pattern (Behavioral) + +[discrete] +== *Absicht*: +Definiere ein Objekt, das kapselt, wie eine Menge von Objekten interagiert. Mediator fördert lose Kopplung, indem Objekte sich nicht explizit aufeinander beziehen. + +[discrete] +== *Wann zu verwenden*: +* Wenn eine Menge von Objekten auf wohldefinierte, aber komplexe Weise kommuniziert +* Wenn die Wiederverwendung eines Objekts schwierig ist, weil es auf viele andere Objekte verweist und mit ihnen kommuniziert +* Wenn Verhalten, das auf mehrere Klassen verteilt ist, ohne übermäßige Unterklassenbildung anpassbar sein soll + +[discrete] +== *Prompt-Beispiel*: +"Führe einen Mediator nach GoF ein, der die Kommunikation zwischen den UI-Komponenten (Formular, Liste, Filter) zentral koordiniert und die direkte Kopplung beseitigt." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-memento-pattern.de.adoc b/docs/anchors/gof-memento-pattern.de.adoc new file mode 100644 index 0000000..6312b9b --- /dev/null +++ b/docs/anchors/gof-memento-pattern.de.adoc @@ -0,0 +1,16 @@ += GoF-Memento Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 3 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, behavioral, memento, snapshot, undo, state preservation + +[%collapsible] +==== +Vollständiger Name:: GoF Memento Pattern (Behavioral) + +[discrete] +== *Absicht*: +Erfasse und externalisiere den internen Zustand eines Objekts, ohne die Kapselung zu verletzen, sodass das Objekt später in diesen Zustand zurückversetzt werden kann. +==== diff --git a/docs/anchors/gof-observer-pattern.de.adoc b/docs/anchors/gof-observer-pattern.de.adoc new file mode 100644 index 0000000..05723ae --- /dev/null +++ b/docs/anchors/gof-observer-pattern.de.adoc @@ -0,0 +1,31 @@ += GoF-Observer Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 1 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, behavioral, observer, publish-subscribe, event, notification, reactive + +[%collapsible] +==== +Vollständiger Name:: GoF Observer Pattern (Behavioral) + +Auch bekannt als:: Publish-Subscribe, Event-Listener + +[discrete] +== *Absicht*: +Definiere eine Eins-zu-viele-Abhängigkeit zwischen Objekten, sodass bei Zustandsänderung eines Objekts alle abhängigen Objekte automatisch benachrichtigt und aktualisiert werden. + +[discrete] +== *Wann zu verwenden*: +* Wenn Änderungen an einem Objekt Änderungen an anderen erfordern und du nicht weißt, wie viele Objekte sich ändern müssen +* Wenn ein Objekt andere benachrichtigen soll, ohne zu wissen, wer sie sind + +[discrete] +== *Prompt-Beispiel*: +"Implementiere ein Event-System nach dem GoF-Observer Pattern, damit Änderungen am Datenmodell automatisch die UI aktualisieren." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-prototype-pattern.de.adoc b/docs/anchors/gof-prototype-pattern.de.adoc new file mode 100644 index 0000000..a6c8982 --- /dev/null +++ b/docs/anchors/gof-prototype-pattern.de.adoc @@ -0,0 +1,30 @@ += GoF-Prototype Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 2 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, creational, prototype, cloning, copy, object creation + +[%collapsible] +==== +Vollständiger Name:: GoF Prototype Pattern (Creational) + +[discrete] +== *Absicht*: +Bestimme die Arten der zu erzeugenden Objekte anhand einer prototypischen Instanz und erstelle neue Objekte durch Kopieren dieses Prototypen. + +[discrete] +== *Wann zu verwenden*: +* Wenn ein System unabhängig davon sein soll, wie seine Produkte erzeugt und dargestellt werden +* Wenn die zu instanziierenden Klassen zur Laufzeit spezifiziert werden +* Wenn du den Aufbau einer Fabrik-Klassenhierarchie vermeiden möchtest, die die Produkt-Klassenhierarchie widerspiegelt + +[discrete] +== *Prompt-Beispiel*: +"Verwende das GoF-Prototype Pattern, um neue Konfigurationsobjekte durch Klonen eines Prototypen zu erzeugen, statt sie jedes Mal von Grund auf zu konstruieren." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-proxy-pattern.de.adoc b/docs/anchors/gof-proxy-pattern.de.adoc new file mode 100644 index 0000000..87f0663 --- /dev/null +++ b/docs/anchors/gof-proxy-pattern.de.adoc @@ -0,0 +1,28 @@ += GoF-Proxy Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 1 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, structural, proxy, access control, lazy loading, caching, virtual proxy + +[%collapsible] +==== +Vollständiger Name:: GoF Proxy Pattern (Structural) + +[discrete] +== *Absicht*: +Stelle einen Stellvertreter oder Platzhalter für ein anderes Objekt bereit, um den Zugriff darauf zu kontrollieren. + +[discrete] +== *Wann zu verwenden*: +* Wenn du eine vielseitigere oder ausgefeiltere Referenz auf ein Objekt benötigst als einen einfachen Zeiger (Remote-, Virtual-, Protection- oder Smart-Reference-Proxy) + +[discrete] +== *Prompt-Beispiel*: +"Implementiere einen Caching-Proxy nach GoF für den API-Client, der wiederholte Anfragen aus dem Cache beantwortet." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-singleton-pattern.de.adoc b/docs/anchors/gof-singleton-pattern.de.adoc new file mode 100644 index 0000000..e8e096e --- /dev/null +++ b/docs/anchors/gof-singleton-pattern.de.adoc @@ -0,0 +1,29 @@ += GoF-Singleton Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 1 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, creational, singleton, global state, instance control + +[%collapsible] +==== +Vollständiger Name:: GoF Singleton Pattern (Creational) + +[discrete] +== *Absicht*: +Stelle sicher, dass eine Klasse nur eine Instanz hat, und biete einen globalen Zugriffspunkt darauf. + +[discrete] +== *Wann zu verwenden*: +* Wenn es genau eine Instanz einer Klasse geben muss +* Wenn die einzige Instanz durch Unterklassenbildung erweiterbar sein soll + +[discrete] +== *Prompt-Beispiel*: +"Stelle sicher, dass der ConfigManager als GoF-Singleton implementiert ist, mit thread-sicherem Lazy Loading." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-state-pattern.de.adoc b/docs/anchors/gof-state-pattern.de.adoc new file mode 100644 index 0000000..7eb8394 --- /dev/null +++ b/docs/anchors/gof-state-pattern.de.adoc @@ -0,0 +1,31 @@ += GoF-State Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 1 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, behavioral, state, state machine, finite automaton, context + +[%collapsible] +==== +Vollständiger Name:: GoF State Pattern (Behavioral) + +Auch bekannt als:: Objects for States + +[discrete] +== *Absicht*: +Ermögliche einem Objekt, sein Verhalten zu ändern, wenn sich sein interner Zustand ändert. Das Objekt scheint seine Klasse zu wechseln. + +[discrete] +== *Wann zu verwenden*: +* Wenn das Verhalten eines Objekts von seinem Zustand abhängt und sich zur Laufzeit ändern muss +* Wenn Operationen große bedingte Anweisungen enthalten, die vom Zustand des Objekts abhängen + +[discrete] +== *Prompt-Beispiel*: +"Ersetze die verschachtelten if/switch-Statements durch das GoF-State Pattern, sodass jeder Zustand sein eigenes Verhalten kapselt." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-strategy-pattern.de.adoc b/docs/anchors/gof-strategy-pattern.de.adoc new file mode 100644 index 0000000..5035e04 --- /dev/null +++ b/docs/anchors/gof-strategy-pattern.de.adoc @@ -0,0 +1,30 @@ += GoF-Strategy Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 1 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, behavioral, strategy + +[%collapsible] +==== +Vollständiger Name:: GoF Strategy Pattern (Behavioral) + +[discrete] +== *Absicht*: +Definiere eine Familie von Algorithmen, kapsle jeden einzelnen und mache sie austauschbar. Strategy ermöglicht es, den Algorithmus unabhängig von den Clients zu variieren, die ihn verwenden. + +[discrete] +== *Wann zu verwenden*: +* Mehrere verwandte Klassen unterscheiden sich nur im Verhalten +* Du brauchst verschiedene Varianten eines Algorithmus +* Ein Algorithmus verwendet Daten, die Clients nicht kennen sollten + +[discrete] +== *Prompt-Beispiel*: +"Refactore diese Klasse nach dem GoF-Strategy Pattern, um die verschiedenen Berechnungsarten austauschbar zu machen." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-template-method-pattern.de.adoc b/docs/anchors/gof-template-method-pattern.de.adoc new file mode 100644 index 0000000..2c0e53b --- /dev/null +++ b/docs/anchors/gof-template-method-pattern.de.adoc @@ -0,0 +1,29 @@ += GoF-Template Method Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 1 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, behavioral, template method, algorithm skeleton, hook, inheritance + +[%collapsible] +==== +Vollständiger Name:: GoF Template Method Pattern (Behavioral) + +[discrete] +== *Absicht*: +Definiere das Skelett eines Algorithmus in einer Operation und delegiere einige Schritte an Unterklassen. + +[discrete] +== *Wann zu verwenden*: +* Wenn du die unveränderlichen Teile eines Algorithmus einmal implementieren und es den Unterklassen überlassen möchtest, das variierende Verhalten zu implementieren +* Wenn gemeinsames Verhalten unter Unterklassen in einer gemeinsamen Klasse zusammengefasst und lokalisiert werden soll + +[discrete] +== *Prompt-Beispiel*: +"Refactore die Report-Generierung nach dem GoF-Template Method Pattern. Der Algorithmus (Daten laden, transformieren, formatieren) bleibt fix, aber die einzelnen Schritte sind austauschbar." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/gof-visitor-pattern.de.adoc b/docs/anchors/gof-visitor-pattern.de.adoc new file mode 100644 index 0000000..ba152c3 --- /dev/null +++ b/docs/anchors/gof-visitor-pattern.de.adoc @@ -0,0 +1,16 @@ += GoF-Visitor Pattern +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: gof-design-patterns +:tier: 3 +:proponents: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides +:tags: GoF, design pattern, behavioral, visitor, double dispatch, operations, traversal + +[%collapsible] +==== +Vollständiger Name:: GoF Visitor Pattern (Behavioral) + +[discrete] +== *Absicht*: +Repräsentiere eine Operation, die auf den Elementen einer Objektstruktur ausgeführt werden soll. Visitor ermöglicht es, eine neue Operation zu definieren, ohne die Klassen der Elemente zu ändern, auf denen sie operiert. +==== diff --git a/docs/anchors/iec-61508-sil-levels.de.adoc b/docs/anchors/iec-61508-sil-levels.de.adoc new file mode 100644 index 0000000..39e312e --- /dev/null +++ b/docs/anchors/iec-61508-sil-levels.de.adoc @@ -0,0 +1,63 @@ += IEC 61508 SIL Levels +:categories: testing-quality +:roles: software-developer, software-architect, qa-engineer, devops-engineer, consultant +:proponents: International Electrotechnical Commission (IEC) +:related: testing-pyramid, mutation-testing +:tags: safety, functional-safety, SIL, standards, certification, risk-assessment + +[%collapsible] +==== +Vollständiger Name:: IEC 61508 Safety Integrity Levels + +Auch bekannt als:: Funktionale Sicherheitsstufen, SIL-Klassifikation + +[discrete] +== *Kernkonzepte*: + +Vier Safety Integrity Levels:: ++ +SIL 1 (niedrigste)::: 10^-2^ ≤ PFD < 10^-1^ (tolerierbare Risikominderung) +SIL 2::: 10^-3^ ≤ PFD < 10^-2^ (moderate Risikominderung) +SIL 3::: 10^-4^ ≤ PFD < 10^-3^ (erhebliche Risikominderung) +SIL 4 (höchste)::: 10^-5^ ≤ PFD < 10^-4^ (maximale Risikominderung) + +Risikobasierte Klassifikation:: SIL-Stufe wird durch Gefährdungsanalyse und Risikobewertung bestimmt + +Sicherheitslebenszyklus:: Systematischer Ansatz vom Konzept bis zur Stilllegung + +Hardwareanforderungen:: Architektonische Einschränkungen und systematische Fähigkeit + +Softwareanforderungen:: Entwicklungsmethoden, Verifikations- und Validierungstechniken + +Probability of Failure on Demand (PFD):: Schlüsselmetrik für die Zuverlässigkeit von Sicherheitsfunktionen + +Sicherheitsinstrumentierte Systeme (SIS):: Schutzebenen, die Sicherheitsfunktionen implementieren + +Verifikation und Validierung:: Unabhängige Bewertung von Sicherheitsaussagen + +Systematische Ausfälle:: Fokus auf Vermeidung von Design- und Spezifikationsfehlern + +Zufällige Hardwareausfälle:: Statistische Analyse und Fehlertoleranz + + +Schlüsselstandard:: IEC 61508 "Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme" (erste Ausgabe 1998, zweite Ausgabe 2010) + +[discrete] +== *Verwandte Standards*: + +* IEC 61511 (Prozessindustrie) +* ISO 26262 (Automobil) +* EN 50128 (Eisenbahn) +* IEC 62304 (Medizinprodukte) + +[discrete] +== *Wann zu verwenden*: + +* Entwicklung sicherheitskritischer eingebetteter Systeme +* Risikobewertung in industrieller Automatisierung und Steuerungssystemen +* Zertifizierung sicherheitsinstrumentierter Systeme +* Entwurf von Fail-Safe-Mechanismen und Redundanz +* Etablierung von Softwareentwicklungsprozessen für Sicherheitsanwendungen +* Durchführung von HAZOP-Studien (Hazard and Operability) +* Implementierung funktionaler Sicherheitsmanagementsysteme +==== diff --git a/docs/anchors/morphological-box.de.adoc b/docs/anchors/morphological-box.de.adoc new file mode 100644 index 0000000..191a8c4 --- /dev/null +++ b/docs/anchors/morphological-box.de.adoc @@ -0,0 +1,86 @@ += Morphological Box +:categories: problem-solving +:roles: software-architect, product-owner, consultant, software-developer +:related: mece, pugh-matrix +:proponents: Fritz Zwicky +:tags: innovation, creativity, problem-solving, systematic-design, combinatorial-analysis + +[%collapsible] +==== +Vollständiger Name:: Morphologische Analyse / Morphologischer Kasten + +[discrete] +== *Kernkonzepte*: + +Mehrdimensionale Zerlegung:: Komplexes Problem in unabhängige Parameter/Dimensionen zerlegen + +Variantenaufzählung:: Mögliche Werte/Optionen für jeden Parameter identifizieren + +Matrixkonstruktion:: Parameter und Varianten in Tabellen-/Kastenform organisieren + +Kombinatorische Exploration:: Kombinationen von Varianten systematisch untersuchen + +Constraint-Filterung:: Nicht realisierbare oder widersprüchliche Kombinationen eliminieren + +Entdeckung neuartiger Lösungen:: Nicht offensichtliche Lösungen durch systematische Rekombination finden + +Vollständiger Lösungsraum:: Sicherstellen, dass alle Möglichkeiten berücksichtigt werden + +Strukturierte Kreativität:: Systematischer Ansatz für Innovation und Ideenfindung + + +Schlüsselvertreter:: Fritz Zwicky (1940er-1960er, California Institute of Technology) + +Historischer Kontext:: Entwickelt für Probleme der Luft- und Raumfahrttechnik (Strahltriebwerke, Raumfahrtantriebe), heute weit verbreitet in Produktentwicklung, Systementwurf und Innovationsmanagement. + +[discrete] +== *Wann zu verwenden*: + +* Erkundung von Designalternativen für komplexe Systeme +* Analyse von Produktfunktionskombinationen +* Technologieauswahl mit mehreren Dimensionen +* Architekturentscheidungen mit unabhängigen Parametern +* Innovationsworkshops und Ideenfindungssitzungen +* Requirements Engineering für Produktvarianten +* Lösungsraumkartierung vor der Bewertung + +[discrete] +== *Beispielanwendung*: + +---- +Problem: Entwurf eines Entwickler-Dokumentationssystems +Parameter: +├─ Format: Markdown, AsciiDoc, reStructuredText, API-first +├─ Hosting: GitHub Pages, Netlify, Read the Docs, S3+CloudFront +├─ Generator: Statisch (Hugo, Jekyll), Dynamisch (Docusaurus), Custom +└─ Versionierung: Git-basiert, Versionsauswahl, Branch-per-Version + +Matrix erzeugt 4 × 4 × 3 × 3 = 144 mögliche Kombinationen +Filterung nach Constraints (z.B. "AsciiDoc + Hugo schlecht unterstützt") +→ Identifikation von ~20 realisierbaren Lösungen zur Bewertung mit Pugh-Matrix +---- + +[discrete] +== *Verwandte Konzepte*: + +* MECE-Prinzip (für Parameterunabhängigkeit) +* Pugh-Matrix (zur Bewertung generierter Alternativen) +* Design of Experiments (DOE) +* Kombinatorisches Design +* Lösungsraum-Exploration + +[discrete] +== *Ergänzende Werkzeuge*: + +* *Morphological Box* verwenden, um Alternativen zu generieren +* Dann *Pugh-Matrix* anwenden, um die beste Option zu bewerten und auszuwählen +* *MECE* verwenden, um Parameterunabhängigkeit sicherzustellen + +[discrete] +== *Zu vermeidende Fallstricke*: + +* Parameter, die nicht unabhängig sind (verletzt kombinatorische Logik) +* Zu viele Parameter, die zu kombinatorischer Explosion führen +* Aufhören bei der Matrixerstellung, ohne Kombinationen zu erkunden +* Vergessen, nicht realisierbare Kombinationen herauszufiltern +==== diff --git a/docs/anchors/myers-briggs-type-indicator.de.adoc b/docs/anchors/myers-briggs-type-indicator.de.adoc new file mode 100644 index 0000000..b0a06a5 --- /dev/null +++ b/docs/anchors/myers-briggs-type-indicator.de.adoc @@ -0,0 +1,59 @@ += Myers-Briggs Type Indicator (MBTI) +:categories: communication-presentation +:roles: team-lead, consultant, educator, ux-designer, product-owner +:proponents: Isabel Briggs Myers, Katharine Cook Briggs, Carl Gustav Jung +:tags: personality types, MBTI, psychological types, communication styles, team dynamics, Jungian psychology + +[%collapsible] +==== +Vollständiger Name:: Myers-Briggs Type Indicator (MBTI) + +Auch bekannt als:: MBTI, Myers-Briggs, Angewandte Jungsche Typentheorie, 16 Persönlichkeitstypen + +[discrete] +== *Kernkonzepte*: + +Vier Dichotomien:: Das Framework definiert vier Präferenzdimensionen, jede mit zwei Polen: +* *Extraversion (E) vs. Introversion (I)* — Wohin richtest du deine Energie? Nach außen zu Menschen und Aktivität, oder nach innen zu Ideen und Reflexion? +* *Sensing (S) vs. Intuition (N)* — Wie nimmst du Informationen auf? Durch konkrete Fakten und gegenwärtige Realität, oder durch Muster und zukünftige Möglichkeiten? +* *Thinking (T) vs. Feeling (F)* — Wie triffst du Entscheidungen? Basierend auf Logik und objektiver Analyse, oder basierend auf Werten und zwischenmenschlicher Wirkung? +* *Judging (J) vs. Perceiving (P)* — Wie gehst du mit der Außenwelt um? Mit Struktur und Planung, oder mit Flexibilität und Spontaneität? + +16 Persönlichkeitstypen:: Die vier Dichotomien kombinieren sich zu 16 verschiedenen Typenprofilen (z.B. INTJ, ENFP, ISTJ, ESFP), jeweils mit charakteristischen Stärken, blinden Flecken und Kommunikationspräferenzen + +Kognitive Funktionen:: Jeder Typ hat einen Stapel von vier kognitiven Funktionen (z.B. dominante Introvertierte Intuition, auxiliäre Extravertierte Fühlen bei INFJs), die beschreiben, wie Informationen verarbeitet und Entscheidungen getroffen werden + +Präferenz, nicht Fähigkeit:: Der Typ beschreibt eine natürliche Präferenz, keine Fähigkeit oder feste Eigenschaft — Menschen können und nutzen alle Funktionen, bevorzugen aber einige gegenüber anderen + +Typdynamik:: Das Verständnis der Typenmischung eines Teams zeigt wahrscheinliche Reibungsquellen (z.B. S/N-Konflikte zwischen Gesamtbild und Detailfokus) und natürliche Kooperationsmuster + +Schlüsselvertreter:: Isabel Briggs Myers und Katharine Cook Briggs, aufbauend auf Carl Gustav Jungs Theorie der psychologischen Typen ("Psychologische Typen", 1921) + +Historischer Kontext:: Während des Zweiten Weltkriegs entwickelt, um Frauen beim Einstieg in die industrielle Arbeitswelt bei der Suche nach zu ihrer Persönlichkeit passenden Rollen zu helfen; 1962 offiziell als Instrument veröffentlicht und in organisatorischen und pädagogischen Umgebungen weit verbreitet + +[discrete] +== *Wann zu verwenden*: + +* Verständnis von Kommunikationspräferenzen und potenziellen Reibungsquellen innerhalb eines Teams +* Moderation von Team-Retrospektiven oder Kickoffs, bei denen zwischenmenschliche Dynamiken wichtig sind +* Coaching von Einzelpersonen zu Führungs- und Kommunikationsstil +* Karriereentwicklungsgespräche zur Abstimmung von Rollenerwartungen mit persönlichem Arbeitsstil +* UX-Forschung, um zu berücksichtigen, wie verschiedene Nutzertypen mit einem Produkt interagieren könnten +* Onboarding-Programme zur Beschleunigung des gegenseitigen Verständnisses unter neuen Teammitgliedern + +[discrete] +== *Häufige Missverständnisse*: + +* "Mein Typ bedeutet, dass ich X nicht kann" — MBTI beschreibt Präferenzen, nicht Fähigkeiten oder Grenzen +* "Typen sind lebenslang festgelegt" — Präferenzen können sich mit Erfahrung, Stress oder Kontext verschieben +* "Ein Typ ist besser als ein anderer" — Alle 16 Typen bringen Wert; das Framework ist beschreibend, nicht bewertend +* "MBTI ist ein Ausgangspunkt für Selbstreflexion und Dialog" — Korrekte Nutzung ist explorativ, nicht diagnostisch + +[discrete] +== *Einschränkungen und Kritik*: + +* Die Test-Retest-Reliabilität ist mäßig — dieselbe Person kann bei erneuter Durchführung einen anderen Typ erhalten +* Binäre Dichotomien vereinfachen kontinuierliche Merkmalsverteilungen zu stark +* Nicht empfohlen für Einstellungsentscheidungen oder Personalauswahl mit hohem Einsatz +* Kritisiert wegen geringer prädiktiver Validität für Arbeitsleistung im Vergleich zu z.B. Big-Five-Persönlichkeitsmerkmalen +==== diff --git a/docs/anchors/solid-dip.adoc b/docs/anchors/solid-dip.adoc new file mode 100644 index 0000000..1cace79 --- /dev/null +++ b/docs/anchors/solid-dip.adoc @@ -0,0 +1,31 @@ += SOLID-Dependency Inversion Principle +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: solid-principles +:tier: 1 +:proponents: Robert C. Martin +:tags: SOLID, design principle, DIP, dependency inversion + +[%collapsible] +==== +Full Name:: SOLID Dependency Inversion Principle (DIP) + +[discrete] +== *Intent*: +High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. + +[discrete] +== *When to Use*: +* High-level business logic directly instantiates infrastructure classes +* Changing a database or framework requires modifying business logic +* Unit testing requires running actual external services + +[discrete] +== *Prompt Example*: +"Refactore diese Klasse nach dem SOLID-Dependency Inversion Principle, sodass die Abhängigkeiten über Interfaces injiziert werden." + +[discrete] +== *Related Anchors*: +* <> (Umbrella) +* <> - Architectural application of DIP +==== diff --git a/docs/anchors/solid-dip.de.adoc b/docs/anchors/solid-dip.de.adoc new file mode 100644 index 0000000..38ae47e --- /dev/null +++ b/docs/anchors/solid-dip.de.adoc @@ -0,0 +1,31 @@ += SOLID-Dependency Inversion Principle +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: solid-principles +:tier: 1 +:proponents: Robert C. Martin +:tags: SOLID, design principle, DIP, dependency inversion + +[%collapsible] +==== +Vollständiger Name:: SOLID Dependency Inversion Principle (DIP) + +[discrete] +== *Absicht*: +High-Level-Module sollten nicht von Low-Level-Modulen abhängen. Beide sollten von Abstraktionen abhängen. Abstraktionen sollten nicht von Details abhängen; Details sollten von Abstraktionen abhängen. + +[discrete] +== *Wann zu verwenden*: +* High-Level-Geschäftslogik instanziiert direkt Infrastrukturklassen +* Das Wechseln einer Datenbank oder eines Frameworks erfordert Änderungen an der Geschäftslogik +* Unit-Tests erfordern das Ausführen tatsächlicher externer Dienste + +[discrete] +== *Prompt-Beispiel*: +"Refactore diese Klasse nach dem SOLID-Dependency Inversion Principle, sodass die Abhängigkeiten über Interfaces injiziert werden." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +* <> - Architektonische Anwendung von DIP +==== diff --git a/docs/anchors/solid-isp.adoc b/docs/anchors/solid-isp.adoc new file mode 100644 index 0000000..62fac8f --- /dev/null +++ b/docs/anchors/solid-isp.adoc @@ -0,0 +1,30 @@ += SOLID-Interface Segregation Principle +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: solid-principles +:tier: 1 +:proponents: Robert C. Martin +:tags: SOLID, design principle, ISP, interface segregation + +[%collapsible] +==== +Full Name:: SOLID Interface Segregation Principle (ISP) + +[discrete] +== *Intent*: +Clients should not be forced to depend on interfaces they do not use. Prefer many specific interfaces over one general-purpose interface. + +[discrete] +== *When to Use*: +* Classes implement interface methods they don't need (empty or throwing) +* Changes to an interface affect clients that don't use the changed methods +* Fat interfaces with many methods serving different client groups + +[discrete] +== *Prompt Example*: +"Refactore dieses Interface nach dem SOLID-Interface Segregation Principle in kleinere, clientspezifische Interfaces." + +[discrete] +== *Related Anchors*: +* <> (Umbrella) +==== diff --git a/docs/anchors/solid-isp.de.adoc b/docs/anchors/solid-isp.de.adoc new file mode 100644 index 0000000..10123b6 --- /dev/null +++ b/docs/anchors/solid-isp.de.adoc @@ -0,0 +1,30 @@ += SOLID-Interface Segregation Principle +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: solid-principles +:tier: 1 +:proponents: Robert C. Martin +:tags: SOLID, design principle, ISP, interface segregation + +[%collapsible] +==== +Vollständiger Name:: SOLID Interface Segregation Principle (ISP) + +[discrete] +== *Absicht*: +Clients sollten nicht gezwungen werden, von Schnittstellen abzuhängen, die sie nicht nutzen. Bevorzuge viele spezifische Schnittstellen gegenüber einer allgemeinen Universalschnittstelle. + +[discrete] +== *Wann zu verwenden*: +* Klassen implementieren Interface-Methoden, die sie nicht benötigen (leer oder mit Exception) +* Änderungen an einem Interface betreffen Clients, die die geänderten Methoden nicht nutzen +* Aufgeblähte Interfaces mit vielen Methoden für unterschiedliche Client-Gruppen + +[discrete] +== *Prompt-Beispiel*: +"Refactore dieses Interface nach dem SOLID-Interface Segregation Principle in kleinere, clientspezifische Interfaces." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/solid-lsp.adoc b/docs/anchors/solid-lsp.adoc new file mode 100644 index 0000000..4b16df0 --- /dev/null +++ b/docs/anchors/solid-lsp.adoc @@ -0,0 +1,30 @@ += SOLID-Liskov Substitution Principle +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: solid-principles +:tier: 1 +:proponents: Robert C. Martin, Barbara Liskov +:tags: SOLID, design principle, LSP, liskov, substitution + +[%collapsible] +==== +Full Name:: SOLID Liskov Substitution Principle (LSP) + +[discrete] +== *Intent*: +Subtypes must be substitutable for their base types without altering the correctness of the program. Derived classes must honor the contracts of their base classes. + +[discrete] +== *When to Use*: +* Subclass overrides break expected behavior of the base class +* instanceof/type checks appear in client code +* Inheritance hierarchies violate "is-a" relationships + +[discrete] +== *Prompt Example*: +"Überprüfe diese Vererbungshierarchie auf Verletzungen des SOLID-Liskov Substitution Principle." + +[discrete] +== *Related Anchors*: +* <> (Umbrella) +==== diff --git a/docs/anchors/solid-lsp.de.adoc b/docs/anchors/solid-lsp.de.adoc new file mode 100644 index 0000000..ac6ffe9 --- /dev/null +++ b/docs/anchors/solid-lsp.de.adoc @@ -0,0 +1,30 @@ += SOLID-Liskov Substitution Principle +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: solid-principles +:tier: 1 +:proponents: Robert C. Martin, Barbara Liskov +:tags: SOLID, design principle, LSP, liskov, substitution + +[%collapsible] +==== +Vollständiger Name:: SOLID Liskov Substitution Principle (LSP) + +[discrete] +== *Absicht*: +Subtypen müssen durch ihre Basistypen ersetzbar sein, ohne die Korrektheit des Programms zu verändern. Abgeleitete Klassen müssen die Verträge ihrer Basisklassen einhalten. + +[discrete] +== *Wann zu verwenden*: +* Überschreibungen in Unterklassen brechen das erwartete Verhalten der Basisklasse +* instanceof-/Typprüfungen erscheinen im Client-Code +* Vererbungshierarchien verletzen "ist-ein"-Beziehungen + +[discrete] +== *Prompt-Beispiel*: +"Überprüfe diese Vererbungshierarchie auf Verletzungen des SOLID-Liskov Substitution Principle." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/solid-ocp.adoc b/docs/anchors/solid-ocp.adoc new file mode 100644 index 0000000..026e78a --- /dev/null +++ b/docs/anchors/solid-ocp.adoc @@ -0,0 +1,31 @@ += SOLID-Open/Closed Principle +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: solid-principles +:tier: 1 +:proponents: Robert C. Martin, Bertrand Meyer +:tags: SOLID, design principle, OCP, open closed + +[%collapsible] +==== +Full Name:: SOLID Open/Closed Principle (OCP) + +[discrete] +== *Intent*: +Software entities should be open for extension but closed for modification. Add new behavior by adding new code, not changing existing code. + +[discrete] +== *When to Use*: +* Adding new features requires modifying existing working code +* Frequent changes to a module break other parts of the system +* You need a plugin or strategy-based extension mechanism + +[discrete] +== *Prompt Example*: +"Refactore diesen Code nach dem SOLID-Open/Closed Principle, sodass neue Varianten ohne Änderung des bestehenden Codes hinzugefügt werden können." + +[discrete] +== *Related Anchors*: +* <> (Umbrella) +* <> - Common OCP implementation +==== diff --git a/docs/anchors/solid-ocp.de.adoc b/docs/anchors/solid-ocp.de.adoc new file mode 100644 index 0000000..7569481 --- /dev/null +++ b/docs/anchors/solid-ocp.de.adoc @@ -0,0 +1,31 @@ += SOLID-Open/Closed Principle +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: solid-principles +:tier: 1 +:proponents: Robert C. Martin, Bertrand Meyer +:tags: SOLID, design principle, OCP, open closed + +[%collapsible] +==== +Vollständiger Name:: SOLID Open/Closed Principle (OCP) + +[discrete] +== *Absicht*: +Software-Entitäten sollten offen für Erweiterung, aber geschlossen für Modifikation sein. Neues Verhalten wird durch Hinzufügen von neuem Code erreicht, nicht durch Ändern von bestehendem Code. + +[discrete] +== *Wann zu verwenden*: +* Das Hinzufügen neuer Features erfordert Änderungen an bestehendem, funktionierendem Code +* Häufige Änderungen an einem Modul brechen andere Teile des Systems +* Ein Plugin- oder Strategy-basierter Erweiterungsmechanismus wird benötigt + +[discrete] +== *Prompt-Beispiel*: +"Refactore diesen Code nach dem SOLID-Open/Closed Principle, sodass neue Varianten ohne Änderung des bestehenden Codes hinzugefügt werden können." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +* <> - Gängige OCP-Implementierung +==== diff --git a/docs/anchors/solid-principles.adoc b/docs/anchors/solid-principles.adoc index be2495d..56eb5da 100644 --- a/docs/anchors/solid-principles.adoc +++ b/docs/anchors/solid-principles.adoc @@ -1,6 +1,10 @@ = SOLID Principles :categories: design-principles :roles: software-developer, software-architect, educator, consultant +:proponents: Robert C. Martin +:related: gof-design-patterns, clean-architecture +:tags: design-principles, oop, solid, uncle-bob +:sub-anchors: solid-srp, solid-ocp, solid-lsp, solid-isp, solid-dip [%collapsible] ==== diff --git a/docs/anchors/solid-srp.adoc b/docs/anchors/solid-srp.adoc new file mode 100644 index 0000000..11b786e --- /dev/null +++ b/docs/anchors/solid-srp.adoc @@ -0,0 +1,30 @@ += SOLID-Single Responsibility Principle +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: solid-principles +:tier: 1 +:proponents: Robert C. Martin +:tags: SOLID, design principle, SRP, single responsibility + +[%collapsible] +==== +Full Name:: SOLID Single Responsibility Principle (SRP) + +[discrete] +== *Intent*: +A class should have only one reason to change. Each module or class should be responsible for a single part of the software's functionality. + +[discrete] +== *When to Use*: +* A class has multiple unrelated responsibilities +* Changes to one feature require modifying unrelated code +* Unit testing requires complex setup due to tangled concerns + +[discrete] +== *Prompt Example*: +"Refactore diese Klasse nach dem SOLID-Single Responsibility Principle. Trenne die Verantwortlichkeiten in separate Klassen." + +[discrete] +== *Related Anchors*: +* <> (Umbrella) +==== diff --git a/docs/anchors/solid-srp.de.adoc b/docs/anchors/solid-srp.de.adoc new file mode 100644 index 0000000..29975d7 --- /dev/null +++ b/docs/anchors/solid-srp.de.adoc @@ -0,0 +1,30 @@ += SOLID-Single Responsibility Principle +:categories: design-principles +:roles: software-developer, software-architect +:umbrella: solid-principles +:tier: 1 +:proponents: Robert C. Martin +:tags: SOLID, design principle, SRP, single responsibility + +[%collapsible] +==== +Vollständiger Name:: SOLID Single Responsibility Principle (SRP) + +[discrete] +== *Absicht*: +Eine Klasse sollte nur einen Grund haben, sich zu ändern. Jedes Modul oder jede Klasse sollte für einen einzelnen Teil der Funktionalität der Software verantwortlich sein. + +[discrete] +== *Wann zu verwenden*: +* Eine Klasse hat mehrere, nicht zusammenhängende Verantwortlichkeiten +* Änderungen an einem Feature erfordern Modifikationen an nicht verwandtem Code +* Unit-Tests erfordern komplexes Setup aufgrund vermischter Zuständigkeiten + +[discrete] +== *Prompt-Beispiel*: +"Refactore diese Klasse nach dem SOLID-Single Responsibility Principle. Trenne die Verantwortlichkeiten in separate Klassen." + +[discrete] +== *Verwandte Anker*: +* <> (Umbrella) +==== diff --git a/docs/anchors/test-double-meszaros.de.adoc b/docs/anchors/test-double-meszaros.de.adoc new file mode 100644 index 0000000..3c77b25 --- /dev/null +++ b/docs/anchors/test-double-meszaros.de.adoc @@ -0,0 +1,47 @@ += Test Double (Meszaros) +:categories: testing-quality +:roles: software-developer, qa-engineer, educator +:proponents: Gerard Meszaros +:related: tdd-london-school, tdd-chicago-school, property-based-testing +:tags: test-double, mock, stub, spy, fake, dummy, xunit, testing, isolation + +[%collapsible] +==== +Vollständiger Name:: Test-Double-Taxonomie nach Gerard Meszaros + +Auch bekannt als:: xUnit Test Patterns Test-Double-Taxonomie + +[discrete] +== *Kernkonzepte*: + +Dummy:: Objekt, das übergeben wird, um eine Parameterliste zu füllen, aber nie tatsächlich verwendet wird + +Stub:: Liefert vorgefertigte Antworten auf Aufrufe während eines Tests; keine Verifikation von Interaktionen + +Spy:: Zeichnet Aufrufe für spätere Assertions auf; ein Stub, der zusätzlich Interaktionsdaten erfasst + +Mock:: Vorprogrammiert mit Erwartungen; verifiziert, dass bestimmte Interaktionen stattgefunden haben (interaktionsbasierte Verifikation) + +Fake:: Funktionierende vereinfachte Implementierung mit Abkürzungen, die für Produktion ungeeignet sind (z.B. In-Memory-Datenbank, In-Memory-Repository) + +Test Double:: Oberbegriff für jedes Objekt, das während des Testens für eine echte Abhängigkeit eingesetzt wird + +Vokabularpräzision:: Unterscheidung zwischen dem, was ein Double IST (Taxonomie) und wann man es einsetzt (TDD-Schulphilosophie) + + +Schlüsselvertreter:: Gerard Meszaros ("xUnit Test Patterns: Refactoring Test Code", 2007) + +[discrete] +== *Wann zu verwenden*: + +* Präzise Kommunikation über Test-Isolationsstrategien +* Auswahl des richtigen Double-Typs für ein gegebenes Testszenario +* Vermeidung von Vokabularkollisionen (z.B. einen Stub "Mock" zu nennen löst falsches Denken aus) +* Lehre oder Review von Testcode mit gemeinsamer Terminologie + +[discrete] +== *Verwandte Anker*: + +* <> - Philosophie des intensiven Double-Einsatzes (interaktionsbasiert) +* <> - Philosophie des minimalen Double-Einsatzes (zustandsbasiert) +==== diff --git a/docs/anchors/yagni.de.adoc b/docs/anchors/yagni.de.adoc new file mode 100644 index 0000000..e6a159b --- /dev/null +++ b/docs/anchors/yagni.de.adoc @@ -0,0 +1,46 @@ += YAGNI (You Aren't Gonna Need It) +:categories: design-principles +:roles: software-developer, software-architect, consultant +:proponents: Ron Jeffries, Kent Beck +:related: dry-principle, spot-principle, tdd-chicago-school +:tags: yagni, extreme-programming, simplicity, incremental-design, over-engineering + +[%collapsible] +==== +Vollständiger Name:: You Aren't Gonna Need It + +[discrete] +== *Kernkonzepte*: + +Nicht für hypothetische Zukunft bauen:: Funktionalität nur implementieren, wenn sie tatsächlich benötigt wird, nicht wenn man vermutet, dass sie benötigt werden könnte + +Spekulative Verallgemeinerung:: Anti-Pattern, Abstraktionen für vorgestellte zukünftige Anforderungen zu bauen, die möglicherweise nie eintreten + +Inkrementelles Design:: Design durch tatsächliche Bedürfnisse entstehen lassen; Architektur weiterentwickeln, wenn Anforderungen konkret werden + +Kosten des Mitführens:: Ungenutzter Code erhöht den Wartungsaufwand, steigert die Komplexität und erzeugt kognitive Last für das gesamte Team + +Toten Code löschen:: Code, der keinem aktuellen Zweck mehr dient, konsequent entfernen + +Extreme-Programming-Ursprung:: Zentrale XP-Praxis neben TDD, Refactoring und Continuous Integration + +Reversibilität:: Einfache, änderbare Entscheidungen gegenüber voreiligen Festlegungen auf komplexe Lösungen bevorzugen + + +Schlüsselvertreter:: Ron Jeffries (prägte den Begriff), Kent Beck ("Extreme Programming Explained", 1999) + +[discrete] +== *Wann zu verwenden*: + +* Bekämpfung von Over-Engineering und voreiliger Abstraktion +* Agile Projekte mit iterativer Lieferung und sich entwickelnden Anforderungen +* Refactoring von Legacy-Systemen, die mit ungenutzten Features belastet sind +* Wenn man versucht ist, "Nur-für-den-Fall"-Funktionalität oder Konfigurierbarkeit hinzuzufügen + +[discrete] +== *Verwandte Anker*: + +* <> - Eliminiert Duplizierung vorhandenen Wissens (komplementär, aber verschieden) +* <> - Single Point of Truth, verwandtes Einfachheitsprinzip +* <> - YAGNI ist ein Kernprinzip des klassischen TDD +==== diff --git a/scripts/eslint.config.mjs b/scripts/eslint.config.mjs index 563f522..293a378 100644 --- a/scripts/eslint.config.mjs +++ b/scripts/eslint.config.mjs @@ -17,6 +17,7 @@ export default [ prettierConfig, { files: ['**/*.js'], + ignores: ['**/*.test.js'], languageOptions: { ecmaVersion: 2022, sourceType: 'commonjs', @@ -27,4 +28,15 @@ export default [ 'no-console': 'off', }, }, + { + files: ['**/*.test.js'], + languageOptions: { + ecmaVersion: 2022, + sourceType: 'module', + }, + rules: { + 'no-unused-vars': ['warn', { argsIgnorePattern: '^_', caughtErrorsIgnorePattern: '^_' }], + 'no-console': 'off', + }, + }, ] diff --git a/skill/semantic-anchor-translator/references/catalog.md b/skill/semantic-anchor-translator/references/catalog.md index 5c14791..1b04f2e 100644 --- a/skill/semantic-anchor-translator/references/catalog.md +++ b/skill/semantic-anchor-translator/references/catalog.md @@ -82,6 +82,26 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors ### SOLID Principles - **Core:** Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion +#### SOLID-SRP (Single Responsibility Principle) +- **Proponents:** Robert C. Martin +- **Core:** Each class should have only one reason to change + +#### SOLID-OCP (Open/Closed Principle) +- **Proponents:** Robert C. Martin, Bertrand Meyer +- **Core:** Open for extension, closed for modification + +#### SOLID-LSP (Liskov Substitution Principle) +- **Proponents:** Robert C. Martin, Barbara Liskov +- **Core:** Subtypes must be substitutable for their base types + +#### SOLID-ISP (Interface Segregation Principle) +- **Proponents:** Robert C. Martin +- **Core:** Don't force clients to depend on unused interfaces + +#### SOLID-DIP (Dependency Inversion Principle) +- **Proponents:** Robert C. Martin +- **Core:** Depend on abstractions, not concrete implementations + ### DRY (Don't Repeat Yourself) - **Core:** Every piece of knowledge has single, unambiguous representation @@ -100,6 +120,35 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors - **Proponents:** Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides - **Core:** 23 patterns in 3 categories (Creational, Structural, Behavioral), pattern language, composition over inheritance, program to an interface +#### Creational Patterns +- **GoF-Abstract Factory** — Families of related objects without specifying concrete classes +- **GoF-Builder** — Construct complex objects step by step +- **GoF-Factory Method** — Let subclasses decide which class to instantiate +- **GoF-Prototype** — Clone existing objects +- **GoF-Singleton** — Ensure single instance with global access + +#### Structural Patterns +- **GoF-Adapter** — Convert interface to one clients expect +- **GoF-Bridge** — Separate abstraction from implementation +- **GoF-Composite** — Compose objects into tree structures +- **GoF-Decorator** — Add responsibilities dynamically +- **GoF-Facade** — Simplified interface to a subsystem +- **GoF-Flyweight** — Share fine-grained objects efficiently (not a semantic anchor) +- **GoF-Proxy** — Surrogate controlling access to another object + +#### Behavioral Patterns +- **GoF-Chain of Responsibility** — Pass requests along a chain of handlers +- **GoF-Command** — Encapsulate requests as objects +- **GoF-Interpreter** — Grammar and interpreter for a language (not a semantic anchor) +- **GoF-Iterator** — Sequential access without exposing structure +- **GoF-Mediator** — Centralize complex communications +- **GoF-Memento** — Capture and restore object state (not a semantic anchor) +- **GoF-Observer** — Notify dependents of state changes +- **GoF-State** — Alter behavior when internal state changes +- **GoF-Strategy** — Interchangeable algorithm families +- **GoF-Template Method** — Define skeleton, let subclasses fill in steps +- **GoF-Visitor** — Operations on elements without changing their classes (not a semantic anchor) + ### Patterns of Enterprise Application Architecture (PEAA) - **Proponents:** Martin Fowler - **Core:** Repository, Unit of Work, Data Mapper, Active Record, etc. diff --git a/website/public/data/metadata.json b/website/public/data/metadata.json index a17269a..ac07583 100644 --- a/website/public/data/metadata.json +++ b/website/public/data/metadata.json @@ -1,15 +1,15 @@ { - "generatedAt": "2026-03-09T15:16:57.712Z", + "generatedAt": "2026-03-09T14:10:44.809Z", "version": "1.0.0", "counts": { - "anchors": 86, + "anchors": 85, "categories": 12, "roles": 12 }, "statistics": { - "averageRolesPerAnchor": "2.99", + "averageRolesPerAnchor": "2.96", "averageCategoriesPerAnchor": "1.00", - "anchorsWithTags": 41, + "anchorsWithTags": 40, "anchorsWithRelated": 16 } } \ No newline at end of file diff --git a/website/src/components/card-grid.js b/website/src/components/card-grid.js index dcb8952..7f70bec 100644 --- a/website/src/components/card-grid.js +++ b/website/src/components/card-grid.js @@ -64,10 +64,7 @@ export function renderCardGrid(categories, anchors) { */ function renderCategorySection(category, allAnchors) { const categoryAnchors = allAnchors.filter( - (anchor) => - anchor.categories && - anchor.categories.includes(category.id) && - !anchor.umbrella + (anchor) => anchor.categories && anchor.categories.includes(category.id) && !anchor.umbrella ) if (categoryAnchors.length === 0) return '' diff --git a/website/src/components/card-grid.test.js b/website/src/components/card-grid.test.js index e7ad400..5177e6c 100644 --- a/website/src/components/card-grid.test.js +++ b/website/src/components/card-grid.test.js @@ -18,8 +18,25 @@ describe('umbrella anchors', () => { it('should not render sub-anchors in the main catalog', () => { const categories = [{ id: 'design-principles', name: 'Design Principles' }] const anchors = [ - { id: 'gof-design-patterns', title: 'GoF', categories: ['design-principles'], roles: ['software-developer'], subAnchors: ['gof-strategy-pattern'], tags: [], proponents: [] }, - { id: 'gof-strategy-pattern', title: 'GoF-Strategy', categories: ['design-principles'], roles: ['software-developer'], umbrella: 'gof-design-patterns', tier: 1, tags: [], proponents: [] }, + { + id: 'gof-design-patterns', + title: 'GoF', + categories: ['design-principles'], + roles: ['software-developer'], + subAnchors: ['gof-strategy-pattern'], + tags: [], + proponents: [], + }, + { + id: 'gof-strategy-pattern', + title: 'GoF-Strategy', + categories: ['design-principles'], + roles: ['software-developer'], + umbrella: 'gof-design-patterns', + tier: 1, + tags: [], + proponents: [], + }, ] const html = renderCardGrid(categories, anchors) expect(html).toContain('gof-design-patterns') @@ -29,7 +46,15 @@ describe('umbrella anchors', () => { it('should add umbrella class to umbrella cards', () => { const categories = [{ id: 'design-principles', name: 'Design Principles' }] const anchors = [ - { id: 'gof-design-patterns', title: 'GoF', categories: ['design-principles'], roles: ['software-developer'], subAnchors: ['gof-strategy-pattern'], tags: [], proponents: [] }, + { + id: 'gof-design-patterns', + title: 'GoF', + categories: ['design-principles'], + roles: ['software-developer'], + subAnchors: ['gof-strategy-pattern'], + tags: [], + proponents: [], + }, ] const html = renderCardGrid(categories, anchors) expect(html).toContain('anchor-card-umbrella') diff --git a/website/src/styles/main.css b/website/src/styles/main.css index 9c659fb..c94cc11 100644 --- a/website/src/styles/main.css +++ b/website/src/styles/main.css @@ -296,7 +296,6 @@ body { animation: fade-out 0.3s ease-out; } - /* Sub-anchor tier styling */ .sub-anchor-item.tier-1 { font-weight: 600;