mirror of
https://github.com/tiennm99/java-design-patterns.git
synced 2026-05-15 18:59:10 +00:00
docs: update abstract factory
This commit is contained in:
Ilkka Seppälä
+59
-82
@@ -6,21 +6,25 @@ tag:
|
||||
- Abstraction
|
||||
- Decoupling
|
||||
- Gang of Four
|
||||
- Instantiation
|
||||
- Polymorphism
|
||||
---
|
||||
|
||||
## Also known as
|
||||
|
||||
Kit
|
||||
* Kit
|
||||
|
||||
## Intent
|
||||
|
||||
The Abstract Factory design pattern provides a way to create families of related objects without specifying their concrete classes. This allows for code that is independent of the specific classes of objects it uses, promoting flexibility and maintainability.
|
||||
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
|
||||
|
||||
## Explanation
|
||||
|
||||
Real-world example
|
||||
|
||||
> To create a kingdom we need objects with a common theme. The elven kingdom needs an elven king, elven castle, and elven army whereas the orcish kingdom needs an orcish king, orcish castle, and orcish army. There is a dependency between the objects in the kingdom.
|
||||
> Imagine a furniture company that produces 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.
|
||||
>
|
||||
> 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.
|
||||
|
||||
In plain words
|
||||
|
||||
@@ -32,6 +36,8 @@ Wikipedia says
|
||||
|
||||
**Programmatic Example**
|
||||
|
||||
To create a kingdom we need objects with a common theme. The elven kingdom needs an elven king, elven castle, and elven army whereas the orcish kingdom needs an orcish king, orcish castle, and orcish army. There is a dependency between the objects in the kingdom.
|
||||
|
||||
Translating the kingdom example above. First of all, we have some interfaces and implementation for the objects in the kingdom.
|
||||
|
||||
```java
|
||||
@@ -76,7 +82,6 @@ public class ElfArmy implements Army {
|
||||
}
|
||||
|
||||
// Orcish implementations similarly -> ...
|
||||
|
||||
```
|
||||
|
||||
Then we have the abstraction and implementations for the kingdom factory.
|
||||
@@ -108,44 +113,7 @@ public class ElfKingdomFactory implements KingdomFactory {
|
||||
}
|
||||
}
|
||||
|
||||
public class OrcKingdomFactory implements KingdomFactory {
|
||||
|
||||
@Override
|
||||
public Castle createCastle() {
|
||||
return new OrcCastle();
|
||||
}
|
||||
|
||||
@Override
|
||||
public King createKing() {
|
||||
return new OrcKing();
|
||||
}
|
||||
|
||||
@Override
|
||||
public Army createArmy() {
|
||||
return new OrcArmy();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Now we have the abstract factory that lets us make a family of related objects i.e. elven kingdom factory creates elven castle, king and army, etc.
|
||||
|
||||
```java
|
||||
var factory=new ElfKingdomFactory();
|
||||
var castle=factory.createCastle();
|
||||
var king=factory.createKing();
|
||||
var army=factory.createArmy();
|
||||
|
||||
castle.getDescription();
|
||||
king.getDescription();
|
||||
army.getDescription();
|
||||
```
|
||||
|
||||
Program output:
|
||||
|
||||
```java
|
||||
This is the elven castle!
|
||||
This is the elven king!
|
||||
This is the elven Army!
|
||||
// Orcish implementations similarly -> ...
|
||||
```
|
||||
|
||||
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.
|
||||
@@ -164,50 +132,62 @@ public static class FactoryMaker {
|
||||
};
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
public static void main(String[] args) {
|
||||
var app = new App();
|
||||
Here is the main function of our example application:
|
||||
|
||||
LOGGER.info("Elf Kingdom");
|
||||
app.createKingdom(FactoryMaker.makeFactory(KingdomType.ELF));
|
||||
LOGGER.info(app.getArmy().getDescription());
|
||||
LOGGER.info(app.getCastle().getDescription());
|
||||
LOGGER.info(app.getKing().getDescription());
|
||||
```java
|
||||
LOGGER.info("elf kingdom");
|
||||
createKingdom(Kingdom.FactoryMaker.KingdomType.ELF);
|
||||
LOGGER.info(kingdom.getArmy().getDescription());
|
||||
LOGGER.info(kingdom.getCastle().getDescription());
|
||||
LOGGER.info(kingdom.getKing().getDescription());
|
||||
|
||||
LOGGER.info("Orc Kingdom");
|
||||
app.createKingdom(FactoryMaker.makeFactory(KingdomType.ORC));
|
||||
--similar use of the orc factory
|
||||
}
|
||||
LOGGER.info("orc kingdom");
|
||||
createKingdom(Kingdom.FactoryMaker.KingdomType.ORC);
|
||||
LOGGER.info(kingdom.getArmy().getDescription());
|
||||
LOGGER.info(kingdom.getCastle().getDescription());
|
||||
LOGGER.info(kingdom.getKing().getDescription());
|
||||
```
|
||||
|
||||
The program output:
|
||||
|
||||
```
|
||||
07:35:46.340 [main] INFO com.iluwatar.abstractfactory.App -- elf kingdom
|
||||
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- This is the elven army!
|
||||
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- This is the elven castle!
|
||||
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- This is the elven king!
|
||||
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- orc kingdom
|
||||
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- This is the orc army!
|
||||
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- This is the orc castle!
|
||||
07:35:46.343 [main] INFO com.iluwatar.abstractfactory.App -- This is the orc king!
|
||||
```
|
||||
|
||||
## Class diagram
|
||||
|
||||
|
||||
|
||||
|
||||
## Applicability
|
||||
|
||||
Use the Abstract Factory pattern when
|
||||
Use the Abstract Factory pattern when:
|
||||
|
||||
* The system should be independent of how its products are created, composed, and represented
|
||||
* The system should be configured with one of the multiple families of products
|
||||
* The family of related product objects is designed to be used together, and you need to enforce this constraint
|
||||
* You want to provide a class library of products, and you want to reveal just their interfaces, not their implementations
|
||||
* The lifetime of the dependency is conceptually shorter than the lifetime of the consumer.
|
||||
* You need a run-time value to construct a particular dependency
|
||||
* You want to decide which product to call from a family at runtime.
|
||||
* You need to supply one or more parameters only known at run-time before you can resolve a dependency.
|
||||
* When you need consistency among products
|
||||
* You don’t want to change existing code when adding new products or families of products to the program.
|
||||
* The system should be independent of how its products are created, composed, and represented.
|
||||
* You need to configure the system with one of multiple families of products.
|
||||
* A family of related product objects must be used together, enforcing consistency.
|
||||
* You want to provide a class library of products, exposing only their interfaces, not their implementations.
|
||||
* The lifetime of dependencies is shorter than the consumer's lifetime.
|
||||
* Dependencies need to be constructed using runtime values or parameters.
|
||||
* You need to choose which product to use from a family at runtime.
|
||||
* Adding new products or families should not require changes to existing code.
|
||||
|
||||
Example use cases
|
||||
## Tutorials
|
||||
|
||||
* Selecting to call to the appropriate implementation of FileSystemAcmeService or DatabaseAcmeService or NetworkAcmeService at runtime.
|
||||
* Unit test case writing becomes much easier
|
||||
* UI tools for different OS
|
||||
* [Abstract Factory Design Pattern in Java (DigitalOcean)](https://www.digitalocean.com/community/tutorials/abstract-factory-design-pattern-in-java)
|
||||
* [Abstract Factory(Refactoring Guru)](https://refactoring.guru/design-patterns/abstract-factory)
|
||||
|
||||
## Consequences
|
||||
|
||||
Benefits
|
||||
Benefits:
|
||||
|
||||
* Flexibility: Easily switch between product families without code modifications.
|
||||
|
||||
@@ -217,32 +197,29 @@ Benefits
|
||||
|
||||
* Maintainability: Changes to individual product families are localized, simplifying updates.
|
||||
|
||||
Trade-offs
|
||||
Trade-offs:
|
||||
|
||||
* Complexity: Defining abstract interfaces and concrete factories adds initial overhead.
|
||||
|
||||
* Indirectness: Client code interacts with products indirectly through factories, potentially reducing transparency.
|
||||
|
||||
## Tutorials
|
||||
|
||||
* [Abstract Factory Pattern Tutorial](https://www.journaldev.com/1418/abstract-factory-design-pattern-in-java)
|
||||
* [Refactoring Guru - Abstract Factory](https://refactoring.guru/design-patterns/abstract-factory)
|
||||
|
||||
## Known uses
|
||||
|
||||
* Java Swing's `LookAndFeel` classes for providing different look-and-feel options.
|
||||
* Various implementations in the Java Abstract Window Toolkit (AWT) for creating different GUI components.
|
||||
* [javax.xml.parsers.DocumentBuilderFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/parsers/DocumentBuilderFactory.html)
|
||||
* [javax.xml.transform.TransformerFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/transform/TransformerFactory.html#newInstance--)
|
||||
* [javax.xml.xpath.XPathFactory](http://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathFactory.html#newInstance--)
|
||||
|
||||
## Related patterns
|
||||
|
||||
* [Factory Method](https://java-design-patterns.com/patterns/factory-method/)
|
||||
* [Factory Kit](https://java-design-patterns.com/patterns/factory-kit/)
|
||||
* [Factory Method](https://java-design-patterns.com/patterns/factory-method/): Abstract Factory uses Factory Methods to create products.
|
||||
* [Singleton](https://java-design-patterns.com/patterns/singleton/): Abstract Factory classes are often implemented as Singletons.
|
||||
* [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.
|
||||
|
||||
## Credits
|
||||
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](https://www.amazon.com/gp/product/0201633612/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0201633612&linkCode=as2&tag=javadesignpat-20&linkId=675d49790ce11db99d90bde47f1aeb59)
|
||||
* [Head First Design Patterns: A Brain-Friendly Guide](https://www.amazon.com/gp/product/0596007124/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0596007124&linkCode=as2&tag=javadesignpat-20&linkId=6b8b6eea86021af6c8e3cd3fc382cb5b)
|
||||
* [Java Design Patterns: A Hands-On Experience with Real-World Examples](https://amzn.to/3HWNf4U)
|
||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](https://amzn.to/3w0pvKI)
|
||||
* [Design Patterns in Java](https://amzn.to/3Syw0vC)
|
||||
*
|
||||
* [Head First Design Patterns: Building Extensible and Maintainable Object-Oriented Software](https://amzn.to/49NGldq)
|
||||
* [Java Design Patterns: A Hands-On Experience with Real-World Examples](https://amzn.to/3HWNf4U)
|
||||
|
||||
Reference in New Issue
Block a user