KapreSoft
From Coding to Cooking to Coins:
Antonio Lagnada's Blog on Software, Music, Food, and Finance
Antonio Lagnada's Blog on Software, Music, Food, and Finance
The Factory Pattern is a creational design pattern that provides an interface for creating objects in a superclass but allows subclasses to alter the type of objects that will be created. By following best practices in the implementation of the Factory Pattern, developers can achieve loose coupling, improved maintainability, and enhanced flexibility in their code.
The Factory Method Pattern is a cornerstone of the Factory Pattern, and it involves defining an interface for creating an object, but leaving the choice of its type to the subclasses, creation being deferred at the time of instantiation. This pattern is essential for promoting abstraction and reducing dependencies between classes.
abstract class Animal {
// Factory Method
abstract Animal createAnimal();
}
class Dog extends Animal {
@Override
Animal createAnimal() {
return new Dog();
}
}
class Cat extends Animal {
@Override
Animal createAnimal() {
return new Cat();
}
}
In this example, Animal is an abstract class that defines a factory method createAnimal. The subclasses Dog and Cat provide the implementation for this method, creating instances of Dog and Cat, respectively.
The Concrete Factory is a key component in the Factory Pattern. It is responsible for creating and returning instances of concrete products, which are objects that implement a specific product interface. The Concrete Factory relies on concrete products to carry out the required functionalities.
interface Product {
void display();
}
class ConcreteProductA implements Product {
@Override
public void display() {
System.out.println("ConcreteProductA");
}
}
class ConcreteProductB implements Product {
@Override
public void display() {
System.out.println("ConcreteProductB");
}
}
class ConcreteFactory {
public Product createProduct(String type) {
if (type.equalsIgnoreCase("A")) {
return new ConcreteProductA();
} else if (type.equalsIgnoreCase("B")) {
return new ConcreteProductB();
}
return null;
}
}
In this example, Product is an interface that defines the method display. ConcreteProductA and ConcreteProductB are classes that implement this interface, providing their own version of the display method. ConcreteFactory is a class that contains a method createProduct, which returns instances of ConcreteProductA or ConcreteProductB based on the input parameter.
When creating factory methods or classes, it is crucial to follow a consistent naming convention that clearly indicates the purpose of the method or class.
Using consistent naming conventions is essential for readability and maintainability of code. Here’s an example that illustrates the importance of this best practice:
interface Shape {
void draw();
}
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing Circle");
}
}
class Square implements Shape {
@Override
public void draw() {
System.out.println("Drawing Square");
}
}
class ShapeMaker {
public Shape getShape(String shapeType) {
if (shapeType.equalsIgnoreCase("circle")) {
return new Circle();
} else if (shapeType.equalsIgnoreCase("square")) {
return new Square();
}
return null;
}
}
In this example, the ShapeMaker class could be named more consistently to indicate that it is a factory class, for instance, ShapeFactory.
interface Shape {
void draw();
}
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing Circle");
}
}
class Square implements Shape {
@Override
public void draw() {
System.out.println("Drawing Square");
}
}
class ShapeFactory {
public Shape createShape(String shapeType) {
if (shapeType.equalsIgnoreCase("circle")) {
return new Circle();
} else if (shapeType.equalsIgnoreCase("square")) {
return new Square();
}
return null;
}
}
In this improved example, the ShapeMaker class is renamed to ShapeFactory and the getShape method is renamed to createShape to clearly indicate that it is a factory class responsible for creating Shape instances. This makes the code more understandable and maintainable.
One of the significant advantages of the Factory Pattern is that it promotes loose coupling between classes. Developers should strive to minimize dependencies between different parts of the code.
Loose coupling is a design principle aimed at reducing the inter-dependencies between different parts of a system to increase robustness and maintainability. Here is an example to illustrate the application of loose coupling in the Factory Pattern:
In the following example, the client code is tightly coupled with the concrete implementations of the Shape interface.
interface Shape {
void draw();
}
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing Circle");
}
}
class Square implements Shape {
@Override
public void draw() {
System.out.println("Drawing Square");
}
}
class Client {
public static void main(String[] args) {
Circle circle = new Circle();
circle.draw();
Square square = new Square();
square.draw();
}
}
Here, the Client class is directly creating instances of Circle and Square, which makes it tightly coupled with these concrete implementations.
Now, let’s apply the Factory Pattern to achieve loose coupling:
interface Shape {
void draw();
}
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing Circle");
}
}
class Square implements Shape {
@Override
public void draw() {
System.out.println("Drawing Square");
}
}
class ShapeFactory {
public Shape createShape(String shapeType) {
if (shapeType.equalsIgnoreCase("circle")) {
return new Circle();
} else if (shapeType.equalsIgnoreCase("square")) {
return new Square();
}
return null;
}
}
class Client {
public static void main(String[] args) {
ShapeFactory shapeFactory = new ShapeFactory();
Shape circle = shapeFactory.createShape("circle");
circle.draw();
Shape square = shapeFactory.createShape("square");
square.draw();
}
}
In this improved example, the Client class is not directly dependent on the concrete implementations of Shape (Circle and Square). Instead, it relies on the ShapeFactory to create instances of Shape. This decouples the client code from the concrete implementations, making the system more flexible and maintainable.
Each factory method or class should have a single responsibility, and it should not be overloaded with multiple tasks.
The Single Responsibility Principle (SRP) is one of the five SOLID principles of object-oriented design and programming. It states that a class should have only one reason to change. Here’s an example to illustrate the adherence to the Single Responsibility Principle in a Factory Pattern:
In the following example, the ShapeFactory class has multiple responsibilities, making it overloaded with tasks.
interface Shape {
void draw();
}
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing Circle");
}
}
class Square implements Shape {
@Override
public void draw() {
System.out.println("Drawing Square");
}
}
class ShapeFactory {
public Shape createShape(String shapeType) {
if (shapeType.equalsIgnoreCase("circle")) {
return new Circle();
} else if (shapeType.equalsIgnoreCase("square")) {
return new Square();
}
return null;
}
public void drawShape(Shape shape) {
shape.draw();
}
}
Here, the ShapeFactory class is responsible for creating shapes and also drawing them. This violates the Single Responsibility Principle.
Now, let’s refactor the code to adhere to the Single Responsibility Principle:
interface Shape {
void draw();
}
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing Circle");
}
}
class Square implements Shape {
@Override
public void draw() {
System.out.println("Drawing Square");
}
}
class ShapeFactory {
public Shape createShape(String shapeType) {
if (shapeType.equalsIgnoreCase("circle")) {
return new Circle();
} else if (shapeType.equalsIgnoreCase("square")) {
return new Square();
}
return null;
}
}
class ShapeDrawer {
public void drawShape(Shape shape) {
shape.draw();
}
}
In this improved example, we have separated the responsibility of drawing shapes from the ShapeFactory class and created a new class ShapeDrawer specifically for that purpose. Now, the ShapeFactory class has a single responsibility of creating shapes, and the ShapeDrawer class has a single responsibility of drawing shapes. This makes the system more maintainable and flexible.
Utilize abstraction to create a clear separation between the client code and the object creation process. This enhances flexibility and allows for easier maintenance.
Leveraging abstraction in the Factory Pattern helps to create a clear separation between the client code and the object creation process, providing greater flexibility and ease of maintenance. Here’s an example to illustrate this concept:
class Circle {
void draw() {
System.out.println("Drawing Circle");
}
}
class Square {
void draw() {
System.out.println("Drawing Square");
}
}
class ShapeFactory {
Object createShape(String shapeType) {
if (shapeType.equalsIgnoreCase("circle")) {
return new Circle();
} else if (shapeType.equalsIgnoreCase("square")) {
return new Square();
}
return null;
}
}
class Client {
public static void main(String[] args) {
ShapeFactory shapeFactory = new ShapeFactory();
Circle circle = (Circle) shapeFactory.createShape("circle");
circle.draw();
Square square = (Square) shapeFactory.createShape("square");
square.draw();
}
}
In this example, the ShapeFactory class returns Object type, and the client code needs to cast the result to the correct type. This is not ideal because it introduces potential runtime errors and reduces flexibility.
interface Shape {
void draw();
}
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing Circle");
}
}
class Square implements Shape {
@Override
public void draw() {
System.out.println("Drawing Square");
}
}
class ShapeFactory {
public Shape createShape(String shapeType) {
if (shapeType.equalsIgnoreCase("circle")) {
return new Circle();
} else if (shapeType.equalsIgnoreCase("square")) {
return new Square();
}
return null;
}
}
class Client {
public static void main(String[] args) {
ShapeFactory shapeFactory = new ShapeFactory();
Shape circle = shapeFactory.createShape("circle");
circle.draw();
Shape square = shapeFactory.createShape("square");
square.draw();
}
}
In this improved example, we’ve introduced the Shape interface, and both Circle and Square implement this interface. The ShapeFactory class now returns instances of the Shape interface, eliminating the need for casting in the client code. This provides a clear separation between the client code and the object creation process, enhancing flexibility and ease of maintenance.
Design the factory pattern in a way that makes it easy to add new subclasses or concrete products in the future without significant changes to the existing code.
One of the key advantages of the Factory Pattern is its ability to facilitate extensibility. By designing the Factory Pattern in a way that minimizes the impact on existing code when adding new subclasses or concrete products, we can achieve greater flexibility and ease of maintenance. Here’s an example to illustrate how to optimize for extensibility:
interface Shape {
void draw();
}
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing Circle");
}
}
class Square implements Shape {
@Override
public void draw() {
System.out.println("Drawing Square");
}
}
class ShapeFactory {
public Shape createShape(String shapeType) {
if (shapeType.equalsIgnoreCase("circle")) {
return new Circle();
} else if (shapeType.equalsIgnoreCase("square")) {
return new Square();
}
throw new IllegalArgumentException("Unknown shape type: " + shapeType);
}
}
In this example, if we want to add a new shape, we would have to modify the ShapeFactory class to include a new conditional branch for the new shape. This is not ideal as it violates the Open/Closed Principle, which states that a class should be open for extension but closed for modification.
interface Shape {
void draw();
}
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing Circle");
}
}
class Square implements Shape {
@Override
public void draw() {
System.out.println("Drawing Square");
}
}
interface ShapeFactory {
Shape createShape();
}
class CircleFactory implements ShapeFactory {
@Override
public Shape createShape() {
return new Circle();
}
}
class SquareFactory implements ShapeFactory {
@Override
public Shape createShape() {
return new Square();
}
}
In this improved example, we have created an ShapeFactory interface with a createShape method. For each shape, we have a separate factory class (CircleFactory and SquareFactory) that implements the ShapeFactory interface. This design makes it easy to add new shapes in the future without modifying the existing code. To add a new shape, we simply create a new factory class for the new shape and have it implement the ShapeFactory interface. This achieves greater extensibility while adhering to the Open/Closed Principle.
Another example is extending the ShapeFactory, so we can leverage Spring’s ability to inject a collection of beans to dynamically build our ShapeFactory. This provides a very flexible and extensible way to manage our shapes, as adding a new shape is as simple as adding a new bean. Here’s how we can define our ShapeFactory with Spring Framework:
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class ShapeConfig {
@Bean
public Shape circleShape() {
return new Circle();
}
@Bean
public Shape squareShape() {
return new Square();
}
@Bean
public ShapeFactory shapeFactory(Map<String, Shape> availableShapes) {
return new ShapeFactory() {
@Override
public Shape createShape(String shapeType) {
if (availableShapes.containsKey(shapeType)) {
return availableShapes.get(shapeType);
}
throw new IllegalArgumentException("Unknown shape type: " + shapeType);
}
};
}
}
In this example, circleShape and squareShape are defined as beans that return instances of Circle and Square, respectively. The shapeFactory bean takes a Map of String to Shape as a parameter, which Spring will automatically populate with all beans of type Shape, using their bean names as keys.
The createShape method of ShapeFactory then simply looks up the shape type in the map and returns the corresponding Shape instance. This approach allows us to add new shapes in the future simply by adding new beans, without having to modify the shapeFactory bean definition.
The factory pattern should provide a consistent way of creating objects, ensuring that all instances are created following the defined rules and guidelines.
Ensuring consistency in object creation is crucial to maintaining the integrity and reliability of the application. Here’s an example to illustrate the importance of consistency in object creation using the Factory Pattern:
interface Shape {
void draw();
}
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing Circle");
}
}
class Square implements Shape {
@Override
public void draw() {
System.out.println("Drawing Square");
}
}
class ShapeFactory {
public Shape createShape(String shapeType, boolean fill) {
Shape shape = null;
if (shapeType.equalsIgnoreCase("circle")) {
shape = new Circle();
} else if (shapeType.equalsIgnoreCase("square")) {
shape = new Square();
}
// Inconsistent object creation
if (fill) {
// Some additional steps to fill the shape
System.out.println("Filling the shape");
}
return shape;
}
}
In this example, the ShapeFactory class has a createShape method that takes an additional parameter fill to determine whether the shape should be filled. However, this approach is inconsistent because the filling process is handled within the factory method, which should primarily be responsible for object creation.
interface Shape {
void draw();
void fill();
}
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing Circle");
}
@Override
public void fill() {
System.out.println("Filling Circle");
}
}
class Square implements Shape {
@Override
public void draw() {
System.out.println("Drawing Square");
}
@Override
public void fill() {
System.out.println("Filling Square");
}
}
class ShapeFactory {
public Shape createShape(String shapeType) {
if (shapeType.equalsIgnoreCase("circle")) {
return new Circle();
} else if (shapeType.equalsIgnoreCase("square")) {
return new Square();
}
throw new IllegalArgumentException("Unknown shape type: " + shapeType);
}
}
In this improved example, we have defined a fill method in the Shape interface, and each concrete shape class (Circle and Square) implements this method. The ShapeFactory class is now only responsible for creating objects, ensuring a consistent way of object creation. The decision to fill the shape or not is left to the client code, which can call the fill method on the created object if needed. This approach ensures consistency in object creation and adheres to the Single Responsibility Principle.
In this comprehensive guide, we’ve delved deep into the intricacies of the Factory Pattern, one of the fundamental creational design patterns that plays a pivotal role in software development. By adhering to best practices such as consistent naming conventions, applying loose coupling, and optimizing for extensibility, developers can harness the full potential of the Factory Pattern to create flexible and maintainable code.
Key takeaways from this article include the importance of adhering to the Single Responsibility Principle, leveraging abstraction to create a clear separation between client code and object creation, and ensuring consistency in object creation. Each of these best practices contributes to a robust implementation of the Factory Pattern that stands the test of time and evolves with the ever-changing landscape of software development.
Furthermore, we’ve explored how the integration of modern frameworks like Spring can significantly enhance the Factory Pattern, providing powerful tools and features that simplify the configuration and management of factory classes. The examples provided illustrate the seamless transition from a traditional implementation of the Factory Pattern to a Spring-powered configuration that takes advantage of Java-based configuration and dependency injection.
In conclusion, the Factory Pattern is a versatile and essential tool in a developer’s arsenal. By following the best practices and insights provided in this article, developers can create code that is not only functional and efficient but also clean, maintainable, and ready to adapt to future changes. The Factory Pattern, when properly implemented, lays a solid foundation for building scalable and flexible software applications that stand the test of time.