Sunday, 28 August 2016

JavaScript Closure

To understand Closure we have to understand Scope. So first we discuss about Scope then slowly move to Closure.

Scope is a programming language controls for the visibility and lifetimes of variables and parameters.
var foo = function ( ) {

 var a = 3, b = 5;

 var bar = function ( ) {

  var b = 7, c = 11;
  // At this point, a is 3, b is 7, and c is 11

  a += b + c;
  // At this point, a is 21, b is 7, and c is 11
 };

 // At this point, a is 3, b is 5, and c is not defined

 bar();

 // At this point, a is 21, b is 5
};
  Most languages with C syntax have block scope. All variables defined in a block (a list of statements wrapped with curly braces) are not visible from outside of the block. This is a good thing. Unfortunately, JavaScript does not have block scope. JavaScript does have function scope. That means the parameters and variables defined in a function are not visible outside of the function, and that a variable defined anywhere within a function is visible everywhere within the function.

  In many modern languages, it is recommended that variables be declared as late as possible, at the first point of use. That turns out to be bad advice for JavaScript because it lacks block scope. So instead, it is best to declare all of the variables used in a function at the top of the function body.
var myObject = function ( ) {
 var value = 0;
 return {
  increment: function (inc) {
   value += typeof inc === 'number' ? inc : 1;
  },
  getValue: function ( ) {
   return value;
  }
 };
}();
We are not assigning a function to myObject. We are assigning the result of invoking that function. Notice the () on the last line. The function returns an object containing two methods, and those methods continue to enjoy the privilege of access to the value variable.
/*Create a maker function called quo. It makes an object with a 
get_status method and a private status property.*/
var quo = function (status) {
 return {
  get_status: function ( ) {
   return status;
  }
 };
};

// Make an instance of quo.
var myQuo = quo("amazed");
document.writeln(myQuo.get_status());
When we call quo, it returns a new object containing a get_status method. A reference to that object is stored in myQuo. The get_status method still has privileged access to quo’s status property even though quo has already returned.
get_status does not have access to a copy of the parameter; it has access to the parameter itself. This is possible because the function has access to the context in which it was created. This is called closure.

Let’s look at a more useful example : Example - 1 :
var add = (function () {
 var counter = 0;
 return function () {
  return counter += 1;
 }
})();

add();
add();
add();
The variable add is assigned the return value of a self invoking function. The self-invoking function only runs once. It sets the counter to zero (0), and returns a function expression.

Example - 2 :
// Define a function that sets a DOM node's color to yellow and then fades it to white.
var fade = function (node) {
 var level = 1;
 var step = function ( ) {
  var hex = level.toString(16);
  node.style.backgroundColor = '#FFFF' + hex + hex;
  if (level < 15) {
   level += 1;
   setTimeout(step, 100);
  }
 };

 step();
};

fade(document.body);
We call fade, passing it document.body (the node created by the HTML <body> tag). fade() sets level to 1. It defines a step function. It calls step function. It then returns fade has finished.
So we can say, "A closure is a function having access to the parent scope, even after the parent function has closed".

Saturday, 9 July 2016

Dependency Inversion Principle (DIP)

To understand Dependency Inversion Principle (DIP) we need to clear concept about Inversion Of Control(IOC) and Dependency Injection(DI). So here we discuss all about the terms with Dependency Inversion Principle (DIP).
Inversion Of Control(IOC) : The control or logic which is not the part of that entity is taken care by someone else. Or, IOC is a programming technique where the unconcerned LOGIC is delegated/shifted to some other entity.
Dependency Injection(DI) : Dependency injection is a technique which helps to inject dependent objects of a class that makes architecture more loosely coupled.
There are lots of IOC container for .NET framework that helps us to resolved dependency. Some are listed here.

Dependency Inversion Principle(DIP) :

If you search the internet you will get lot's of definition and scratch image to make you understand what is DIP.  
Basically it says :
The principle basically says, Class should depend on abstractions (e.g interface, abstract classes), not specific details (implementations). That means, You should let the caller create the dependencies instead of letting the class itself create the dependencies.  

Wednesday, 25 May 2016

Interface Segregation Principle (ISP)

