{"id":54,"date":"2020-04-22T15:07:09","date_gmt":"2020-04-22T15:07:09","guid":{"rendered":"https:\/\/cebucodesolutions.com\/blog\/?p=54"},"modified":"2020-04-22T15:07:12","modified_gmt":"2020-04-22T15:07:12","slug":"javascript-design-patterns","status":"publish","type":"post","link":"https:\/\/cebucodesolutions.com\/blog\/2020\/04\/22\/javascript-design-patterns\/","title":{"rendered":"JavaScript Design Patterns"},"content":{"rendered":"\n

The ultimate guide to the most useful design patterns<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

UPDATE NOTE:<\/strong> Updated the Proxy Pattern example to use ES6 Proxy and Reflect. Replaced images of source code snippets with GitHub<\/strong> gists. <\/p>\n\n\n\n

In\n this article, we are going to talk about design patterns that can be \nand should be used to write better, maintainable JavaScript code. I \nassume you have a basic understanding of JavaScript and concepts like \nclasses (classes in JavaScript can be tricky), objects, prototypal \ninheritance, closures, etc.<\/p>\n\n\n\n

<\/p>\n\n\n\n

This article is a long read as a whole because of the nature of the subject matter, so I have tried to keep the sections self-contained. So you as a reader can pick and choose specific parts (or, in this case, specific patterns) and ignore the ones you are not interested in or are well versed with. Now, let\u2019s get started.<\/p>\n\n\n\n

Note:<\/strong> Source code for the implementation of all the design patterns explained here is on GitHub<\/strong><\/a>. <\/p>\n\n\n\n

Introduction<\/h1>\n\n\n\n

We write code to solve problems. These problems usually have many similarities, and, when trying to solve them, we notice several common patterns. This is where design patterns come in.<\/p>\n\n\n\n

A design pattern<\/strong> is a term used in software engineering for a general, reusable solution to a commonly occurring problem in software design. <\/p>\n\n\n\n

The underlying concept of design patterns has been around in the software engineering industry since the very beginning, but they weren\u2019t really so formalised. Design Patterns: Elements Of Reusable Object-Oriented Software<\/strong><\/a> written by Erich Gamma, Richard Helm, Ralph Johnson<\/strong>,and John Vlissides<\/strong> \u2014 the famous Gang of Four (GoF)\u2014was instrumental in pushing the formalised concept of design patterns in software engineering. Now, design patterns are an essential part of software development and have been so for a long time. <\/p>\n\n\n\n

There were 23 design patterns introduced in the original book. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Design\n patterns are beneficial for various reasons. They are proven solutions \nthat industry veterans have tried and tested. They are solid approaches \nthat solve issues in a widely accepted way and reflect the experience \nand insights of the industry-leading developers that helped define them.\n Patterns also make your code more reusable and readable while speeding \nup the development process vastly.<\/p>\n\n\n\n

Design patterns are by no means finished solutions. They only provide us with approaches or schemes to solve a problem.<\/p>\n\n\n\n

Note:<\/strong>\n In this article, we will mainly talk about design patterns from an \nobject-oriented point of view and in the context of their usability in \nmodern JavaScript. That is why many classic patterns from GoF may be \nomitted, and some modern patterns from sources like Addy Osmani\u2019s Learn JavaScript Design Patterns<\/strong><\/a>\n will be included. The examples are kept simple for easier understanding\n and are hence not the most optimised implementation of their respective\n design patterns.<\/p><\/blockquote>\n\n\n\n

\n\n\n\n

Categories of Design Patterns<\/h1>\n\n\n\n

Design patterns are usually categorized into three major groups.<\/p>\n\n\n\n

Creational Design Patterns<\/h2>\n\n\n\n

As\n the name suggests, these patterns are for handling object creational \nmechanisms. A creational design pattern basically solves a problem by \ncontrolling the creation process of an object.<\/p>\n\n\n\n

We will discuss the following patterns in detail: Constructor Pattern, Factory Pattern, Prototype Pattern, <\/em><\/strong>and Singleton Pattern.<\/em><\/strong><\/p>\n\n\n\n

Structural Design Patterns<\/h2>\n\n\n\n

These patterns are concerned with class and object composition. They help structure or restructure one or more parts without affecting the entire system. In other words, they help obtain new functionalities without tampering with the existing ones.<\/p>\n\n\n\n

We will discuss the following patterns in detail: Adapter Pattern, Composite Pattern, Decorator Pattern, Fa\u00e7ade Pattern, Flyweight Pattern, <\/em><\/strong>and Proxy Pattern.<\/em><\/strong><\/p>\n\n\n\n

Behavioral Design Patterns<\/h2>\n\n\n\n

These patterns are concerned with improving communication between dissimilar objects.<\/p>\n\n\n\n

We will discuss the following patterns in detail: Chain of Responsibility Pattern, Command Pattern, Iterator Pattern, Mediator Pattern, Observer Pattern, State Pattern, Strategy Pattern, <\/em><\/strong>and Template Pattern.<\/em><\/strong><\/p>\n\n\n\n

Constructor Pattern<\/h1>\n\n\n\n

This\n is a class-based creational design pattern. Constructors are special \nfunctions that can be used to instantiate new objects with methods and \nproperties defined by that function.<\/p>\n\n\n\n

It\n is not one of the classic design patterns. In fact, it is more of a \nbasic language construct than a pattern in most object-oriented \nlanguages. But in JavaScript, objects can be created on the fly without \nany constructor functions or \u201cclass\u201d definition. Therefore, I think it \nis important to lay down the foundation for other patterns to come with \nthis simple one.<\/p>\n\n\n\n

Constructor pattern is one of the most commonly used patterns in JavaScript for creating new objects of a given kind.<\/p>\n\n\n\n

In this example, we define a Hero<\/code> class with attributes like name<\/code> and specialAbility<\/code> and methods like getDetails<\/code>. Then, we instantiate an object IronMan<\/code> by invoking the constructor method with the new<\/code> keyword passing in the values for the respective attributes as arguments.<\/p>\n\n\n\n

\/\/ traditional Function-based syntax
\nfunction Hero(name, specialAbility) {
\n \/\/ setting property values
\n this.name = name;
\n this.specialAbility = specialAbility;<\/p>\n\n\n\n

\/\/ declaring a method on the object
\n this.getDetails = function() {
\n return this.name + ‘ can ‘ + this.specialAbility;
\n };
\n}<\/p>\n\n\n\n

\/\/ ES6 Class syntax
\nclass Hero {
\n constructor(name, specialAbility) {
\n \/\/ setting property values
\n this._name = name;
\n this._specialAbility = specialAbility;<\/p>\n\n\n\n

\/\/ declaring a method on the object\nthis.getDetails = function() {\n  return `${this._name} can ${this._specialAbility}`;\n};<\/code><\/pre>\n\n\n\n
}
\n}<\/p>\n\n\n\n
\/\/ creating new instances of Hero
\nconst IronMan = new Hero(‘Iron Man’, ‘fly’);<\/p>\n\n\n\n
console.log(IronMan.getDetails()); \/\/ Iron Man can fly<\/p>\n\n\n\n
Factory Pattern<\/h1>\n\n\n\n
Factory\n pattern is another class-based creational pattern. In this, we provide a\n generic interface that delegates the responsibility of object \ninstantiation to its subclasses.<\/p>\n\n\n\n
This\n pattern is frequently used when we need to manage or manipulate \ncollections of objects that are different yet have many similar \ncharacteristics.<\/p>\n\n\n\n
In this example, we create a factory class named BallFactory<\/code>  that has a method that takes in parameters, and, depending on the  parameters, it delegates the object instantiation responsibility to the  respective class. If the type parameter is \"football\"<\/code> or \"soccer\"<\/code> object instantiation is handled by Football<\/code> class, but if it is \"basketball\"<\/code> object instantiation is handled by Basketball<\/code> class.<\/p>\n\n\n\n
class BallFactory {
\n  constructor() {
\n    this.createBall = function(type) {
\n      let ball;
\n      if (type === ‘football’ || type === ‘soccer’) ball = new Football();
\n      else if (type === ‘basketball’) ball = new Basketball();
\n      ball.roll = function() {
\n        return The ${this._type} is rolling.<\/code>;
\n      };<\/p>\n\n\n\n
  return ball;\n};<\/code><\/pre>\n\n\n\n
}
\n}<\/p>\n\n\n\n
class Football {
\n  constructor() {
\n    this._type = ‘football’;
\n    this.kick = function() {
\n      return ‘You kicked the football.’;
\n    };
\n  }
\n}<\/p>\n\n\n\n
class Basketball {
\n  constructor() {
\n    this._type = ‘basketball’;
\n    this.bounce = function() {
\n      return ‘You bounced the basketball.’;
\n    };
\n  }
\n}<\/p>\n\n\n\n
\/\/ creating objects
\nconst factory = new BallFactory();<\/p>\n\n\n\n
const myFootball = factory.createBall(‘football’);
\nconst myBasketball = factory.createBall(‘basketball’);<\/p>\n\n\n\n
console.log(myFootball.roll()); \/\/ The football is rolling.
 console.log(myBasketball.roll()); \/\/ The basketball is rolling.
 console.log(myFootball.kick()); \/\/ You kicked the football.
 console.log(myBasketball.bounce()); \/\/ You bounced the basketball.<\/p>\n\n\n\n
Prototype Pattern<\/h1>\n\n\n\n
This\n pattern is an object-based creational design pattern. In this, we use a\n sort of a \u201cskeleton\u201d of an existing object to create or instantiate new\n objects.<\/p>\n\n\n\n
This\n pattern is specifically important and beneficial to JavaScript because \nit utilizes prototypal inheritance instead of a classic object-oriented \ninheritance. Hence, it plays to JavaScript\u2019s strength and has native \nsupport.<\/p>\n\n\n\n
In this example, we have a car<\/code> object that we use as the prototype to create another object myCar<\/code> with JavaScript\u2019s Object.create <\/code>feature and define an extra property owner<\/code> on the new object.<\/p>\n\n\n\n
\/\/ using Object.create as was recommended by ES5 standard
\nconst car = {
\n  noOfWheels: 4,
\n  start() {
\n    return ‘started’;
\n  },
\n  stop() {
\n    return ‘stopped’;
\n  },
\n};<\/p>\n\n\n\n
\/\/ Object.create(proto[, propertiesObject])<\/p>\n\n\n\n
const myCar = Object.create(car, { owner: { value: ‘John’ } });<\/p>\n\n\n\n
console.log(myCar.proto<\/strong> === car); \/\/ true<\/p>\n\n\n\n
Singleton Pattern<\/h1>\n\n\n\n
Singleton\n is a special creational design pattern in which only one instance of a \nclass can exist. It works like this \u2014 if no instance of the singleton \nclass exists then a new instance is created and returned, but if an \ninstance already exists, then the reference to the existing instance is \nreturned.<\/p>\n\n\n\n
A perfect real-life example would be that of mongoose<\/code> (the famous Node.js ODM library for MongoDB). It utilizes the singleton pattern.<\/p>\n\n\n\n
In this example, we have a Database<\/code> class that is a singleton. First, we create an object mongo<\/code> by using the new<\/code> operator to invoke the Database<\/code> class constructor. This time an object is instantiated because none already exists. The second time, when we create the mysql<\/code> object, no new object is instantiated but instead, the reference to the object that was instantiated earlier, i.e. the mongo<\/code> object, is returned.<\/p>\n\n\n\n
class Database {
\n  constructor(data) {
\n    if (Database.exists) {
\n      return Database.instance;
\n    }
\n    this._data = data;
\n    Database.instance = this;
\n    Database.exists = true;
\n    return this;
\n  }<\/p>\n\n\n\n
getData() {
\n    return this._data;
\n  }<\/p>\n\n\n\n
setData(data) {
\n    this._data = data;
\n  }
\n}<\/p>\n\n\n\n
\/\/ usage
\nconst mongo = new Database(‘mongo’);
\nconsole.log(mongo.getData()); \/\/ mongo<\/p>\n\n\n\n
const mysql = new Database(‘mysql’);
 console.log(mysql.getData()); \/\/ mongo<\/p>\n\n\n\n
Adapter Pattern<\/h1>\n\n\n\n
This\n is a structural pattern where the interface of one class is translated \ninto another. This pattern lets classes work together that could not \notherwise because of incompatible interfaces.<\/p>\n\n\n\n
This\n pattern is often used to create wrappers for new refactored APIs so \nthat other existing old APIs can still work with them. This is usually \ndone when new implementations or code refactoring (done for reasons like\n performance gains) result in a different public API, while the other \nparts of the system are still using the old API and need to be adapted \nto work together.<\/p>\n\n\n\n
In this example, we have an old API, i.e. OldCalculator<\/code> class, and a new API, i.e. NewCalculator<\/code> class. The OldCalculator<\/code> class provides an operation<\/code>method for both addition and subtraction, while the NewCalculator<\/code> provides separate methods for addition and subtraction. The Adapter class CalcAdapter<\/code>wraps the NewCalculator<\/code> to add the operation<\/code> method to the public-facing API while using its own addition and subtraction implementation under the hood.<\/p>\n\n\n\n
\/\/ old interface
\nclass OldCalculator {
\n  constructor() {
\n    this.operations = function(term1, term2, operation) {
\n      switch (operation) {
\n        case ‘add’:
\n          return term1 + term2;
\n        case ‘sub’:
\n          return term1 – term2;
\n        default:
\n          return NaN;
\n      }
\n    };
\n  }
\n}<\/p>\n\n\n\n
\/\/ new interface
\nclass NewCalculator {
\n  constructor() {
\n    this.add = function(term1, term2) {
\n      return term1 + term2;
\n    };
\n    this.sub = function(term1, term2) {
\n      return term1 – term2;
\n    };
\n  }
\n}<\/p>\n\n\n\n
\/\/ Adapter Class
\nclass CalcAdapter {
\n  constructor() {
\n    const newCalc = new NewCalculator();<\/p>\n\n\n\n
this.operations = function(term1, term2, operation) {\n  switch (operation) {\n    case 'add':\n      \/\/ using the new implementation under the hood\n      return newCalc.add(term1, term2);\n    case 'sub':\n      return newCalc.sub(term1, term2);\n    default:\n      return NaN;\n  }\n};<\/code><\/pre>\n\n\n\n
}
\n}<\/p>\n\n\n\n
\/\/ usage
\nconst oldCalc = new OldCalculator();
\nconsole.log(oldCalc.operations(10, 5, ‘add’)); \/\/ 15<\/p>\n\n\n\n
const newCalc = new NewCalculator();
\nconsole.log(newCalc.add(10, 5)); \/\/ 15<\/p>\n\n\n\n
const adaptedCalc = new CalcAdapter();
 console.log(adaptedCalc.operations(10, 5, ‘add’)); \/\/ 15;<\/p>\n\n\n\n
Composite Pattern<\/h1>\n\n\n\n
This  is a structural design pattern that composes objects into tree-like  structures to represent whole-part hierarchies. In this pattern, each  node in the tree-like structure can be either an individual object or a  composed collection of objects. Regardless, each node is treated  uniformly.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
It\n is a bit complex to visualize this pattern. The easiest way to think \nabout this is with the example of a multi-level menu. Each node can be a\n distinct option, or it can be a menu itself, which has multiple options\n as its child. A node component with children is a composite component, \nwhile a node component without any child is a leaf component.<\/p>\n\n\n\n
In this example, we create a base class of Component<\/code>  that implements the common functionalities needed and abstracts the  other methods needed. The base class also has a static method that  utilises recursion to traverse a composite tree structure made with its  subclasses. Then we create two subclasses extending the base class \u2014 Leaf<\/code> that does not have any children and Composite<\/code>  that can have children\u2014and hence have methods handling adding,  searching, and removing child functionalities. The two subclasses are  used to create a composite structure\u2014a tree, in this case.<\/p>\n\n\n\n
class Component {
\n  constructor(name) {
\n    this._name = name;
\n  }<\/p>\n\n\n\n
getNodeName() {
\n    return this._name;
\n  }<\/p>\n\n\n\n
\/\/ abstract methods that need to be overridden
\n  getType() {}<\/p>\n\n\n\n
addChild(component) {}<\/p>\n\n\n\n
removeChildByName(componentName) {}<\/p>\n\n\n\n
removeChildByIndex(index) {}<\/p>\n\n\n\n
getChildByName(componentName) {}<\/p>\n\n\n\n
getChildByIndex(index) {}<\/p>\n\n\n\n
noOfChildren() {}<\/p>\n\n\n\n
static logTreeStructure(root) {
\n    let treeStructure = ”;
\n    function traverse(node, indent = 0) {
\n      treeStructure += ${'--'.repeat(indent)}${node.getNodeName()}\\n<\/code>;
\n      indent++;
\n      for (let i = 0, length = node.noOfChildren(); i < length; i++) {
\n        traverse(node.getChildByIndex(i), indent);
\n      }
\n    }<\/p>\n\n\n\n
traverse(root);\nreturn treeStructure;<\/code><\/pre>\n\n\n\n
}
\n}<\/p>\n\n\n\n
class Leaf extends Component {
\n  constructor(name) {
\n    super(name);
\n    this._type = ‘Leaf Node’;
\n  }<\/p>\n\n\n\n
getType() {
\n    return this._type;
\n  }<\/p>\n\n\n\n
noOfChildren() {
\n    return 0;
\n  }
\n}<\/p>\n\n\n\n
class Composite extends Component {
\n  constructor(name) {
\n    super(name);
\n    this._type = ‘Composite Node’;
\n    this._children = [];
\n  }<\/p>\n\n\n\n
getType() {
\n    return this._type;
\n  }<\/p>\n\n\n\n
addChild(component) {
\n    this._children = [\u2026this._children, component];
\n  }<\/p>\n\n\n\n
removeChildByName(componentName) {
\n    this._children = [\u2026this._children].filter(component => component.getNodeName() !== componentName);
\n  }<\/p>\n\n\n\n
removeChildByIndex(index) {
\n    this._children = [\u2026this._children.slice(0, index), \u2026this._children.slice(index + 1)];
\n  }<\/p>\n\n\n\n
getChildByName(componentName) {
\n    return this._children.find(component => component.name === componentName);
\n  }<\/p>\n\n\n\n
getChildByIndex(index) {
\n    return this._children[index];
\n  }<\/p>\n\n\n\n
noOfChildren() {
\n    return this._children.length;
\n  }
\n}<\/p>\n\n\n\n
\/\/ usage
\nconst tree = new Composite(‘root’);
\ntree.addChild(new Leaf(‘left’));
\nconst right = new Composite(‘right’);
\ntree.addChild(right);
\nright.addChild(new Leaf(‘right-left’));
\nconst rightMid = new Composite(‘right-middle’);
\nright.addChild(rightMid);
\nright.addChild(new Leaf(‘right-right’));
\nrightMid.addChild(new Leaf(‘left-end’));
\nrightMid.addChild(new Leaf(‘right-end’));<\/p>\n\n\n\n
\/\/ log
 console.log(Component.logTreeStructure(tree));
 \/*
 root
 –left
 –right
 —-right-left
 —-right-middle
 ——left-end
 ——right-end
 —-right-right
 *\/<\/p>\n\n\n\n
Decorator Pattern<\/h1>\n\n\n\n
This\n is also a structural design pattern that focuses on the ability to add \nbehaviour or functionalities to existing classes dynamically. It is \nanother viable alternative to sub-classing.<\/p>\n\n\n\n
The\n decorator type behaviour is very easy to implement in JavaScript \nbecause JavaScript allows us to add methods and properties to object \ndynamically. The simplest approach would be to just add a property to an\n object, but it will not be efficiently reusable.<\/p>\n\n\n\n
In fact, there is a proposal to add decorators to the JavaScript language. Take a look at Addy Osmani\u2019s post<\/strong><\/a> about decorators in JavaScript.<\/p>\n\n\n\n
If you want to read about the proposal itself<\/strong><\/a>, feel free.<\/p>\n\n\n\n
In this example, we create a Book<\/code> class. We further create two decorator functions that accept a book object and return a \u201cdecorated\u201d book<\/code> object \u2014 giftWrap<\/code> that adds one new attribute and one new function and hardbindBook<\/code> that adds one new attribute and edits the value of one existing attribute.<\/p>\n\n\n\n
class Book {
\n  constructor(title, author, price) {
\n    this._title = title;
\n    this._author = author;
\n    this.price = price;
\n  }<\/p>\n\n\n\n
getDetails() {
\n    return ${this._title} by ${this._author}<\/code>;
\n  }
\n}<\/p>\n\n\n\n
\/\/ decorator 1
\nfunction giftWrap(book) {
\n  book.isGiftWrapped = true;
\n  book.unwrap = function() {
\n    return Unwrapped ${book.getDetails()}<\/code>;
\n  };<\/p>\n\n\n\n
return book;
\n}<\/p>\n\n\n\n
\/\/ decorator 2
\nfunction hardbindBook(book) {
\n  book.isHardbound = true;
\n  book.price += 5;
\n  return book;
\n}<\/p>\n\n\n\n
\/\/ usage
\nconst alchemist = giftWrap(new Book(‘The Alchemist’, ‘Paulo Coelho’, 10));<\/p>\n\n\n\n
console.log(alchemist.isGiftWrapped); \/\/ true
\nconsole.log(alchemist.unwrap()); \/\/ ‘Unwrapped The Alchemist by Paulo Coelho’<\/p>\n\n\n\n
const inferno = hardbindBook(new Book(‘Inferno’, ‘Dan Brown’, 15));<\/p>\n\n\n\n
console.log(inferno.isHardbound); \/\/ true
 console.log(inferno.price); \/\/ 20<\/p>\n\n\n\n
Fa\u00e7ade Pattern<\/h1>\n\n\n\n
This\n is a structural design pattern that is widely used in the JavaScript \nlibraries. It is used to provide a unified and simpler, public-facing \ninterface for ease of use that shields away from the complexities of its\n consisting subsystems or subclasses.<\/p>\n\n\n\n
The use of this pattern is very common in libraries like jQuery.<\/p>\n\n\n\n
In this example, we create a public facing API with the class ComplaintRegistry<\/code>. It exposes only one method to be used by the client, i.e. registerComplaint<\/code>. It internally handles instantiating required objects of either ProductComplaint<\/code> or ServiceComplaint<\/code>  based on the type argument. It also handles all the other complex  functionalities like generating a unique ID, storing the complaint in  memory, etc. But, all these complexities are hidden away using the  fa\u00e7ade pattern.<\/p>\n\n\n\n
let currentId = 0;<\/p>\n\n\n\n
class ComplaintRegistry {
\n  registerComplaint(customer, type, details) {
\n    const id = ComplaintRegistry._uniqueIdGenerator();
\n    let registry;
\n    if (type === ‘service’) {
\n      registry = new ServiceComplaints();
\n    } else {
\n      registry = new ProductComplaints();
\n    }
\n    return registry.addComplaint({ id, customer, details });
\n  }<\/p>\n\n\n\n
static _uniqueIdGenerator() {
\n    return ++currentId;
\n  }
\n}<\/p>\n\n\n\n
class Complaints {
\n  constructor() {
\n    this.complaints = [];
\n  }<\/p>\n\n\n\n
addComplaint(complaint) {
\n    this.complaints.push(complaint);
\n    return this.replyMessage(complaint);
\n  }<\/p>\n\n\n\n
getComplaint(id) {
\n    return this.complaints.find(complaint => complaint.id === id);
\n  }<\/p>\n\n\n\n
replyMessage(complaint) {}
\n}<\/p>\n\n\n\n
class ProductComplaints extends Complaints {
\n  constructor() {
\n    super();
\n    if (ProductComplaints.exists) {
\n      return ProductComplaints.instance;
\n    }
\n    ProductComplaints.instance = this;
\n    ProductComplaints.exists = true;
\n    return this;
\n  }<\/p>\n\n\n\n
replyMessage({ id, customer, details }) {
\n    return Complaint No. ${id} reported by ${customer} regarding ${details} have been filed with the Products Complaint Department. Replacement\/Repairment of the product as per terms and conditions will be carried out soon.<\/code>;
\n  }
\n}<\/p>\n\n\n\n
class ServiceComplaints extends Complaints {
\n  constructor() {
\n    super();
\n    if (ServiceComplaints.exists) {
\n      return ServiceComplaints.instance;
\n    }
\n    ServiceComplaints.instance = this;
\n    ServiceComplaints.exists = true;
\n    return this;
\n  }<\/p>\n\n\n\n
replyMessage({ id, customer, details }) {
\n    return Complaint No. ${id} reported by ${customer} regarding ${details} have been filed with the Service Complaint Department. The issue will be resolved or the purchase will be refunded as per terms and conditions.<\/code>;
\n  }
\n}<\/p>\n\n\n\n
\/\/ usage
\nconst registry = new ComplaintRegistry();<\/p>\n\n\n\n
const reportService = registry.registerComplaint(‘Martha’, ‘service’, ‘availability’);
\n\/\/ ‘Complaint No. 1 reported by Martha regarding availability have been filed with the Service Complaint Department. The issue will be resolved or the purchase will be refunded as per terms and conditions.’<\/p>\n\n\n\n
const reportProduct = registry.registerComplaint(‘Jane’, ‘product’, ‘faded color’);
 \/\/ ‘Complaint No. 2 reported by Jane regarding faded color have been filed with the Products Complaint Department. Replacement\/Repairment of the product as per terms and conditions will be carried out soon.’<\/p>\n\n\n\n
Flyweight Pattern<\/h1>\n\n\n\n
This\n is a structural design pattern focused on efficient data sharing \nthrough fine-grained objects. It is used for efficiency and memory \nconservation purposes.<\/p>\n\n\n\n
This\n pattern can be used for any kind of caching purposes. In fact, modern \nbrowsers use a variant of a flyweight pattern to prevent loading the \nsame images twice.<\/p>\n\n\n\n
In this example, we create a fine-grained flyweight class Icecream<\/code> for sharing data regarding ice-cream flavours and a factory class IcecreamFactory<\/code>  to create those flyweight objects. For memory conservation, the objects  are recycled if the same object is instantiated twice. This is a simple  example of flyweight implementation.<\/p>\n\n\n\n
\/\/ flyweight class
\nclass Icecream {
\n  constructor(flavour, price) {
\n    this.flavour = flavour;
\n    this.price = price;
\n  }
\n}<\/p>\n\n\n\n
\/\/ factory for flyweight objects
\nclass IcecreamFactory {
\n  constructor() {
\n    this._icecreams = [];
\n  }<\/p>\n\n\n\n
createIcecream(flavour, price) {
\n    let icecream = this.getIcecream(flavour);
\n    if (icecream) {
\n      return icecream;
\n    } else {
\n      const newIcecream = new Icecream(flavour, price);
\n      this._icecreams.push(newIcecream);
\n      return newIcecream;
\n    }
\n  }<\/p>\n\n\n\n
getIcecream(flavour) {
\n    return this._icecreams.find(icecream => icecream.flavour === flavour);
\n  }
\n}<\/p>\n\n\n\n
\/\/ usage
\nconst factory = new IcecreamFactory();<\/p>\n\n\n\n
const chocoVanilla = factory.createIcecream(‘chocolate and vanilla’, 15);
\nconst vanillaChoco = factory.createIcecream(‘chocolate and vanilla’, 15);<\/p>\n\n\n\n
\/\/ reference to the same object
 console.log(chocoVanilla === vanillaChoco); \/\/ true<\/p>\n\n\n\n
Proxy Pattern<\/h1>\n\n\n\n
This\n is a structural design pattern that behaves exactly as its name \nsuggests. It acts as a surrogate or placeholder for another object to \ncontrol access to it.<\/p>\n\n\n\n
It\n is usually used in situations in which a target object is under \nconstraints and may not be able to handle all its responsibilities \nefficiently. A proxy, in this case, usually provides the same interface \nto the client and adds a level of indirection to support controlled \naccess to the target object to avoid undue pressure on it.<\/p>\n\n\n\n
The\n proxy pattern can be very useful when working with network \nrequest-heavy applications to avoid unnecessary or redundant network \nrequests.<\/p>\n\n\n\n
In this example, we will use two new ES6 features, Proxy<\/strong><\/a> and Reflect<\/strong><\/a>.\n A Proxy object is used to define custom behaviour for fundamental \noperations of a JavaScript object (remember, function and arrays are \nalso object in JavaScript). It is a constructor method that can be used \nto create a Proxy<\/code> object. It accepts a target<\/code> object that is to be proxied and a handler<\/code> object that will define the necessary customisation. The handler object allows for defining some trap functions like get<\/code>, set<\/code>, has<\/code>, apply<\/code>, etc. that are used to add custom behaviour attached to their usage. Reflect<\/code>,\n on the other hand, is a built-in object that provides similar methods \nthat are supported by the handler object of Proxy as static methods on \nitself. It is not a constructor; its static methods are used for \nintercept-able JavaScript operations.<\/p>\n\n\n\n
Now, we create a function that can be thought of as a network request. We named it as networkFetch<\/code>.\n It accepts a URL and responds accordingly. We want to implement a proxy\n where we only get the response from the network if it is not available \nin our cache. Otherwise, we just return a response from the cache.<\/p>\n\n\n\n
The cache<\/code> global variable will store our cached responses. We create a proxy named proxiedNetworkFetch<\/code> with our original networkFetch<\/code> as the target<\/code>and use apply method in our handler<\/code> object to proxy the function invocation. The apply method gets passed on the target<\/code> object itself. This value as thisArg<\/code> and the arguments are passed to it in an array-like structure args<\/code>.<\/p>\n\n\n\n
We  check if the passed url argument is in the cache. If it exists in the  cache, we return the response from there, never invoking the original  target function. If it does not, then we use the Reflect.apply<\/code> method to invoke the target<\/code>function with thisArg<\/code> (although it\u2019s not of any significance in our case here) and the arguments it passed.<\/p>\n\n\n\n
\/\/ Target
\nfunction networkFetch(url) {
\n  return ${url} - Response from network<\/code>;
\n}<\/p>\n\n\n\n
\/\/ Proxy
\n\/\/ ES6 Proxy API = new Proxy(target, handler);
\nconst cache = [];
\nconst proxiedNetworkFetch = new Proxy(networkFetch, {
\n  apply(target, thisArg, args) {
\n    const urlParam = args[0];
\n    if (cache.includes(urlParam)) {
\n      return ${urlParam} - Response from cache<\/code>;
\n    } else {
\n      cache.push(urlParam);
\n      return Reflect.apply(target, thisArg, args);
\n    }
\n  },
\n});<\/p>\n\n\n\n
\/\/ usage
 console.log(proxiedNetworkFetch(‘dogPic.jpg’)); \/\/ ‘dogPic.jpg – Response from network’
 console.log(proxiedNetworkFetch(‘dogPic.jpg’)); \/\/ ‘dogPic.jpg – Response from cache’<\/p>\n\n\n\n
Chain of Responsibility Pattern<\/h1>\n\n\n\n
This\n is a behavioural design pattern that provides a chain of loosely \ncoupled objects. Each of these objects can choose to act on or handle \nthe request of the client.<\/p>\n\n\n\n
A\n good example of the chain of responsibility pattern is the event \nbubbling in DOM in which an event propagates through a series of nested \nDOM elements, one of which may have an \u201cevent listener\u201d attached to \nlisten to and act on the event.<\/p>\n\n\n\n
In this example, we create a class CumulativeSum<\/code>, which can be instantiated with an optional initialValue<\/code>. It has a method add<\/code> that adds the passed value to the sum<\/code> attribute of the object and returns the object<\/code> itself to allow chaining of add<\/code> method calls.<\/p>\n\n\n\n
class CumulativeSum {
\n  constructor(intialValue = 0) {
\n    this.sum = intialValue;
\n  }<\/p>\n\n\n\n
add(value) {
\n    this.sum += value;
\n    return this;
\n  }
\n}<\/p>\n\n\n\n
\/\/ usage
\nconst sum1 = new CumulativeSum();
\nconsole.log(sum1.add(10).add(2).add(50).sum); \/\/ 62<\/p>\n\n\n\n
const sum2 = new CumulativeSum(10);
 console.log(sum2.add(10).add(20).add(5).sum); \/\/ 45<\/p>\n\n\n\n
Command Pattern<\/h1>\n\n\n\n
This\n is a behavioural design pattern that aims to encapsulate actions or \noperations as objects. This pattern allows loose coupling of systems and\n classes by separating the objects that request an operation or invoke a\n method from the ones that execute or process the actual implementation.<\/p>\n\n\n\n
The clipboard interaction API somewhat resembles the command pattern. If you are a Redux<\/strong><\/a>\n user, you have already come across the command pattern. The actions \nthat allow the awesome time-travel debugging feature are nothing but \nencapsulated operations that can be tracked to redo or undo operations. \nHence, time-travelling made possible.<\/p>\n\n\n\n
In this example, we have a class called SpecialMath<\/code> that has multiple methods and a Command<\/code> class that encapsulates commands that are to be executed on its subject, i.e. an object of the SpecialMath<\/code> class. The Command<\/code>  class also keeps track of all the commands executed, which can be used  to extend its functionality to include undo and redo type operations.<\/p>\n\n\n\n
class SpecialMath {
\n  constructor(num) {
\n    this._num = num;
\n  }<\/p>\n\n\n\n
square() {
\n    return this._num ** 2;
\n  }<\/p>\n\n\n\n
cube() {
\n    return this._num ** 3;
\n  }<\/p>\n\n\n\n
squareRoot() {
\n    return Math.sqrt(this._num);
\n  }
\n}<\/p>\n\n\n\n
class Command {
\n  constructor(subject) {
\n    this._subject = subject;
\n    this.commandsExecuted = [];
\n  }
\n  execute(command) {
\n    this.commandsExecuted.push(command);
\n    return this._subject[command]();
\n  }
\n}<\/p>\n\n\n\n
\/\/ usage
\nconst x = new Command(new SpecialMath(5));
\nx.execute(‘square’);
\nx.execute(‘cube’);<\/p>\n\n\n\n
console.log(x.commandsExecuted); \/\/ [‘square’, ‘cube’]<\/p>\n\n\n\n
Iterator Pattern<\/h1>\n\n\n\n
It\n is a behavioural design pattern that provides a way to access the \nelements of an aggregate object sequentially without exposing its \nunderlying representation.<\/p>\n\n\n\n
Iterators have a special kind of behaviour where we step through an ordered set of values one at a time by calling next()<\/code>\n until we reach the end. The introduction of Iterator and Generators in \nES6 made the implementation of the iterator pattern extremely \nstraightforward.<\/p>\n\n\n\n
We have two examples below. First, one IteratorClass<\/code> uses iterator spec, while the other one iteratorUsingGenerator<\/code> uses generator functions.<\/p>\n\n\n\n
The Symbol.iterator<\/code> ( Symbol<\/code>\u2014a\n new kind of primitive data type) is used to specify the default \niterator for an object. It must be defined for a collection to be able \nto use the for...of<\/code> looping construct. In the first example, we define the constructor to store some collection of data and then define Symbol.iterator<\/code>, which returns an object with next<\/code> method for iteration.<\/p>\n\n\n\n
For the second case, we define a generator function passing it an array of data and returning its elements iteratively using next<\/code> and yield<\/code>.  A generator function is a special type of function that works as a  factory for iterators and can explicitly maintain its own internal state  and yield values iteratively. It can pause and resume its own execution  cycle.<\/p>\n\n\n\n
\/\/ using Iterator
\nclass IteratorClass {
\n  constructor(data) {
\n    this.index = 0;
\n    this.data = data;
\n  }<\/p>\n\n\n\n
[Symbol.iterator]() {
\n    return {
\n      next: () => {
\n        if (this.index < this.data.length) {
\n          return { value: this.data[this.index++], done: false };
\n        } else {
\n          this.index = 0; \/\/ to reset iteration status
\n          return { done: true };
\n        }
\n      },
\n    };
\n  }
\n}<\/p>\n\n\n\n
\/\/ using Generator
\nfunction* iteratorUsingGenerator(collection) {
\n  var nextIndex = 0;<\/p>\n\n\n\n
while (nextIndex < collection.length) {
\n    yield collection[nextIndex++];
\n  }
\n}<\/p>\n\n\n\n
\/\/ usage
\nconst gen = iteratorUsingGenerator([‘Hi’, ‘Hello’, ‘Bye’]);<\/p>\n\n\n\n
console.log(gen.next().value); \/\/ ‘Hi’
 console.log(gen.next().value); \/\/ ‘Hello’
 console.log(gen.next().value); \/\/ ‘Bye’<\/p>\n\n\n\n
Mediator Pattern<\/h1>\n\n\n\n
It\n is a behavioural design pattern that encapsulates how a set of objects \ninteract with each other. It provides the central authority over a group\n of objects by promoting loose coupling, keeping objects from referring \nto each other explicitly.<\/p>\n\n\n\n
In this example, we have TrafficTower<\/code> as Mediator that controls the way Airplane<\/code> objects interact with each other. All the Airplane<\/code> objects register themselves with a TrafficTower<\/code> object, and it is the mediator class object that handles how an Airplane<\/code> object receives coordinates data of all the other Airplane<\/code> objects.<\/p>\n\n\n\n
class TrafficTower {
\n  constructor() {
\n    this._airplanes = [];
\n  }<\/p>\n\n\n\n
register(airplane) {
\n    this._airplanes.push(airplane);
\n    airplane.register(this);
\n  }<\/p>\n\n\n\n
requestCoordinates(airplane) {
\n    return this._airplanes.filter(plane => airplane !== plane).map(plane => plane.coordinates);
\n  }
\n}<\/p>\n\n\n\n
class Airplane {
\n  constructor(coordinates) {
\n    this.coordinates = coordinates;
\n    this.trafficTower = null;
\n  }<\/p>\n\n\n\n
register(trafficTower) {
\n    this.trafficTower = trafficTower;
\n  }<\/p>\n\n\n\n
requestCoordinates() {
\n    if (this.trafficTower) return this.trafficTower.requestCoordinates(this);
\n    return null;
\n  }
\n}<\/p>\n\n\n\n
\/\/ usage
\nconst tower = new TrafficTower();<\/p>\n\n\n\n
const airplanes = [new Airplane(10), new Airplane(20), new Airplane(30)];
\nairplanes.forEach(airplane => {
\n  tower.register(airplane);
\n});<\/p>\n\n\n\n
console.log(airplanes.map(airplane => airplane.requestCoordinates())) 
 \/\/ [[20, 30], [10, 30], [10, 20]]<\/p>\n\n\n\n
Observer Pattern<\/h1>\n\n\n\n
It\n is a crucial behavioural design pattern that defines one-to-many \ndependencies between objects so that when one object (publisher) changes\n its state, all the other dependent objects (subscribers) are notified \nand updated automatically. This is also called PubSub \n(publisher\/subscribers) or event dispatcher\/listeners pattern. The \npublisher is sometimes called the subject, and the subscribers are \nsometimes called observers.<\/p>\n\n\n\n
Chances are, you\u2019re already somewhat familiar with this pattern if you have used addEventListener<\/code> or jQuery\u2019s .on<\/code> to write even-handling code. It has its influences in Reactive Programming (think RxJS<\/strong><\/a>) as well.<\/p>\n\n\n\n
In the example, we create a simple Subject<\/code> class that has methods to add and remove objects of Observer<\/code> class from subscriber collection. Also, a fire<\/code>method to propagate any changes in the Subject<\/code> class object to the subscribed Observers. The Observer<\/code>\n class, on the other hand, has its internal state and a method to update\n its internal state based on the change propagated from the Subject<\/code> it has subscribed to.<\/p>\n\n\n\nclass Subject {\n  constructor() {\n    this._observers = [];\n  }\n\n  subscribe(observer) {\n    this._observers.push(observer);\n  }\n\n  unsubscribe(observer) {\n    this._observers = this._observers.filter(obs => observer !== obs);\n  }\n\n  fire(change) {\n    this._observers.forEach(observer => {\n      observer.update(change);\n    });\n  }\n}\n\nclass Observer {\n  constructor(state) {\n    this.state = state;\n    this.initialState = state;\n  }\n\n  update(change) {\n    let state = this.state;\n    switch (change) {\n      case ‘INC’:\n        this.state = ++state;\n        break;\n      case ‘DEC’:\n        this.state = –state;\n        break;\n      default:\n        this.state = this.initialState;\n    }\n  }\n}\n\n\/\/ usage\nconst sub = new Subject();\n\nconst obs1 = new Observer(1);\nconst obs2 = new Observer(19);\n\nsub.subscribe(obs1);\nsub.subscribe(obs2);\n\nsub.fire(‘INC’);\n\nconsole.log(obs1.state); \/\/ 2\nconsole.log(obs2.state); \/\/ 20\n\n\n\n
State Pattern<\/h1>\n\n\n\n
It\n is a behavioural design pattern that allows an object to alter its \nbehaviour based on changes to its internal state. The object returned by\n a state pattern class seems to change its class. It provides \nstate-specific logic to a limited set of objects in which each object \ntype represents a particular state.<\/p>\n\n\n\n
We will take a simple example of a traffic light to understand this pattern. The TrafficLight<\/code> class changes the object it returns based on its internal state, which is an object of Red<\/code>, Yellow<\/code>, or Green<\/code> class.<\/p>\n\n\n\n
class TrafficLight {
\n  constructor() {
\n    this.states = [new GreenLight(), new RedLight(), new YellowLight()];
\n    this.current = this.states[0];
\n  }<\/p>\n\n\n\n
change() {
\n    const totalStates = this.states.length;
\n    let currentIndex = this.states.findIndex(light => light === this.current);
\n    if (currentIndex + 1 < totalStates) this.current = this.states[currentIndex + 1];
\n    else this.current = this.states[0];
\n  }<\/p>\n\n\n\n
sign() {
\n    return this.current.sign();
\n  }
\n}<\/p>\n\n\n\n
class Light {
\n  constructor(light) {
\n    this.light = light;
\n  }
\n}<\/p>\n\n\n\n
class RedLight extends Light {
\n  constructor() {
\n    super(‘red’);
\n  }<\/p>\n\n\n\n
sign() {
\n    return ‘STOP’;
\n  }
\n}<\/p>\n\n\n\n
class YellowLight extends Light {
\n  constructor() {
\n    super(‘yellow’);
\n  }<\/p>\n\n\n\n
sign() {
\n    return ‘STEADY’;
\n  }
\n}<\/p>\n\n\n\n
class GreenLight extends Light {
\n    constructor() {
\n        super(‘green’);
\n    }<\/p>\n\n\n\n
sign() {\n    return 'GO';\n}<\/code><\/pre>\n\n\n\n
}<\/p>\n\n\n\n
\/\/ usage
\nconst trafficLight = new TrafficLight();<\/p>\n\n\n\n
console.log(trafficLight.sign()); \/\/ ‘GO’
\ntrafficLight.change();<\/p>\n\n\n\n
console.log(trafficLight.sign()); \/\/ ‘STOP’
\ntrafficLight.change();<\/p>\n\n\n\n
console.log(trafficLight.sign()); \/\/ ‘STEADY’
\ntrafficLight.change();<\/p>\n\n\n\n
console.log(trafficLight.sign()); \/\/ ‘GO’
\ntrafficLight.change();<\/p>\n\n\n\n
console.log(trafficLight.sign()); \/\/ ‘STOP’<\/p>\n\n\n\n
Strategy Pattern<\/h1>\n\n\n\n
It\n is a behavioural design pattern that allows encapsulation of \nalternative algorithms for a particular task. It defines a family of \nalgorithms and encapsulates them in such a way that they are \ninterchangeable at runtime without client interference or knowledge.<\/p>\n\n\n\n
In the example below, we create a class Commute<\/code> for encapsulating all the possible strategies for commuting to work. Then, we define three strategies namely Bus<\/code>, PersonalCar<\/code>, and Taxi<\/code>. Using this pattern we can swap the implementation to use for the travel<\/code> method of the Commute<\/code> object at runtime.<\/p>\n\n\n\n
\/\/ encapsulation<\/td><\/tr><\/tbody><\/table>\n\n\n\n
class Commute {<\/td><\/tr><\/tbody><\/table>\n\n\n\n
  travel(transport) {<\/td><\/tr><\/tbody><\/table>\n\n\n\n
    return transport.travelTime();<\/td><\/tr><\/tbody><\/table>\n\n\n\n
  }<\/td><\/tr><\/tbody><\/table>\n\n\n\n
}<\/td><\/tr><\/tbody><\/table>\n\n\n\n<\/tr><\/tbody><\/table>\n\n\n\n
class Vehicle {<\/td><\/tr><\/tbody><\/table>\n\n\n\n
  travelTime() {<\/td><\/tr><\/tbody><\/table>\n\n\n\n
    return this._timeTaken;<\/td><\/tr><\/tbody><\/table>\n\n\n\n
  }<\/td><\/tr><\/tbody><\/table>\n\n\n\n
}<\/td><\/tr><\/tbody><\/table>\n\n\n\n<\/tr><\/tbody><\/table>\n\n\n\n
\/\/ strategy 1<\/td><\/tr><\/tbody><\/table>\n\n\n\n
class Bus extends Vehicle {<\/td><\/tr><\/tbody><\/table>\n\n\n\n
  constructor() {<\/td><\/tr><\/tbody><\/table>\n\n\n\n
    super();<\/td><\/tr><\/tbody><\/table>\n\n\n\n
    this._timeTaken = 10;<\/td><\/tr><\/tbody><\/table>\n\n\n\n
  }<\/td><\/tr><\/tbody><\/table>\n\n\n\n
}<\/td><\/tr><\/tbody><\/table>\n\n\n\n<\/tr><\/tbody><\/table>\n\n\n\n
\/\/ strategy 2<\/td><\/tr><\/tbody><\/table>\n\n\n\n
class Taxi extends Vehicle {<\/td><\/tr><\/tbody><\/table>\n\n\n\n
  constructor() {<\/td><\/tr><\/tbody><\/table>\n\n\n\n
    super();<\/td><\/tr><\/tbody><\/table>\n\n\n\n
    this._timeTaken = 5;<\/td><\/tr><\/tbody><\/table>\n\n\n\n
  }<\/td><\/tr><\/tbody><\/table>\n\n\n\n
}<\/td><\/tr><\/tbody><\/table>\n\n\n\n<\/tr><\/tbody><\/table>\n\n\n\n
\/\/ strategy 3<\/td><\/tr><\/tbody><\/table>\n\n\n\n
class PersonalCar extends Vehicle {<\/td><\/tr><\/tbody><\/table>\n\n\n\n
  constructor() {<\/td><\/tr><\/tbody><\/table>\n\n\n\n
    super();<\/td><\/tr><\/tbody><\/table>\n\n\n\n
    this._timeTaken = 3;<\/td><\/tr><\/tbody><\/table>\n\n\n\n
  }<\/td><\/tr><\/tbody><\/table>\n\n\n\n
}<\/td><\/tr><\/tbody><\/table>\n\n\n\n<\/tr><\/tbody><\/table>\n\n\n\n
\/\/ usage<\/td><\/tr><\/tbody><\/table>\n\n\n\n
const commute = new Commute();<\/td><\/tr><\/tbody><\/table>\n\n\n\n<\/tr><\/tbody><\/table>\n\n\n\n
console.log(commute.travel(new Taxi())); \/\/ 5<\/td><\/tr><\/tbody><\/table>\n\n\n\n
console.log(commute.travel(new Bus())); \/\/ 10<\/p>\n\n\n\n
Template Pattern<\/h1>\n\n\n\n
This\n is a behavioural design pattern based on defining the skeleton of the \nalgorithm or implementation of an operation, but deferring some steps to\n subclasses. It lets subclasses redefine certain steps of an algorithm \nwithout changing the algorithm\u2019s outward structure.<\/p>\n\n\n\n
In this example, we have a Template class Employee<\/code> that implements work<\/code>method  partially. It is for the subclasses to implement responsibilities  method to make it work as a whole. We then create two subclasses Developer<\/code> and Tester<\/code> that extend the template class and implement the required method to fill the implementation gap.<\/p>\n\n\n\n
class Employee {
\n  constructor(name, salary) {
\n    this._name = name;
\n    this._salary = salary;
\n  }<\/p>\n\n\n\n
work() {
\n    return ${this._name} handles ${this.responsibilities() \/* gap to be filled by subclass *\/}<\/code>;
\n  }<\/p>\n\n\n\n
getPaid() {
\n    return ${this._name} got paid ${this._salary}<\/code>;
\n  }
\n}<\/p>\n\n\n\n
class Developer extends Employee {
\n  constructor(name, salary) {
\n    super(name, salary);
\n  }<\/p>\n\n\n\n
\/\/ details handled by subclass
\n  responsibilities() {
\n    return ‘application development’;
\n  }
\n}<\/p>\n\n\n\n
class Tester extends Employee {
\n  constructor(name, salary) {
\n    super(name, salary);
\n  }<\/p>\n\n\n\n
\/\/ details handled by subclass
\n  responsibilities() {
\n    return ‘testing’;
\n  }
\n}<\/p>\n\n\n\n
\/\/ usage
\nconst dev = new Developer(‘Nathan’, 100000);
\nconsole.log(dev.getPaid()); \/\/ ‘Nathan got paid 100000’
\nconsole.log(dev.work()); \/\/ ‘Nathan handles application development’<\/p>\n\n\n\n
const tester = new Tester(‘Brian’, 90000);
 console.log(tester.getPaid()); \/\/ ‘Brian got paid 90000’
 console.log(tester.work()); \/\/ ‘Brian handles testing’<\/p>\n\n\n\n
Conclusion<\/h1>\n\n\n\n
Design\n patterns are crucial to software engineering and can be very helpful in\n solving common problems. But this is a very vast subject, and it is \nsimply not possible to include everything about them in a short piece. \nTherefore, I made the choice to shortly and concisely talk only about \nthe ones I think can be really handy in writing modern JavaScript. To \ndive deeper, I suggest you take a look at these books:<\/p>\n\n\n\n
  1. Design Patterns: Elements Of Reusable Object-Oriented Software<\/strong><\/a>by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (Gang of Four)<\/em><\/li>
  2. Learn JavaScript Design Patterns<\/strong> <\/a>by Addy Osmani<\/em><\/li>
  3. JavaScript Patterns<\/strong><\/a> by Stoyan Stefanov<\/em><\/li><\/ol>\n","protected":false},"excerpt":{"rendered":"
    The ultimate guide to the most useful design patterns UPDATE NOTE: Updated the Proxy Pattern example to use ES6 Proxy and Reflect. Replaced images of source code snippets with GitHub gists. In this article, we are going to talk about design patterns that can be and should be used to write better, maintainable JavaScript code. … Continue reading “JavaScript Design Patterns”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-54","post","type-post","status-publish","format-standard","hentry","category-updates"],"_links":{"self":[{"href":"https:\/\/cebucodesolutions.com\/blog\/wp-json\/wp\/v2\/posts\/54","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cebucodesolutions.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cebucodesolutions.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cebucodesolutions.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cebucodesolutions.com\/blog\/wp-json\/wp\/v2\/comments?post=54"}],"version-history":[{"count":1,"href":"https:\/\/cebucodesolutions.com\/blog\/wp-json\/wp\/v2\/posts\/54\/revisions"}],"predecessor-version":[{"id":60,"href":"https:\/\/cebucodesolutions.com\/blog\/wp-json\/wp\/v2\/posts\/54\/revisions\/60"}],"wp:attachment":[{"href":"https:\/\/cebucodesolutions.com\/blog\/wp-json\/wp\/v2\/media?parent=54"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cebucodesolutions.com\/blog\/wp-json\/wp\/v2\/categories?post=54"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cebucodesolutions.com\/blog\/wp-json\/wp\/v2\/tags?post=54"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
This is a common pattern that can be seen in jQuery<\/strong><\/a> as well, where almost any method call on a jQuery object returns a jQuery object so that method calls can be chained together.<\/p>\n\n\n\n