



What is Abstract Factory design pattern?





The intent or definition of Abstract Factory is





“ Provide an interface for creating families of related or dependent objects without specifying their concrete classes ”





It is kind of an obscure definition, in order to understand it we need to break it into meaningful pieces.











1. " Provide an interface "





When we talk about Abstract Factory we talk about interface not abstract class , Basically this design pattern gives us an Interface, like Interface in Java, C# , Typescript (abstract class).





Why interface? Whenever we talk about any design pattern, it emphasizes more on how we are going to use it rather than implement it.





Interface is always the right type to prefer because concrete class creates tight coupling whereas an interface isolates it from the rest of the system. At runtime we can get different solution, without updating our code.





For example





interface SecurityFactory { AuthenticationManager getAuthenticationManager (); AuthorizationManager getAuthorizationManager (); }





Here we have an Abstract factory which defines behaviour of creating objects related to application security, like Authentication & Authorization.



Here we can have different authentication schemes like Basic , Bearer or Digest and authorization like simple or JWT .



Our client code does not care about what implementation we are using, it just uses interfaces from Abstract Factory to execute security related operations









2. “ for creating families of related or dependent objects ”





The second part states that Abstract Factory aka interface creates objects.

Interfaces contain methods and each method should return an object.





AuthenticationManager getAuthenticationManager (); AuthorizationManager getAuthorizationManager ();





When we call these methods we get instances of security objects which are related to a context, here context is security.









3. “ without specifying their concrete classes ”





Last part of definition states that the return type of each abstract method is an interface not a concrete class .





It makes complete scenes as Abstract Factory is itself an interface and the return type of each of its methods should be an interface. This allows clients to get different types of objects from Abstract Factory without updating anything on the client side.





For example when I use SecurityFactory like this





public TestApp (SecurityFactory securityFactory ) { AuthorizationManager authorizationManager = securityFactory. getAuthorizationManager (); if (authorizationManager. isLoggedIn ()){ // allow user to access resource } else { // notify unauthorized user } }





Here object authorizationManager can represent any kind of authorization model, like basic authorization or JWT or session based authorization.





Here we don’t need to change anything on this client side to have different authorization behaviour rather add different securityFactory dependency at runtime.





Another example would be as follow





void AuthenticateUser (String username, String password){ AuthenticationManager authManager = securityFactory. getAuthenticationManager (); if (authManager. authenticate (username, password) == true ){ // User is authenticated } else { // Invalid User } }





Here authentication model could be anything, BASIC authentication or custom.

This implementation will not impact the client code, it only knows about the interface, not its implementation.





Only thing which will be changed inside your application will be assigning concrete implementations of SecurityFactory. This can be done using dependency injection.









Benefits:





Every application requires n number of objects and creational method of these objects could be different, some developer prefer new keyword to instantiate object or other prefer dependency injection like singleton . Earlier approach create tight coupling which is hard to test and later is hard to manage and can create verbose constructor.





When we group all related objects of application together, we get only a few abstract factories which are easy to manage and maintain in the entire application.





AbstractFactory is easy to test, we can create mock objects and test application behaviour easily.





AbstractFactory follows the Open/Close principle. We can change the behaviour of an application without updating any client code.





Example :



Security Abstract Factory link

Security Abstract Factory Implementation link





Conclusion:



It is a creational pattern to create a set of related objects. Object should not be created using new keyword which is hard to manage and test rather we encapsulate it inside creational patterns and Abstract Factory is a good place to create related objects and it has large scope inside application.





Please let me know what are your thoughts about this pattern and how you use it inside your application.



