Factory pattern JS

Factory Pattern

The Factory pattern js it is one more creational pattern which concerned with creating different objects. The most important difference between this pattern and the others is that you no longer need to use the constructor. Instead of the usual methods, the pattern can provide a generic interface for creation. In result, we have an opportunity to select a type of factory object by ourselves.

Could you imagine an ability to have a user interface for developing a type of such component? You need to program a F obj. to construct a new constituent element and you don’t have to make it by applying another constructing machine or operator. We specify settings (the sort of object, e.g “Panel”), and the program instantiates what we have ordered.
This peculiarity will be useful if the creation is rather complex.

// Types.js - Constructors used behind the scenes
// A constructor for defining new cars
function Car( options ) {
  // some defaults
  this.doors = options.doors || 4;
  this.state = options.state || "brand new";
  this.color = options.color || "silver";
// A constructor for defining new trucks
function Truck( options){
  this.state = options.state || "used";
  this.wheelSize = options.wheelSize || "large";
  this.color = options.color || "blue";
// FactoryExample.js
// Define a skeleton vehicle factory
function VehicleFactory() {}
// Define the prototypes and utilities for this factory
// Our default vehicleClass is Car
VehicleFactory.prototype.vehicleClass = Car;
// Our Factory method for creating new Vehicle instances
VehicleFactory.prototype.createVehicle = function ( options ) {
    case "car":
      this.vehicleClass = Car;
    case "truck":
      this.vehicleClass = Truck;
    //defaults to VehicleFactory.prototype.vehicleClass (Car)
  return new this.vehicleClass( options );
// Create an instance of our factory that makes cars
var carFactory = new VehicleFactory();
var car = carFactory.createVehicle( {
            vehicleType: "car",
            color: "yellow",
            doors: 6 } );
// Test to confirm our car was created using the vehicleClass/prototype Car
// Outputs: true
console.log( car instanceof Car );
// Outputs: Car object of color "yellow", doors: 6 in a "brand new" state
console.log( car );

Users interface libraries such as Ext JS can be a great example of this pattern. There, the object creating methods could be divided into subclasses. An example that you could see, builds upon our previous snippets uses the Constructor pattern logic to determine cars.

The Factory Patter in JavaScript should be applied:

  • In these situations The Factory Pattern is particularly useful;
  • In case of a high level of complexity included in the object or component setup;
  • In case of necessity to generate different instances of objects easily, considering the environment in which we are;
  • During the work that includes many tiny objects or components that share the same properties;

When you create objects by instances of other objects that must be satisfied an API contract (as known as duck typing) to work. This can be of use for decoupling.

The FP shouldn’t be applied:

This pattern can brought a lot of difficulties to a pattern, if it is applied to inappropriate problem. So to prevent an overhead, is better to stick certain constructors, if the interface for object creation is a main goal for the library we are writing.
If we pay more attention to the fact that the object creation process is abstracted behind an interface, we can see that it may cause problems with unit testing depending on how complicated this process can be.
Abstract Factories
Be familiar with the AF pattern is also important. It’s main purpose to encapsulate a group of individual factories with a common goal. It works in a way that would separate the details of implementation of a set from their general usage.
We should apply an AF among the systems which are not depending on from the method the objects it creates are generated or it needs to work with different types of objects.