Creational design patterns are responsible for efficient object creation which increases the flexibility and reuseability of existing code.
Factory Method Pattern
Problem - you want to create an object but you don’t know beforehand the exact type of the object your code should work with. You want to pass customisable objects to code that does not care about the details of that object, just that it implements the interface it expects. Say you have a company that delivers products by Truck. After a while your products become more popular so you want to start delivering by Ship. If you add other transportation types, your code could become more riddled with conditionals that switch the app’s behaviour depending on the class of transportation objects.
Solution - the factory method design pattern is used by first defining a separate operation, a factory method, for creating an object (called in this context a product),and then using this factory method by calling it to create the object. This enables writing of subclasses that decide how a parent object is created and what type of objects the parents contains. The factory method separates the product construction code from the code that actually uses the product. Therefore it’s easier to extend product construction code independently from the rest of the code.
Refactoring Guru
Factory Method Design Pattern
Factory method pattern - Wikipedia
The Abstract Factory Pattern
Problem - your code needs to work with various families of related products, but you dont want it to depend on the concrete classes of those products. The factory method constructs a single object and the abstract factory constructs multiple objects. It provides an interface for creating families of related or dependent objects without specifying their concrete classes.
Solution - declare interfaces for your different products and create concrete classes that follow these interfaces. Next declare an abstract factory interface and then concrete factories that implement this interface. Eg you have an MacFactory what will only create Mac products and a WindowsFactory that will only create Windows products.
The Builder Pattern
Problem - you need to create an object that has many optional and required fields. You can build a complex object step by step.
Solution - create a builder class that has different methods for each of the fields in the object you want to create and build your object step by step. The same builder can create different representations of the required object.
The Prototype Pattern
Problem - you want to create an exact copy of an object but some of the object’s fields may be private and not visible from the outside of the object itself. There are numerous potential classes that you want to use only if needed at runtime
Solution - the prototype pattern delegates the cloning process to the actual objects that are being cloned. The pattern declares a common interface for all objects that support cloning. This interface lets you clone an object without coupling your code to the class of that object. Usually that interface contains just a single clone method. An object that supports cloning is called a prototype. When your objects have dozens of fields and hundreds of possible configurations, cloning them might serve as an alternative to subclassing.
The Singleton Pattern
Problem - you have information that needs to be shared in different parts of your application and your application needs one, and only one instance and you need to provide a global point of access to it.
Solution - the singleton pattern creates one single object that is shared around different resources in your application. It contains stored state that is global to your entire application. However, it can make testing difficult and creates coupling in different parts of your application.
Latest comments (0)