=> The principle states that no client should be forced to depend on methods that it doesn't use.
=> A client should never be forced to implement an interface that it doesn't use or client shouldn't be forced to depend on methods that they don't use.

Here we give an example of ISP violation and then refactor that violation. Without talking unnecessary things let's jump into the code.

ISP violation :
public interface IMessage{
 IList<string> ToAddress {get; set;}
 IList<string> BccAddresses {get; set;}
 string MessageBody {get; set;}
 string Subject {get; set;}
 bool Send();
}

public class SmtpMessage : IMessage{
 public IList<string> ToAddress {get; set;}
 public IList<string> BccAddresses {get; set;}
 public string MessageBody {get; set;}
 public string Subject {get; set;}
 public bool Send(){
  // Code for sending E-mail.
 }
}

public class SmsMessage : IMessage{
 public IList<string> ToAddress {get; set;}
 public IList<string> BccAddresses {
  get { throw new NonImplementedException(); }
  set { throw new NonImplementedException(); } 
 }
 public string MessageBody {get; set;}
 public string Subject {
  get { throw new NonImplementedException(); }
  set { throw new NonImplementedException(); } 
 }
 public bool Send(){
  // Code for sending SMS.
 }
}
In the SmsMessage we don't need BccAddresses and Subject, but we forced to implement it because of IMessage interface . So it's violate the ISP principle.

Remove violation :
public interface IMessage{
 bool Send(IList<string> toAddress, string messageBody);
}

public interface IEmailMessage : IMessage{
 string Subject {get; set;}
 IList<string> BccAddresses {get; set;}
}

public class SmtpMessage : IEmailMessage{
 public IList<string> BccAddresses {get; set;}
 public string Subject {get; set;}
 public bool Send (IList<string> toAddress, string messageBody){
  // Code for sending E-mail.
 }
}

public class SmsMessage : IMessage{
 public bool Send (IList<string> toAddress, string messageBody){
  // Code for sending SMS.
 }
}
SmsMessage need only toAddress and messageBody, so now we can use IMessage interface to avoid unnecessary implementations.

Monday, 23 May 2016

Liskov Substituton Principle (LSP)


=> Child class should never break the parent class type definition.
=> An object should be substitutable by its base class (or interface).

LSP violation code :
public interface IPersistedResource{
 void Load();
 void Persist();
}

public class ApplicationSettings : IPersistedResource{
 public void Load(){
  // Function definition for ApplicationSettings
 }

 public void Persist(){
  // Function definition for ApplicationSettings
 }
}

public class UserSettings : IPersistedResource{
 public void Load(){
  // Function definition for UserSettings
 }

 public void Persist(){
  // Function definition for UserSettings
 }
}
Use :
static IEnumerable<IPersistedResource> LoadAll(){

 var allResources = new List<IPersistedResource>
  {
   new UserSettings(),
   new ApplicationSettings()
  };

 allResources.ForEach(r => r.Load());

 return allResources;
}

static void SaveAll(IEnumerable<IPersistedResource> resources){
 resources.ForEach(r => r.Persist());
}

IEnumerable<IPersistedResource> resources = LoadAll(); // Should be a happy user with loaded resources

SaveAll(resources); // Should be a happy user with saved persist

Everything works great, until a new class is added to the system inorder to handle, let's add another class "SpecialSettings"
public class SpecialSettings : IPersistedResource{
 public void Load(){
  // Function definition for SpecialSettings
 }

 public void Persist(){
  through new NotImplementedException();
 }
}

static IEnumerable<IPersistedResource> LoadAll(){

 var allResources = new List<IPersistedResource>
  {
   new UserSettings(),
   new ApplicationSettings(),
   new SpecialSettings()
  };

 allResources.ForEach(r => r.Load());

 return allResources;
}

static void SaveAll(IEnumerable<IPersistedResource> resources){
 resources.ForEach(r => {
  if(r is SpecialSettings)
   return;
  r.Persist();
  });
}
Here, marked code is the violated for SpecialSettings(). Because we know An object should be substitute by its base class or interface".

Now it is time to refactor the violation. Let's refactor this violation :
public interface ILoadResource{
 void Load();
}

public interface IPersistedResource{
 void Persist();
}

public class ApplicationSettings : ILoadResource, IPersistedResource{
 public void Load(){
  // Function definition for ApplicationSettings
 }

