Skip to content

Commit e71866f

Browse files
siebersssieberss
authored
Create README.md for Abstract Document
1 parent 398d4f5 commit e71866f

1 file changed

Lines changed: 227 additions & 0 deletions

File tree

‎localization/de/abstract-factory/README.md‎

Lines changed: 227 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,227 @@
1+
---
2+
shortTitle: Abstract Factory
3+
category: Creational
4+
language: de
5+
tag:
6+
- Abstraction
7+
- Decoupling
8+
- Gang of Four
9+
- Instantiation
10+
- Polymorphism
11+
---
12+
13+
## Alternativbezeichnung
14+
15+
* Kit
16+
17+
## Zweck
18+
19+
Das Abstract-Factory-Pattern stellt ein Interface zum Erzeugen von Instanzen einer Familie
20+
ähnlicher oder voneinander abhängiger Objekte zur Verfügung, ohne dass dabei deren konkrete Klasse
21+
festgelegt ist. Damit werden Modularität und Flexibilität im Softwaredesign verbessert.
22+
23+
## Detailed Explanation of Abstract Factory Pattern with Real-World Examples
24+
25+
Real-world example
26+
27+
> Imagine a furniture company that uses the Abstract Factory pattern in Java to produce various styles of furniture: modern, Victorian, and rustic. Each style includes products like chairs, tables, and sofas. To ensure consistency within each style, the company uses an Abstract Factory pattern.
28+
>
29+
> In this scenario, the Abstract Factory is an interface for creating families of related furniture objects (chairs, tables, sofas). Each concrete factory (ModernFurnitureFactory, VictorianFurnitureFactory, RusticFurnitureFactory) implements the Abstract Factory interface and creates a set of products that match the specific style. This way, clients can create a whole set of modern or Victorian furniture without worrying about the details of their instantiation. This maintains a consistent style and allows easy swapping of one style of furniture for another.
30+
31+
In plain words
32+
33+
> A factory of factories; a factory that groups the individual but related/dependent factories together without specifying their concrete classes.
34+
35+
Wikipedia says
36+
37+
> The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes
38+
39+
Class diagram
40+
41+
![Abstract Factory class diagram](./etc/abstract-factory.urm.png "Abstract Factory class diagram")
42+
43+
## Programmatic Example of Abstract Factory in Java
44+
45+
To create a kingdom using the Abstract Factory pattern in Java, we need objects with a common theme. The elven kingdom needs an elven king, elven castle, and elven army whereas the orcish kingdom needs an orcish king, orcish castle, and orcish army. There is a dependency between the objects in the kingdom.
46+
47+
Translating the kingdom example above. First of all, we have some interfaces and implementation for the objects in the kingdom.
48+
49+
```java
50+
public interface Castle {
51+
String getDescription();
52+
}
53+
54+
public interface King {
55+
String getDescription();
56+
}
57+
58+
public interface Army {
59+
String getDescription();
60+
}
61+
62+
// Elven implementations ->
63+
public class ElfCastle implements Castle {
64+
static final String DESCRIPTION = "This is the elven castle!";
65+
66+
@Override
67+
public String getDescription() {
68+
return DESCRIPTION;
69+
}
70+
}
71+
72+
public class ElfKing implements King {
73+
static final String DESCRIPTION = "This is the elven king!";
74+
75+
@Override
76+
public String getDescription() {
77+
return DESCRIPTION;
78+
}
79+
}
80+
81+
public class ElfArmy implements Army {
82+
static final String DESCRIPTION = "This is the elven Army!";
83+
84+
@Override
85+
public String getDescription() {
86+
return DESCRIPTION;
87+
}
88+
}
89+
90+
// Orcish implementations similarly -> ...
91+
```
92+
93+
Then we have the abstraction and implementations for the kingdom factory.
94+
95+
```java
96+
public interface KingdomFactory {
97+
Castle createCastle();
98+
99+
King createKing();
100+
101+
Army createArmy();
102+
}
103+
104+
public class ElfKingdomFactory implements KingdomFactory {
105+
106+
@Override
107+
public Castle createCastle() {
108+
return new ElfCastle();
109+
}
110+
111+
@Override
112+
public King createKing() {
113+
return new ElfKing();
114+
}
115+
116+
@Override
117+
public Army createArmy() {
118+
return new ElfArmy();
119+
}
120+
}
121+
122+
// Orcish implementations similarly -> ...
123+
```
124+
125+
Now, we can design a factory for our different kingdom factories. In this example, we created `FactoryMaker`, responsible for returning an instance of either `ElfKingdomFactory` or `OrcKingdomFactory`. The client can use `FactoryMaker` to create the desired concrete factory which, in turn, will produce different concrete objects (derived from `Army`, `King`, `Castle`). In this example, we also used an enum to parameterize which type of kingdom factory the client will ask for.
126+
127+
```java
128+
public static class FactoryMaker {
129+
130+
public enum KingdomType {
131+
ELF, ORC
132+
}
133+
134+
public static KingdomFactory makeFactory(KingdomType type) {
135+
return switch (type) {
136+
case ELF -> new ElfKingdomFactory();
137+
case ORC -> new OrcKingdomFactory();
138+
};
139+
}
140+
}
141+
```
142+
143+
Here is the main function of our example application:
144+
145+
```java
146+
LOGGER.info("elf kingdom");
147+
createKingdom(Kingdom.FactoryMaker.KingdomType.ELF);
148+
LOGGER.info(kingdom.getArmy().getDescription());
149+
LOGGER.info(kingdom.getCastle().getDescription());
150+
LOGGER.info(kingdom.getKing().getDescription());
151+
152+
LOGGER.info("orc kingdom");
153+
createKingdom(Kingdom.FactoryMaker.KingdomType.ORC);
154+
LOGGER.info(kingdom.getArmy().getDescription());
155+
LOGGER.info(kingdom.getCastle().getDescription());
156+
LOGGER.info(kingdom.getKing().getDescription());
157+
```
158+
159+
The program output:
160+
161+
```
162+
07:35:46.340 [main] INFO com.iluwatar.abstractfactory.App -- elf kingdom
163+
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- This is the elven army!
164+
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- This is the elven castle!
165+
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- This is the elven king!
166+
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- orc kingdom
167+
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- This is the orc army!
168+
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- This is the orc castle!
169+
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- This is the orc king!
170+
```
171+
172+
## When to Use the Abstract Factory Pattern in Java
173+
174+
Use the Abstract Factory pattern in Java when:
175+
176+
* The system should be independent of how its products are created, composed, and represented.
177+
* You need to configure the system with one of multiple families of products.
178+
* A family of related product objects must be used together, enforcing consistency.
179+
* You want to provide a class library of products, exposing only their interfaces, not their implementations.
180+
* The lifetime of dependencies is shorter than the consumer's lifetime.
181+
* Dependencies need to be constructed using runtime values or parameters.
182+
* You need to choose which product to use from a family at runtime.
183+
* Adding new products or families should not require changes to existing code.
184+
185+
## Abstract Factory Pattern Java Tutorials
186+
187+
* [Abstract Factory Design Pattern in Java (DigitalOcean)](https://www.digitalocean.com/community/tutorials/abstract-factory-design-pattern-in-java)
188+
* [Abstract Factory(Refactoring Guru)](https://refactoring.guru/design-patterns/abstract-factory)
189+
190+
## Benefits and Trade-offs of Abstract Factory Pattern
191+
192+
Benefits:
193+
194+
* Flexibility: Easily switch between product families without code modifications.
195+
196+
* Decoupling: Client code only interacts with abstract interfaces, promoting portability and maintainability.
197+
198+
* Reusability: Abstract factories and products facilitate component reuse across projects.
199+
200+
* Maintainability: Changes to individual product families are localized, simplifying updates.
201+
202+
Trade-offs:
203+
204+
* Complexity: Defining abstract interfaces and concrete factories adds initial overhead.
205+
206+
* Indirectness: Client code interacts with products indirectly through factories, potentially reducing transparency.
207+
208+
## Real-World Applications of Abstract Factory Pattern in Java
209+
210+
* Java Swing's `LookAndFeel` classes for providing different look-and-feel options.
211+
* Various implementations in the Java Abstract Window Toolkit (AWT) for creating different GUI components.
212+
* [javax.xml.parsers.DocumentBuilderFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/parsers/DocumentBuilderFactory.html)
213+
* [javax.xml.transform.TransformerFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/transform/TransformerFactory.html#newInstance--)
214+
* [javax.xml.xpath.XPathFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathFactory.html#newInstance--)
215+
216+
## Related Java Design Patterns
217+
218+
* [Factory Method](https://java-design-patterns.com/patterns/factory-method/): Abstract Factory uses Factory Methods to create products.
219+
* [Singleton](https://java-design-patterns.com/patterns/singleton/): Abstract Factory classes are often implemented as Singletons.
220+
* [Factory Kit](https://java-design-patterns.com/patterns/factory-kit/): Similar to Abstract Factory but focuses on configuring and managing a set of related objects in a flexible way.
221+
222+
## References and Credits
223+
224+
* [Design Patterns: Elements of Reusable Object-Oriented Software](https://amzn.to/3w0pvKI)
225+
* [Design Patterns in Java](https://amzn.to/3Syw0vC)
226+
* [Head First Design Patterns: Building Extensible and Maintainable Object-Oriented Software](https://amzn.to/49NGldq)
227+
* [Java Design Patterns: A Hands-On Experience with Real-World Examples](https://amzn.to/3HWNf4U)

0 commit comments

Comments
 (0)