* Updated saga to JUnit 5 * Update fix for CI job in trampoline module * Updated update-method module to JUnit 5 * Upgraded to latest JUnit Jupiter JUnit 4 is not needed when using JUnit-Vintage * Reverted change to access modifier on Trampoline * Cleanup to resolve code smells * Formatting * Formatting * Migrating to JUnit5 and updating some Mockito patterns * Migrating to JUnit5 * Migrating to JUnit5 * Migrating to JUnit 5 * Formatting cleanup * Added missing scope for junit * Fixed tests that were not running previously. Co-authored-by: Subhrodip Mohanta <hello@subho.xyz>
layout, title, folder, permalink, categories, tags
layout | title | folder | permalink | categories | tags | |
---|---|---|---|---|---|---|
pattern | Factory | factory | /patterns/factory/ | Creational |
|
Also known as
- Simple Factory
- Static Factory Method
Intent
Providing a static method encapsulated in a class called factory, in order to hide the implementation logic and makes client code focus on usage rather then initialization new objects.
Explanation
Real world example
Lets say we have a web application connected to SQLServer, but now we want to switch to Oracle. To do so without modifying existing source code, we need to implements Simple Factory pattern, in which a static method can be invoked to create connection to a given database.
Wikipedia says
Factory is an object for creating other objects – formally a factory is a function or method that returns objects of a varying prototype or class.
Programmatic Example
We have an interface Car
and two implementations Ford
and Ferrari
.
public interface Car {
String getDescription();
}
public class Ford implements Car {
static final String DESCRIPTION = "This is Ford.";
@Override
public String getDescription() {
return DESCRIPTION;
}
}
public class Ferrari implements Car {
static final String DESCRIPTION = "This is Ferrari.";
@Override
public String getDescription() {
return DESCRIPTION;
}
}
Enumeration above represents types of cars that we support (Ford
and Ferrari
).
public enum CarType {
FORD(Ford::new),
FERRARI(Ferrari::new);
private final Supplier<Car> constructor;
CarType(Supplier<Car> constructor) {
this.constructor = constructor;
}
public Supplier<Car> getConstructor() {
return this.constructor;
}
}
Then we have the static method getCar
to create car objects encapsulated in the factory class
CarsFactory
.
public class CarsFactory {
public static Car getCar(CarType type) {
return type.getConstructor().get();
}
}
Now on the client code we can create different types of cars using the factory class.
var car1 = CarsFactory.getCar(CarType.FORD);
var car2 = CarsFactory.getCar(CarType.FERRARI);
LOGGER.info(car1.getDescription());
LOGGER.info(car2.getDescription());
Program output:
This is Ford.
This Ferrari.
Class Diagram
Applicability
Use the Simple Factory pattern when you only care about the creation of a object, not how to create and manage it.
Pros
- Allows keeping all objects creation in one place and avoid of spreading 'new' keyword across codebase.
- Allows to write loosely coupled code. Some of its main advantages include better testability, easy-to-understand code, swappable components, scalability and isolated features.
Cons
- The code becomes more complicated than it should be.
Real world examples
- java.util.Calendar#getInstance()
- java.util.ResourceBundle#getBundle()
- java.text.NumberFormat#getInstance()
- java.nio.charset.Charset#forName()
- java.net.URLStreamHandlerFactory#createURLStreamHandler(String) (Returns different singleton objects, depending on a protocol)
- java.util.EnumSet#of()
- javax.xml.bind.JAXBContext#createMarshaller() and other similar methods.