 public void Persist(){
  // Function definition for ApplicationSettings
 }
}

public class UserSettings : ILoadResource, IPersistedResource{
 public void Load(){
  // Function definition for UserSettings
 }

 public void Persist(){
  // Function definition for UserSettings
 }
}

public class SpecialSettings : ILoadResource{
 public void Load(){
  // Function definition for SpecialSettings
 }
}
Use :
static IEnumerable<ILoadResource> LoadAll(){

 var allResources = new List<ILoadResource>
  {
   new UserSettings(),
   new ApplicationSettings(),
   new SpecialSettings()
  };

 allResources.ForEach(r => r.Load());

 return allResources;
}

static void SaveAll(IEnumerable<IPersistedResource> resources){
 resources.ForEach(r => r.Persist());
}

Friday, 20 May 2016

Open Closed Principle (OCP)

Software entities (class, modules, functions, etc) should be open for extension but closed for modification. Here, we try to explain OCP using codebase. First we'll show a scenario that violate OCP and then we'll remove that violation.

Area Calculation (OCP violation Code) :
public class Rectangle{
 public double Width {get; set;}
 public double Height {get; set;}
}

public class Circle{
 public double Radious {get; set;}
}

public double getArea (object[] shapes){
 double totalArea = 0;

 foreach(var shape in shapes){
  if(shape is Rectangle){
   Rectangle rectangle = (Rectangle)shape;
   totalArea += rectangle.Width * rectangle.Height;
  }
  else{
   Circle circle = (Circle)shape;
   totalArea += circle.Radious * circle.Radious * Math.PI;
  }
 }
}
Now if we need to calculate another another type of object (say, Trapezium) then we've to add another condition. But from the rule's of OCP we know Software entities should be closed for modification. So it is the violation of OCP.

Ok. Let's try to solve this violation implementing OCP.
public abstract class shape{
 public abstract double Area();
}

public class Rectangle : shape{
 public double Width {get; set;}
 public double Height {get; set;}

 public override double Area(){
  return Width * Height;
 }
}

public class Circle : shape{
 public double Radious {get; set;}

 public override double Area(){
  return Radious * Radious * Math.PI;
 }
}

public double getArea (shape[] shapes){
 double totalArea = 0;

 foreach(var shape in shapes){
  totalArea += shape.Area();
 }

 return totalArea;
}
Now when we need to calculate another type of object, we don't need to change logic here (in getArea()), we just have to add another class like Rectangle or Circle..

Saturday, 14 May 2016

Single Responsibility Principle (SRP)

There should never be more than one reason for change anything in software entities (class, function, file etc). A class, function, file etc should have only one reason to change. Let's go through the problem first. Have a look at the code given below :
public class BankAccount
{             
    public BankAccount()  {}

    public string AccountNumber { get; set; }
    public decimal AccountBalance { get; set; }

    public decimal CalculateInterest()
    {
        // Code to calculate Interest
    }
}
Here, BankAccount class contains the properties of account and also calculate the interest of account. Now look at the few change Request we received from business:

1. Please add a new Property AccountHolderName .
2. Some new rule has been introduced to calculate interest.

This are totally different type of change request. One is changing on features; where as other one is impacting the functionality. We have 2 different types of reason to change one class. This violates Single Responsibility Principle.

Now let's try to implement SRP to resolved this violation. Look at the code below:
public interface IBankAccount
{
    string AccountNumber { get; set; }
    decimal AccountBalance { get; set; }
}

public interface IInterstCalculator
{
    decimal CalculateInterest();
}

public class BankAccount : IBankAccount
{
    public string AccountNumber { get; set; }
    public decimal AccountBalance { get; set; }
}

public class InterstCalculator : IInterstCalculator
{
    public decimal CalculateInterest(IBankAccount account)
    {
        // Write your logic here
        return 1000;
    }
}
Now our BankAccount class is just responsible for properties of the bank account. If we want to add any new business rule for the Calculation of Interest, we don't need to change BankAccount class.

And also InterestCalculator class requires no changes, in case we need to add a new Property AccountHolderName. So this is the implementation of Single Responsibility Principle.

We have also used Interfaces to communicate between InterestCalculator and BankAccount class. This will help us to manage dependencies between classes.