Object Oriented JavaScript

JavaScript Objects And Classes

1 Object Constructor

This is Anti pattern

var james = new Object();
james.name = "James Bond";
james.getName = function () {
        return this.name;

2 Object.create Function

This is Anti pattern

var james = Object.create(null);
james.name = "James Bond";
james.getName = function () {
        return this.name;
//General Syntax is
var obj = Object.create({prop: ...});

3 Object Literal Syntax

var james = {
    name: "James Bond",
    getName: function () {
        return this.name;

4 Function Constructor

function Person(name) { 
        this.name = name; 
        this.getName = function() { 
            return this.name; 
// OR
var Person = function (name) {
    this.name = name;
    this.getName = function () {
        return this.name;
var james = new Person ("James Bond");
// Don't do this!
Person('James'); //=> undefined

4.1 Enforce New

function Person (name) {
    var that = {};
    that.name = name;
    that.getName = function () {
        return this.name;
    return that;
function Person (name) {
    return {
        name: name,
        getName : function () {
            return this.name;

5 Sington

var james = new function (name) {
    this.name = name;
    this.getName = function () {
        return this.name;

6 ES6 Syntax

class Person {
  constructor(name) {
    this.name = name;   
  get name() {
    return this.name;

JavaScript Prototype


In General you have to be cautious with :

  • What goes inside constructor function
  • what goes inside prototype
  • Be extra careful if you are putting properties in prototype

Properties and Methods

Objects created using constructor function will have its own copies of properties and methods. Further it will have prototype property, which will intern have constructor property and a chain of prototype property.

Method in Constructor Function

function Person(firstName, lastName) {
    this.firstName = firstName,
    this.lastName = lastName,
    this.fullName = function() {
        return this.firstName + " " this.lastName;
var person = new Person("Mohammad""Nadeem");
var person2 = new Person("Nagaraj""Mandalaparty");




As can be seen here both functions are not same.

person.fullName == person2.fullName
person.fullName === person2.fullName

Method in Prototype

Storing seperate instances of methods in each object may not be a good idea (memory wastage), and hence lets see what happens if we do the follows.

function Person(firstName, lastName) {
    this.firstName = firstName;
    this.lastName = lastName;  
Person.prototype.fullName = function() {
    return this.firstName + " " this.lastName;
var nadeem = new Person("Mohammad""Nadeem");
var nagaraj= new Person("Nagaraj""Mandalaparty");

As can be seen here both functions are same

nadeem.fullName == nagaraj.fullName
nadeem.fullName === nagaraj.fullName

Prototype Object of constructor function is shared among all the objects created using the same constructor function.

Further prototype forms the basis of Inheritance in JavaScript

JavaScript Object Properties and Methods

Private Property

function Person(name) {
        // private property, only available within this constructor function
        var type = "Human Being;


Privilege Method

function Person(name) {
        // private property, only available with this function constructor
        var type = "Human Being;
       // Privileged method accessing private properties and other privilege methods
       this.getType = function() {
            return type;


Public Property And Method

function Person(name) {
        // public property
        this.name = name;
        // public method accessing public property
        this.getName = function() {
            return this.name;
function Person(name) {
        // public property
        this.name = name;
// Pbulic method : the 'this' keyword refers to the object instance, you can access only 'privileged' and 'public' members
Person.prototype.getName = function() {
     return this.name;

Note : Always add public methods to prototype


Static Property And Method

//static Property : Shared by all instances of the class and stored in one place.
Person.db = "Oracle";
// Static method, can access static property
Person.find = function(id){ /*...*/ };


Private Method

function Foo(x) {
    //private property
    var y = 5;
    //private method
    var bar = function() {
        return y * x;
    //public method
    this.public = function(z) {
        return bar() + x * z;
var MYLIB = function() { 
    var aPrivateProperty = true;
    var aPrivateMethod = function() {
        // some code here...
    return {
        aPublicMethod : function() {
            aPrivateMethod(); // okay
            // some code here...
        aPublicProperty : true
var Person = function(){};
  var findById = function(){ /* ... */ };
  Person.find = function(id){
    if (typeof id == "number")
      return findById(id);
function Person() {
Person.prototype = (function() {
    var privateMethod = function() {
        // Private code here
    return {
        // Person.prototype.constructor should be Person
        publicMethod:function() {
            privateMethod ();

Every object in JavaScript has a constructor property that references the constructor object that was used to create the instance of that object (refers back to the constructor function itself).

For instance, in all functions, the constructor property has a reference to the Function type constructor.
It is always a good idea to reset the constructor property of the prototype object after it has been completely replaced (in some cases), as follows:

ChildType.prototype.constructor = ChildType;

JavaScript Inheritance

JavaScript is a prototype-based language and hence it has the notions of a prototypical object (rather than make distinctions between classes and instances):

  • An object used as a template from which to get the initial properties for a new object.
  • Any object can be associated as a prototype of another object, sharing its properties.

Which forms the basis of inheritance in JavaScript.

In general, use constructor to inherit the instance properties and prototype chaining to to inherit methods and shared properties.

Simple Inheritance
var Animal = function(){
Animal.prototype.breath = function() {
var Dog = function() {
  //Inherit instance properties
  //we have to call the parents constructor with the current instance, this is like `super()` in Java
//Inherit methods and shared properties
// Dog inherits from Animal
Dog.prototype = new Animal;
//Dog.prototype = Object.create(Animal.prototype);  // Copy the parent's prototype to the child's prototype
//Dog.prototype.constructor = Dog;   // Assign the constructor by assigning Class.prototype.constructor (because the parent's prototype was copied)
Dog.prototype.wag = function(){
  console.log('wag tail');
Calling Super
var BaseCar = function(config) {
    this.octaneRequired = 86;
    this.shiftTo = function(gear) {
        this.gear = gear;
BaseCar.prototype = (function() {
     return {
        //It is always a good idea to reset the constructor property of the prototype object after it has been completely replaced
        engine : "I4",
        turbo : false,
        wheels : "basic",
        getEngine : function() {
            return this.engine;
        drive : function () {
var PremimumCar = function() {
PremimumCar.prototype = new BaseCar;
PremimumCar.prototype.turbo = true;
PremimumCar.prototype.wheels = "premimum";
PremimumCar.prototype.drive = function() {
    // Call Super
PremimumCar.prototype.getEngine = function() {
    return "Turbo " this.engine;

Calling Super


JavaScript Patterns

Immediately Invoked Function Expression (IIFE)

IIFE are the basis of module patterns and its variants.

Here are some examples

Simple Example
  /* ... */
(function($, exports){
  exports.Foo = "wem";
})(jQuery, window);

Module Pattern

Modules are an integral piece of any robust application’s architecture and typically help in keeping the units of code for a project both cleanly separated and organized. As you build large applications, you will soon realize that it becomes increasingly difficult to keep the code base organized and modular. The module patterns help in keeping the code cleanly separated and organized.

As the variables and functions are contained in the module scope, we automatically prevent naming conflict with other scripts using the same names.

This pattern allows us to focus on which part of the code is exposed out of the class (public elements) and which parts of the code are hidden to the final user (private elements).

The Module Pattern must satisfy the following:

  • Private members live in the closure.
  • Public members are exposed in the return object.

The Module Pattern with Object Literal

It satisfies the following conditions, in addition to the original:

  • Private members are defined in the closure.
  • Public members are defined in the return object literal.
  • References to public members are via this, whenever possible.
var welcomeModule = (function(){
  return {
    name: "John",
    sayHello: function(){ console.log("Hello, " this.name + "!");}
    sayWelcome: function() { console.log( this.name + " Welcome to StackOverflow!");}

in order to make name and sayHello private, the references pointing to nameand sayHello in the various function body definitions also have to be changed.

The Module Pattern with Return Object Stub

It satisfies the following conditions, in addition to the original:

  • An empty return object stub is defined at the beginning.
  • Private members are defined in the closure.
  • Public members are defined as members of the stub
  • References to public members are via the stub object

you can see that public members are directly added to the stub object.

var welcomeModule = (function(){
  var stub = {};
  stub.name = "John";
  stub.sayHello = function(){ console.log("Hello, " + stub.name + "!");}
  stub.sayWelcome = function() { console.log( stub.name + " Welcome to StackOverflow!");}
  return stub;

If you want to make name and sayHello private as before, the references to the now-private members have to be changed.

Revealing Module Pattern

It has a number of advantages over the other alternatives, such as

  • Rename public functions without changing function body.
  • Change members from public to private or vice versa by modifying a single line, without changing the function body.

The RMP satisfies three additional conditions in addition to those in the original:

  • All members, whether public or private, are defined in the closure.
  • The return object is an object literal with no function definitions. All right hand side expressions are closure variables
  • All references are via the closure variables, not the return object.
var welcomeModule = (function(){
  var name = "John";
  var hello = function(){ console.log("Hello, " + name + "!");}
  var welcome = function() { console.log( name + " Welcome to StackOverflow!");}
  return {
    name: name,
    sayHello: hello,
    sayWelcome: welcome

If you wanted to make name and sayHello private, you just need to comment out the appropriate lines in the return object.

In General RMP
var ModuleName = ModuleName || {};
ModuleName.CustomComponent = (function(dependency) {
  var somePrivateProperty = 1;
  var method1 = function() {
  return {

the methods are effectively namespaced inside ModuleName

Other Variations

In production code, however, you would want to use more a standardized approach to create modules. Currently, there are two main approaches to create modules.

  • CommonJS modules are usually more suited for server-side JavaScript environments such as Node.js.
  • Asynchronous Module Definition (AMD) : They are browser-first modules and opt for asynchronous behavior.


Know more

  module_id /*optional*/,
  [dependencies] /*optional*/,
  definition function /*function for instantiating the module or object*/
//You can add a module without dependencies as follows:
  add: function(x, y){
    return x + y;
//The require module is used as follows:
require(["math","draw"], function ( math,draw ) {

ES6 Modules



Namespaces are hierarchical containers for variables and functions. Their main goal is to organize names in order to avoid conflicts and redefinitions. This helps to avoid naming collisions between different parts of an application and other JavaScript libraries that are used, since we only need to keep all the identifiers unique under each different Namespace.

A good example of Namespacing is the mathematical functions and constants that JavaScript provides, which are grouped under the built-in JavaScript object called Math.

Modules avoid name conflicts and redefinitions as well, but they are mainly focused on functionalities; in fact, they provide mechanisms to export functionalities, to allow reuse of code, and to manage dependencies on other modules.

In JavaScript, the window object is also known as the Global Namespace, where each declared variable and function identifier is attached by default. A Namespace can be defined as a naming context where each identifier has to be unique. The main concept of Namespacing is to provide a way to logically group all the related pieces of a distinct and self-contained part of an application.

Designing an application architecture based on Modules and namespacing leads to better code organization and clearly separated parts. In such architectures, Modules are used to group together parts of the implementation that are related, while Namespaces connect them to each other to create the application structure.







Power Of Java 8 Default Method In Spring Controller


Imagine your application has multiple controllers (for Quite a long period of time) for each domain object (EntityOneController, EntityTwoController etc) having its own hierarchy and now a common endpoint has to be added in each controller incrementally, having every thing same however differing in very little aspect.


Lets say that the common endpoint would expose swagger detail for that each entity. One option would be to write the same logic one by one in each controller, however that would duplicate lots of code in every controller.


Java 8  Default Method To The Rescue

Here is the Java 8 Default Interface with Spring @Controller Annotation, as can be seen here it has common implementation, but implementors can provide their custom behavior as well.



public interface SwaggerController { 
  String getName(String foo); 
  @RequestMapping(value = "/swagger/{foo}", method = RequestMethod.GET) 
  default String hyperschema(Model model, @PathVariable String foo) { 
    model.addAttribute("name", getName(foo)); 
    return "welcome"; 

Here is one of the Implementations

public class EntityOneController extends EntityOneBaseController implements SwaggerController { 
  @Override public String getName(String name) { 
    return "Entity1 " + name; 

Endpoint URL would be /entity1/swagger

Here is another implementations

public class EntityTwoController extends EntityTwoBaseController  implements SwaggerController {
 @Override public String getName(String foo) { 
    return "Entitiy2 " + foo; 

Endpoint URL would be /entity2/swagger

We have achieved the same functionality, without duplicating code!


Fixed Delay Scheduling with Quartz


With this (Fixed Delay) kind of scheduling there is always a same fixed delay between termination of one execution and commencement of another, as can be shown in the following image.


Java supports this kind of scheduling inherently through java.util.Timer and java.util.concurrent.ScheduledExecutorService, however achieving fix delay using quartz is not that straight forward (Specially when misfires are considered)

One might consider the easy approach, of rescheduling itself from within the execute method of quartz job.


Here is the implementation, you would keep the reschedule method in util class as static method.


However, a better approach would be to use Quartz listeners:


Here is the implementation of the listener


Here is the usage :


Here is the code for FixdedDelayJobData.java and FixedDelayJobListener.java

Scalable Java Thread Pool Executor

Ideally from any Thread Pool Executor, the expectation would be the following

  • An initial set of threads (core threads pool size) created up front, to handle the load.
  • If the load increases, then more threads should be created to handle the load up to max threads (Max pool size)
  • If the number of threads increases beyond Max Pool Size, then Queue up the tasks.
  • If Bounded Queue is used, and the queue is full then bring in some rejection policy.

The following diagram depicts; only initial threads are created to handle tasks (When load is very low).


As more task come in, more threads are created to handle the load (Task queue is still empty), if total number threads created is less than max pool size.


Task Queue getting filled up if total number of tasks is more than total number of threads (initial + extended)


Unfortunately, Java Thread Pool Executor (TPE) is biased towards queuing rather than spawning new threads, i.e., after the initial core threads gets occupied, tasks gets added to queue, and after the queue reaches its limit (Which would happen only for bounded queue), extra threads would be spawned. If the queue is unbounded then extended threads won’t get spawned at all, as depicted in the following image.


1==> Initial Core threads were created to handle the load

2==> Once there are more tasks than number of core threads, queue starts getting filling up, to store the tasks

3==> Once the queue is filled, extended threads are created.

Here is the code in TPE, which has problem


We have got couple of work around:

Work Around #1

Set the corePoolSize and maximumPoolSize to same value and set allowCoreThreadTimeOut to true.


  • No coding hack required


  • There is no real caching of threads as threads are getting created and terminated quite often.
  • There is no proper scalability.

Work Around #2

  • Override the offer method of delegator TransferQueue, and try to provide the task to one of the free worker threads, return false if there is no waiting threads,
  • Implement custom RejectedExecutionHandler to always add to Queue.


Refer this implementation for more detail


  • TransferQueue ensures that threads are not unnecessarily created, and transfers the work directly to waiting thread.


  • Customized rejection handler cannot be used, since it is used to insert the the tasks to queue.

Work Around #3

Use custom queue (TransferQueue) and override the offer method to do the following

  1. try to transfer the task directly to waiting thread (if any)
  2. If above fails, and max pool size is not reached then create extended thread by returning false from offer method
  3. otherwise insert into queue


Refer this implementation for more detail.


  • TransferQueue ensures that threads are not unnecessarily created, and transfers the work directly to waiting thread on the queue.
  • Custom Rejection Handler can be used.


  • There is a cyclic dependency between Queue and Executor.

Work Around #4

Use Custom Thread pool executor, specially dedicated for this purpose, It uses LIFO scheduling as described in Systems @ Facebook scale

Lightweight Workflow Like Execution Using Dexecutor

Dexecutor can be used very easily for workflow like cases as depicted in the following diagram.


Dexecutor instance is created using DexecutorConfig, which in turn requires ExecutionEngine and TaskProvider, Default Implementation of ExecutionEngine uses ExecutorService, so lets create a Dexecutor Instance first (source code can be found here):

private static ExecutorService buildExecutor() {
   ExecutorService executorService = Executors.newFixedThreadPool(ThreadPoolUtil.ioIntesivePoolSize());
   return executorService;
private Dexecutor<String, Boolean> buildDexecutor(final ExecutorService executorService) {
   DexecutorConfig<String, Boolean> config = new DexecutorConfig<>(executorService, new WorkFlowTaskProvider());
   return new DefaultDexecutor<>(config);

TaskProvider comes into action, when it is the time to execute the task, for this example we will have simple implementation WorkFlowTaskProvider

public class WorkFlowTaskProvider implements TaskProvider<String, Boolean> {

  private final Map<String, Task<String, Boolean>> tasks = new HashMap<String, Task<String, Boolean>>() {

  private static final long serialVersionUID = 1L;
    put(TaskOne.NAME, new TaskOne());
    put(TaskTwo.NAME, new TaskTwo());
    put(TaskThree.NAME, new TaskThree());
    put(TaskFour.NAME, new TaskFour());
    put(TaskFive.NAME, new TaskFive());
    put(TaskSix.NAME, new TaskSix());
    put(TaskSeven.NAME, new TaskSeven());

 public Task<String, Boolean> provideTask(final String id) {
 return this.tasks.get(id);

For simplicity we have implemented Task for each of the tasks (1..7), those can be found here, Most of the task implementations are same except for TaskTwo (if task 2 result is TRUE then tasks 3 and 4 would be executed otherwise task 5 would be executed) and TaskFive (If task 5 is executed (not skipped) then task task 6 would be executed).


TaskFive (TaskThree, TaskFour and TaskSix) overrides shouldExecute() method, to signal if the task should be executed or skipped.


Next step is to build the graph


If WorkFlowApplication is executed, following output can be observed.

Output if TaskTwo result is false

Executing TaskOne , result : true
Executing TaskTwo , result : false
Executing TaskFive , result : true
Executing TaskSix , result : true
Executing TaskSeven , result : true

Output if TaskTwo result is true

Executing TaskOne , result : true
Executing TaskTwo , result : true
Executing TaskFour , result : true
Executing TaskThree , result : true
Executing TaskSeven , result : true




Take Migration Process To Next Level Using Dexecutor

You have Data Migration process, which updates the Application from version X to X+1, by running Migration Scripts (each script consists of sequence of instructions) sequentially, to bring the application to a desired state.


The synchronous process is causing delays leading to unproductive wait times and dissatisfaction from users. There is a need for process to decrease the scripts execution time by running tasks in parallel where ever applicable to come to desired state.

Driving Forces

The following are driving forces behind Dexecutor.

  • Supports Parallel execution, conditionally may revert to sequential execution (provided such logic is provided)
  • Ultra light (Version 1.1.1 is 44KB)
  • Ultra fast
  • Distributed Execution supported
  • Immediate/Scheduled Retry logic supported
  • Non-terminating behaviour supported
  • Conditionally skip the task execution


Incorporate Dexecutor into your script execution logic, additionally distribute the execution using Infinispan, Hazelcast or Ignite. Here is the sample application which demonstrate this functionality, fork it and have fun 🙂

Dexecutor can be used in this case easily by adding an Algorithmic logic on top of Dexecutor which builds the graph based on table names. Lets assume the following scripts:

Script 1 ==> operates on Tables t1 and t2 and takes 5 minute
Script 2 ==> operates on Tables t1 and t3 and takes 5 minute
Script 3 ==> operates on Tables t2 and t4 and takes 5 minute
Script 4 ==> operates on Tables t5 and t6 and takes 5 minute
Script 5 ==> operates on Tables t5 and t7 and takes 5 minute
Script 6 ==> operates on Tables t6 and t8 and takes 5 minute

Normally these scripts are executed sequentially as follows.

Script 1  5 minutes
Script 2  5 minutes
Script 3  5 minutes
Script 4  5 minutes
Script 5  5 minutes
Script 6  5 minutes

Total time 30 minutes 

In sequential case, total execution time would be 30 minutes, However if we could parallelize the script execution, make sure scripts are executed in right sequence and order, then we could save time, decreasing the total execution time to just 10 minutes.

       +----------+                       +----------+
       | Script 1 |                       | Script 4 |             ==> 5 minutes
  +----+----------+--+               +----+----------+-----+
  |                  |               |                     |
  |                  |               |                     |
+-----v----+   +-----v----+     +----v-----+        +------v---+
| Script 2 |   | Script 3 |     | Script 5 |        | Script 6 |   ==> 5 minutes
+----------+   +----------+     +----------+        +----------+

Total Time 10 minutes

Using Dexecutor, we just have to write the algorithm which facilitates building graph using the API exposed by Dexecutor, and rest would be taken care by Dexecutor.  MigrationTasksExecutor implements that algorithm, considering the SQLs in the migration scripts. Since table names in the SQL plays a crucial role in building the graph, we need an efficient, ultra light and ultra fast library to extract table names out of SQLs, and hence we would use sql-table-name-parser, use it by adding the following dependency in your POM.


And of course, Dexecutor should be added as dependency as well


The graph, that would be built, considering the migration script is the following.



As can be seen here node base1, base3 and base 4 runs in parallel and once, one of them finishes its children are executed, for example if node base1 is finished then its children base2 and app3-1 are executed and so on.

Notice that for node app2-4 to start, app1-4 and app2-1 must finish, similarly for node app3-2 to start, app3-1 and app2-4 must finish.

Just Run this class to see how things proceed.


We can indeed run dependent/independent tasks in easy and reliable way with Dexecutor.