mirror of
https://github.com/tiennm99/java-design-patterns.git
synced 2026-10-04 14:13:21 +00:00
docs: Improve existing German READMEs and add new ones (#3444)
* docs: reformulate text, add links to further languages and paragraph about the book in central README.md (#2275) * docs: shorten text for link to payhip (#2275) * docs: reformulate german translation for Abstract Document (#2275) * Create folder for Abstract Factory * Create README.md for Abstract Document * Translate README.md for Abstract Document to German * correct typo * docs: add class diagrams for all patterns (#2275) * docs: add missing words in abstract-factory.README.md (#2275) * docs: Create German README.md for Active Object #2275 first text part * docs: finish German translation of README.md for Active Object * docs: translate actor-model into German #2295 * docs: add German translation for Acyclic Visitor #2295 * correct typo * docs: Translate Singleton into German #2295 * docs: Translate Prototype into German #2295 * Delete localization/de/Abstract Factory * insert line break * correct typos in actor-model * realignment of java code block * docs: translate Adapter Pattern into German #2295 * Update README.md change 'lizenz' to 'Lizenz' in badge * Update README.md translate 'benefits' and 'trade-offs' * remove additional bullet point after line break * correct indentation * docs: translate Dependency Injection into German #2295 * docs: translate Bridge into German #2295 * correct typos * docs: Translate Builder into German * delete english text * little changes in formulation * Update README.md change link to image * docs: remove spanish files (#2275) * docs: remove non-translated patterns (#2275) * Create README.md docs: Translate Step Builder into German #2275 * Create README.md docs: Translate Fluent Interface into German #2275 * eager is eifrig, not gierig * Translate Chain of Responsibility into German #2275
This commit is contained in:
Stefan Siebers authored and GitHub committed
1 parent
bdc008fb78
commit
cd4753a660
15 files changed
+2583
-84
No files matched your search
@@ -1,43 +1,48 @@
|
||||
---
|
||||
title: "Abstract Document Pattern in Java: Vereinfachung der Datenverwaltung mit Flexibilität"
|
||||
shortTitle: Abstract Document
|
||||
description: "Erkunden Sie das Abstract Document Design Pattern in Java. Lernen Sie seine Absicht, Erklärung, Anwendbarkeit, Vorteile kennen und sehen Sie reale Beispiele zur Implementierung flexibler und dynamischer Datenstrukturen."
|
||||
category: Strukturell
|
||||
category: Structural
|
||||
language: de
|
||||
tag:
|
||||
- Abstraktion
|
||||
- Entkopplung
|
||||
- Dynamische Typisierung
|
||||
- Kapselung
|
||||
- Erweiterbarkeit
|
||||
- Polymorphismus
|
||||
- Abstraction
|
||||
- Decoupling
|
||||
- Dynamic typing
|
||||
- Encapsulation
|
||||
- Extensibility
|
||||
- Polymorphism
|
||||
---
|
||||
|
||||
## Absicht des Abstract Document Design Patterns
|
||||
## Zweck
|
||||
|
||||
Das Abstract Document Design Pattern in Java ist ein wichtiges strukturelles Design Pattern, das eine konsistente Möglichkeit bietet, hierarchische und baumartige Datenstrukturen zu handhaben, indem es eine gemeinsame Schnittstelle für verschiedene Dokumenttypen definiert. Es trennt die Kernstruktur des Dokuments von spezifischen Datenformaten und ermöglicht dynamische Aktualisierungen und vereinfachte Wartung.
|
||||
Abstract Document ist ein wichtiges Struktur-Pattern, das ein einheitliches Handling von hierarchischen baumartige Datenstrukturen ermöglicht, indem es eine gemeinsame Schnittstelle für verschiedene Dokumenttypen definiert. Es trennt die Kernstruktur des Dokuments von spezifischen Datenformaten und ermöglicht so dynamische Aktualisierungen und einfachere Wartung.
|
||||
|
||||
## Detaillierte Erklärung des Abstract Document Patterns mit realen Beispielen
|
||||
## Detaillierte Erklärung
|
||||
|
||||
Das Abstract Document Design Pattern in Java ermöglicht die dynamische Handhabung nicht-statischer Eigenschaften. Dieses Pattern verwendet das Konzept der Traits, um Typsicherheit zu gewährleisten und Eigenschaften verschiedener Klassen in eine Menge von Schnittstellen zu trennen.
|
||||
Abstract Document erlaubt die dynamische Behandlung nicht-statischer Eigenschaften. Dieses Pattern verwendet das Konzept der Traits, um Typsicherheit zu gewährleisten und Eigenschaften verschiedener Klassen in verschiedene Schnittstellen abzuspalten.
|
||||
|
||||
Reales Beispiel
|
||||
|
||||
> Betrachten Sie ein Bibliothekssystem, das das Abstract Document Design Pattern in Java implementiert, wo Bücher verschiedene Formate und Attribute haben können: physische Bücher, eBooks und Hörbücher. Jedes Format hat einzigartige Eigenschaften, wie Seitenzahl für physische Bücher, Dateigröße für eBooks und Dauer für Hörbücher. Das Abstract Document Design Pattern ermöglicht es dem Bibliothekssystem, diese verschiedenen Formate flexibel zu verwalten. Durch die Verwendung dieses Patterns kann das System Eigenschaften dynamisch speichern und abrufen, ohne dass eine starre Struktur für jeden Buchtyp erforderlich ist, was es einfacher macht, neue Formate oder Attribute in der Zukunft hinzuzufügen, ohne dass wesentliche Änderungen am Codebase erforderlich sind.
|
||||
> Denken Sie an ein Bibliothekssystem, wo Bücher verschiedene Formate und Attribute haben können: physische Bücher, eBooks und Hörbücher. Jedes Format hat spezielle Eigenschaften, wie die Seitenzahl bei physischen Büchern, die Dateigröße bei eBooks oder die Spielzeit bei Hörbüchern. Das Abstract Document Design Pattern ermöglicht es dem Bibliothekssystem, diese verschiedenen Formate flexibel zu verwalten. Durch die Verwendung dieses Patterns kann das System Eigenschaften dynamisch speichern und abrufen, ohne dass eine starre Struktur für jeden Buchtyp erforderlich ist. Damit wird es einfacher, in der Zukunft neue Formate oder Attribute hinzuzufügen, ohne erhebliche Änderungen am Code vornehmen zu müssen.
|
||||
|
||||
In einfachen Worten
|
||||
|
||||
> Das Abstract Document Pattern ermöglicht das Anhängen von Eigenschaften an Objekte, ohne dass diese davon wissen.
|
||||
> Abstract Document erlaubt das Anhängen von Eigenschaften an Objekte, ohne dass diese davon wissen.
|
||||
|
||||
Wikipedia sagt
|
||||
|
||||
> Ein objektorientiertes strukturelles Design Pattern zur Organisation von Objekten in schwach typisierten Schlüssel-Wert-Speichern und zur Bereitstellung der Daten über typisierte Ansichten. Der Zweck des Patterns besteht darin, einen hohen Grad an Flexibilität zwischen Komponenten in einer stark typisierten Sprache zu erreichen, in der neue Eigenschaften zur Objektstruktur dynamisch hinzugefügt werden können, ohne die Unterstützung der Typsicherheit zu verlieren. Das Pattern verwendet Traits, um verschiedene Eigenschaften einer Klasse in verschiedene Schnittstellen zu trennen.
|
||||
> Ein objektorientiertes strukturelles Design Pattern zur Organisation von Objekten in schwach typisierten Schlüssel-Wert-Speichern mit Darstellung der Daten über typisierte Ansichten. Der Zweck des Patterns besteht darin, einen hohen Grad an Flexibilität zwischen Komponenten in einer stark typisierten Sprache zu erreichen, in der neue Eigenschaften zur Objektstruktur dynamisch hinzugefügt werden können, ohne die Unterstützung der Typsicherheit zu verlieren. Das Pattern verwendet Traits, um verschiedene Klasseneigenschaften in verschiedene Schnittstellen abzutrennen.
|
||||
|
||||
## Programmatisches Beispiel des Abstract Document Patterns in Java
|
||||
## Klassendiagramm
|
||||
|
||||
Betrachten Sie ein Auto, das aus mehreren Teilen besteht. Wir wissen jedoch nicht, ob das spezifische Auto wirklich alle Teile hat oder nur einige davon. Unsere Autos sind dynamisch und extrem flexibel.
|
||||
|
||||
|
||||
Lassen Sie uns zunächst die Basisklassen `Document` und `AbstractDocument` definieren. Sie sorgen im Wesentlichen dafür, dass das Objekt eine Eigenschaftsmap und eine beliebige Anzahl von Kindobjekten enthält.
|
||||
## Beispielprogramm in Java
|
||||
|
||||
Betrachten Sie ein Auto, das aus mehreren Teilen besteht. Wir wissen jedoch nicht,
|
||||
ob das spezifische Auto wirklich alle Teile hat oder nur einige davon.
|
||||
Unsere Autos sind dynamisch und extrem flexibel.
|
||||
|
||||
Zunächst definieren wir die Basisklassen `Document` und `AbstractDocument`.
|
||||
Sie sorgen im Wesentlichen dafür, dass jedes Objekt eine Map von Eigenschaften und eine beliebige Anzahl von Kindobjekten enthält.
|
||||
|
||||
```java
|
||||
public interface Document {
|
||||
@@ -80,10 +85,11 @@ public abstract class AbstractDocument implements Document {
|
||||
.map(constructor);
|
||||
}
|
||||
|
||||
// Andere Eigenschaften und Methoden...
|
||||
// Weitere Eigenschaften und Methoden...
|
||||
}
|
||||
```
|
||||
Als nächstes definieren wir ein Enum Property und eine Menge von Schnittstellen für Typ, Preis, Modell und Teile. Dies ermöglicht es uns, eine statisch aussehende Schnittstelle für unsere Car-Klasse zu erstellen.
|
||||
|
||||
Als nächstes definieren wir ein Enum `Property` und je eine Schnittstelle für Typ, Preis, Modell und Teile. So können wir eine statisch aussehende Schnittstelle für unsere Klasse `Car` erstellen.
|
||||
|
||||
```java
|
||||
public enum Property {
|
||||
@@ -120,33 +126,43 @@ public interface HasParts extends Document {
|
||||
}
|
||||
```
|
||||
|
||||
Jetzt sind wir bereit, das `Car` einzuführen.
|
||||
Nun können wir das `Car` einführen.
|
||||
|
||||
```java
|
||||
public static void main(String[] args) {
|
||||
LOGGER.info("Konstruktion von Teilen und Auto");
|
||||
public class Car extends AbstractDocument implements HasModel, HasPrice, HasParts {
|
||||
|
||||
var wheelProperties = Map.of(
|
||||
Property.TYPE.toString(), "wheel",
|
||||
Property.MODEL.toString(), "15C",
|
||||
Property.PRICE.toString(), 100L);
|
||||
public Car(Map<String, Object> properties) {
|
||||
super(properties);
|
||||
}
|
||||
}
|
||||
```
|
||||
Und schließlich konstruieren und verwenden wir ein solches `Car`.
|
||||
|
||||
var doorProperties = Map.of(
|
||||
Property.TYPE.toString(), "door",
|
||||
Property.MODEL.toString(), "Lambo",
|
||||
Property.PRICE.toString(), 300L);
|
||||
```java
|
||||
public static void main(String[] args) {
|
||||
LOGGER.info("Constructing parts and car");
|
||||
|
||||
var carProperties = Map.of(
|
||||
Property.MODEL.toString(), "300SL",
|
||||
Property.PRICE.toString(), 10000L,
|
||||
Property.PARTS.toString(), List.of(wheelProperties, doorProperties));
|
||||
var wheelProperties = Map.of(
|
||||
Property.TYPE.toString(), "wheel",
|
||||
Property.MODEL.toString(), "15C",
|
||||
Property.PRICE.toString(), 100L);
|
||||
|
||||
var car = new Car(carProperties);
|
||||
var doorProperties = Map.of(
|
||||
Property.TYPE.toString(), "door",
|
||||
Property.MODEL.toString(), "Lambo",
|
||||
Property.PRICE.toString(), 300L);
|
||||
|
||||
LOGGER.info("Hier ist unser Auto:");
|
||||
LOGGER.info("-> Modell: {}", car.getModel().orElseThrow());
|
||||
LOGGER.info("-> Preis: {}", car.getPrice().orElseThrow());
|
||||
LOGGER.info("-> Teile: ");
|
||||
var carProperties = Map.of(
|
||||
Property.MODEL.toString(), "300SL",
|
||||
Property.PRICE.toString(), 10000L,
|
||||
Property.PARTS.toString(), List.of(wheelProperties, doorProperties));
|
||||
|
||||
var car = new Car(carProperties);
|
||||
|
||||
LOGGER.info("Here is our car:");
|
||||
LOGGER.info("-> model: {}", car.getModel().orElseThrow());
|
||||
LOGGER.info("-> price: {}", car.getPrice().orElseThrow());
|
||||
LOGGER.info("-> parts: ");
|
||||
car.getParts().forEach(p -> LOGGER.info("\t{}/{}/{}",
|
||||
p.getType().orElse(null),
|
||||
p.getModel().orElse(null),
|
||||
@@ -154,50 +170,67 @@ Jetzt sind wir bereit, das `Car` einzuführen.
|
||||
);
|
||||
}
|
||||
```
|
||||
Die Programmausgabe:
|
||||
Programmausgabe:
|
||||
|
||||
```
|
||||
07:21:57.391 [main] INFO com.iluwatar.abstractdocument.App -- Konstruktion von Teilen und Auto
|
||||
07:21:57.393 [main] INFO com.iluwatar.abstractdocument.App -- Hier ist unser Auto:
|
||||
07:21:57.393 [main] INFO com.iluwatar.abstractdocument.App -- -> Modell: 300SL
|
||||
07:21:57.394 [main] INFO com.iluwatar.abstractdocument.App -- -> Preis: 10000
|
||||
07:21:57.394 [main] INFO com.iluwatar.abstractdocument.App -- -> Teile:
|
||||
07:21:57.395 [main] INFO com.iluwatar.abstractdocument.App -- Rad/15C/100
|
||||
07:21:57.395 [main] INFO com.iluwatar.abstractdocument.App -- Tür/Lambo/300
|
||||
07:21:57.391 [main] INFO com.iluwatar.abstractdocument.App -- Constructing parts and car
|
||||
07:21:57.393 [main] INFO com.iluwatar.abstractdocument.App -- Here is our car:
|
||||
07:21:57.393 [main] INFO com.iluwatar.abstractdocument.App -- -> model: 300SL
|
||||
07:21:57.394 [main] INFO com.iluwatar.abstractdocument.App -- -> price: 10000
|
||||
07:21:57.394 [main] INFO com.iluwatar.abstractdocument.App -- -> parts:
|
||||
07:21:57.395 [main] INFO com.iluwatar.abstractdocument.App -- wheel/15C/100
|
||||
07:21:57.395 [main] INFO com.iluwatar.abstractdocument.App -- door/Lambo/300
|
||||
```
|
||||
## Abstract Document Pattern Klassendiagramm
|
||||
|
||||
|
||||
## Verwendung
|
||||
|
||||
## Wann sollte das Abstract Document Pattern in Java verwendet werden?
|
||||
|
||||
Das Abstract Document Design Pattern ist besonders vorteilhaft in Szenarien, die eine Verwaltung unterschiedlicher Dokumenttypen in Java erfordern, die einige gemeinsame Attribute oder Verhaltensweisen teilen, aber auch einzigartige Attribute oder Verhaltensweisen haben, die spezifisch für ihren Typ sind. Hier sind einige Szenarien, in denen das Abstract Document Design Pattern anwendbar ist:
|
||||
Abstract Document ist besonders vorteilhaft in Szenarien, die eine Verwaltung unterschiedlicher
|
||||
Dokumenttypen erfordern, die zwar einige gemeinsame Attribute oder Verhaltensweisen teilen,
|
||||
aber auch typspezifische Eigenschaften haben. Hier sind einige Beispiele:
|
||||
|
||||
* **Content-Management-Systeme (CMS)**: In einem CMS könnten verschiedene Arten von Inhalten wie Artikel, Bilder, Videos usw. vorkommen. Jede Inhaltsart könnte gemeinsame Attribute wie Erstellungsdatum, Autor und Tags haben, aber auch spezifische Attribute wie Bildabmessungen für Bilder oder Videodauer für Videos.
|
||||
|
||||
* **Dateisysteme**: Wenn Sie ein Dateisystem entwerfen, in dem unterschiedliche Dateitypen verwaltet werden müssen, wie Dokumente, Bilder, Audiodateien und Verzeichnisse, kann das Abstract Document Pattern helfen, eine konsistente Möglichkeit zum Zugriff auf Attribute wie Dateigröße, Erstellungsdatum usw. zu bieten, während spezifische Attribute wie Bildauflösung oder Audiodauer berücksichtigt werden.
|
||||
* **Dateisysteme**: Wenn Sie ein Dateisystem entwerfen, in dem unterschiedliche Dateitypen verwaltet werden müssen, wie Dokumente, Bilder, Audiodateien und Verzeichnisse, kann das Pattern helfen, einen einheitlichen Zugriff auf Attribute wie Dateigröße, Erstellungsdatum usw. zu bieten, aber zugleich spezifische Attribute wie Bildauflösung oder Audiodauer zu berücksichtigen.
|
||||
|
||||
* **E-Commerce-Systeme**: Eine E-Commerce-Plattform könnte verschiedene Produkttypen haben, wie physische Produkte, digitale Downloads und Abonnements. Jeder Typ könnte gemeinsame Attribute wie Name, Preis und Beschreibung haben, aber auch einzigartige Attribute wie Versandgewicht für physische Produkte oder Download-Link für digitale Produkte.
|
||||
* **E-Commerce-Systeme**: Eine E-Commerce-Plattform kann verschiedene Produkttypen haben,
|
||||
wie physische Produkte, digitale Downloads und Abonnements.
|
||||
Alle Typen haben gemeinsame Attribute wie Name, Preis und Beschreibung,
|
||||
aber auch einzigartige Attribute wie Versandgewicht für physische Produkte
|
||||
oder Download-Link für digitale Produkte.
|
||||
|
||||
* **Medizinische Aufzeichnungssysteme**: Im Gesundheitswesen könnten Patientenakten verschiedene Datentypen enthalten, wie demografische Daten, medizinische Vorgeschichte, Testergebnisse und Rezepte. Das Abstract Document Pattern kann helfen, gemeinsame Attribute wie Patienten-ID und Geburtsdatum zu verwalten, während spezialisierte Attribute wie Testergebnisse oder verschriebene Medikamente berücksichtigt werden.
|
||||
* **Medizindatensysteme**: Im Gesundheitswesen enthalten Patientenakten verschiedene
|
||||
Datentypen wie demografische Daten, medizinische Vorgeschichte, Testergebnisse und Rezepte.
|
||||
Das Abstract Document Pattern kann helfen, gemeinsame Attribute wie Patienten-ID und Geburtsdatum zu
|
||||
verwalten und zusätzlich spezielle Attribute wie Testergebnisse oder verschriebene Medikamente zu berücksichtigt werden.
|
||||
|
||||
* **Konfigurationsmanagement**: Bei der Verwaltung von Konfigurationseinstellungen für Softwareanwendungen gibt es möglicherweise verschiedene Arten von Konfigurationselementen, jedes mit einer eigenen Reihe von Attributen. Das Abstract Document Pattern kann verwendet werden, um diese Konfigurationselemente zu verwalten, während eine konsistente Möglichkeit zum Zugriff auf und Bearbeiten der Attribute sichergestellt wird.
|
||||
* **Konfigurationsmanagement**: Bei der Verwaltung von Konfigurationseinstellungen für
|
||||
Software gibt es verschiedene Arten von Konfigurationselementen, jedes mit einer eigenen Reihe
|
||||
von Attributen. Mit dem Abstract Document Pattern können diese Konfigurationselemente
|
||||
konsistent verwaltet werden.
|
||||
|
||||
* **Bildungsplattformen**: Bildungssysteme könnten verschiedene Arten von Lernmaterialien wie textbasierte Inhalte, Videos, Quizze und Aufgaben haben. Gemeinsame Attribute wie Titel, Autor und Veröffentlichungsdatum können geteilt werden, während spezifische Attribute wie Videodauer oder Aufgabenfälligkeit für jeden Typ einzigartig sind.
|
||||
* **Bildungsplattformen**: Bildungssysteme nutzen verschiedene Arten von Lernmaterialien wie textbasierte Inhalte,
|
||||
Videos, Quiz und Übungsaufgaben. Gemeinsame Attribute können Titel, Autor und Veröffentlichungsdatum sein,
|
||||
während spezifische Attribute wie Videodauer oder Aufgabenfälligkeit typabhängig sind.
|
||||
|
||||
* **Projektmanagement-Tools**: In Projektmanagement-Anwendungen könnten unterschiedliche Aufgabenarten wie To-Do-Items, Meilensteine und Probleme vorliegen. Das Abstract Document Pattern könnte verwendet werden, um allgemeine Attribute wie Aufgabenname und Zuweisung zu handhaben, während spezifische Attribute wie Meilensteindaten oder Problemprioritäten zugelassen werden.
|
||||
* **Projektmanagement-Tools**: In Projektmanagement-Anwendungen können unterschiedliche Aufgabenarten
|
||||
wie To-Dos, Meilensteine und Probleme vorliegen. Das Abstract Document Pattern kann verwendet werden, um allgemeine
|
||||
Attribute wie Aufgabenname und Zuständigkeit zu handhaben, während spezifische Attribute wie Meilensteindaten oder
|
||||
Aufgabenprioritäten zugelassen sind.
|
||||
|
||||
* **Dokumente haben vielfältige und sich entwickelnde Attributstrukturen.**
|
||||
* **Dokumente haben vielfältige und sich verändernde Attributstrukturen.**
|
||||
|
||||
* **Dynamisches Hinzufügen neuer Eigenschaften ist eine häufige Anforderung.**
|
||||
* **Häufig ist es erforderlich, neue Eigenschaften dynamisch hinzuzufügen.**
|
||||
|
||||
* **Entkopplung des Datenzugriffs von spezifischen Formaten ist entscheidend.**
|
||||
* **Entscheidend ist die Entkopplung des Datenzugriffs von spezifischen Formaten.**
|
||||
|
||||
* **Wartbarkeit und Flexibilität sind entscheidend für die Codebasis.**
|
||||
* **Wartbarkeit und Flexibilität sind wesentlich für die Codebasis.**
|
||||
|
||||
Die Hauptidee hinter dem Abstract Document Design Pattern ist es, eine flexible und erweiterbare Möglichkeit zur Verwaltung unterschiedlicher Dokumenttypen oder Entitäten mit gemeinsamen und spezifischen Attributen bereitzustellen. Durch die Definition einer gemeinsamen Schnittstelle und deren Implementierung über verschiedene Dokumenttypen hinweg können Sie einen besser organisierten und konsistenteren Ansatz zur Handhabung komplexer Datenstrukturen erreichen.
|
||||
Die Kernidee des Abstract Document Pattern ist es, eine flexible und erweiterbare Möglichkeit zur Verwaltung
|
||||
unterschiedlicher Dokumenttypen oder Entitäten mit gemeinsamen und spezifischen Attributen bereitzustellen.
|
||||
Durch die Definition einer gemeinsamen Schnittstelle und deren Implementierung über verschiedene Dokumenttypen
|
||||
hinweg können Sie komplexe Datenstrukturen besser organisiert und einheitlich verarbeiten.
|
||||
|
||||
## Vorteile und Abwägungen des Abstract Document Patterns
|
||||
## Vor- und Nachteile
|
||||
|
||||
**Vorteile:**
|
||||
|
||||
@@ -206,12 +239,12 @@ Die Hauptidee hinter dem Abstract Document Design Pattern ist es, eine flexible
|
||||
* **Wartbarkeit**: Fördert sauberen und anpassungsfähigen Code durch Trennung der Verantwortlichkeiten.
|
||||
* **Wiederverwendbarkeit**: Typspezifische Ansichten ermöglichen eine Wiederverwendung des Codes zum Zugriff auf bestimmte Attributtypen.
|
||||
|
||||
**Abwägungen:**
|
||||
**Nachteile:**
|
||||
|
||||
* **Komplexität**: Erfordert die Definition von Schnittstellen und Ansichten, was zu zusätzlichem Implementierungsaufwand führt.
|
||||
* **Leistung**: Kann im Vergleich zum direkten Datenzugriff zu leichtem Leistungsaufwand führen.
|
||||
* **Komplexität**: Die Definition von Schnittstellen und spezifischen Ansichten erfordert zusätzlichen Implementierungsaufwand.
|
||||
* **Performance**: Leicht verringerte Performance im Vergleich zum direkten Datenzugriff möglich.
|
||||
|
||||
## Quellen und Danksagungen
|
||||
## Quellen
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](https://amzn.to/3w0pvKI)
|
||||
* [Java Design Patterns: A Hands-On Experience with Real-World Examples](https://amzn.to/3yhh525)
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 94 KiB |
Reference in new issue
Block a user