Prototypical inheritance in JavaScript

Read full post on falafel blog

Before we can understand prototypical inheritance, let us start with a problem statement. You have a student for whom you need to:

  • Calculate their grade
  • Print the grade

In JavaScript this can be simply implemented as follows:


var studentMarks;
var studentGrade;

function FindGrade(studentMarks) {
    if (studentMarks >= 80) {
        studentGrade = "A";
    }
    else {
        studentGrade = "B";
    }
}

function PrintGrade() {
    console.log("Student Grade is " + studentGrade);
}

FindGrade(60);
PrintGrade();

There are some inherent problems in the above approach:

  • Variables are defined globally
  • Code maintenance is tough as the functionality grows
  • Code debugging is tough
  • Code testing is tough

The major problem in the above code is that neither the PrintGrade nor the FindGrade functions are reusable. Any future requirements in the find grade logic or in the print logic will require a change in the existing code, and that may introduce new bugs and require testing again. As a developer we may not want this.

Let us go ahead and refactor above code as follows:

Read full post on falafel blog

Decorator Pattern in C#

Read full article on Falafel blog

Decorator pattern attach additional functionalities or responsibilities to an existing object at the runtime”. It adds new behaviour to an individual object without affecting other objects of the same class. New behaviour or functionalities can be either added dynamically at the run time or statically.

image

The decorator pattern:

  • · Adds new functionality or behaviour
  • · Either at run time or statically
  • · Without affecting other objects of the class
  • Why do we need this pattern?

    To understand, let us consider a Student object with the basic responsibility to handle and print information like name, age, and grade etc.

    Now you have a requirement to add functionality to maintain lab reports for Science students. How will you do this? Maybe extend the Student class to create a ScienceStudent subclass for this responsibility. Good enough.

Read full article on Falafel blog

Implement Step-by-Step Generic Repository Pattern in C#

Read full article on Falafel blog

It is not a good idea to access the database logic directly in the business logic. Tight coupling of the database logic in the business logic make applications tough to test and extend further. Direct access of the data in the business logic may cause problems such as

  1. Difficulty completing Unit Test of the business logic
  2. Business logic cannot be tested without the dependencies of external systems like database
  3. Duplicate data access code throughout the business layer

Without a Repository, an application will be seen as below:

image

Repository Pattern separates the data access logic and maps it to the entities in the business logic. It works with the domain entities and performs data access logic. In the Repository pattern, the domain entities, the data access logic and the business logic talk to each other using interfaces. It hides the details of data access from the business logic. In other words, business logic can access the data object without having knowledge of the underlying data access architecture. For example, in the Repository pattern, business logic is not aware whether the application is using LINQ to SQL or ADO.NET Entity Model ORM. In the future, underlying data sources or architecture can be changed without affecting the business logic.

Read full article on Falafel blog

Keep your code DRY

Other day my Boss was reviewing the code written by me. He had a feedback, keep the code DRY. It was great feedback, and I thought why not to share with you that what does DRY mean?

DRY stands for Do not Repeat Yourself.

clip_image002

To understand it better let is consider below code snippet:

clip_image003

I am fetching a particular movie on basis of the id. As you notice this code is inside Details method. Next in another method Edit in the controller and I am doing the same fetching a particular movie on basis of the id as shown below:

clip_image004

As you clearly notice that I am repeating the code in the same class hence CODE IS NOT DRY in above scenario. The code should not be repeated and should be kept in repository class. We could have a function FindById() in MovieRepository class and both the methods will call FindById(). A common function to find the movie by id can be created as follows:

clip_image006

And then both methods of Controllers can use them as follows:

clip_image007

In the layered architecture approach DRY code is very essential for robust software development. I hope now you have better understanding of having code DRY and you will follow this approach.

Happy Coding.

Revealing Module Pattern in JavaScript

We talked about Prototype Pattern in previous posts. You can read them at below link.

Understanding Prototype Pattern in JavaScript

Understanding Prototype Pattern in JavaScript: Part # 2

Revealing Module Pattern allows us to achieve

  • Singleton object
  • Private Public behaviour of functions and properties in the object.

Let us consider the usual code we write. We also known as that functional spaghetti code.


var basicSalary;
 var salary;
 function CalculateSalaray(basicSalary) {
 salary = basicSalary * 10;
 }
 function PrintSalaray() {
 alert("Salary is " + salary);
 }

CalculateSalaray(200);
 PrintSalaray();

There is nothing wrong in above code snippet. However,

  • It is hard to maintain when functionality grows
  • It is hard to debug
  • It is hard to test

In Revealing Module pattern we put all code inside a function represented by a variable. This is self-executed function.

image

Revealing module pattern allows us

  • To achieve public private members
  • To make code more readable

In this pattern we put all functions and variable inside the object. In above case everything would be encapsulated inside salary object. To make anything public we need to make them part of return statement.


var salaray = function () {

//Private
 var sal;
 function calculateSal(basesal) {
 sal = basesal*1000;
 }

function printSal(basesal) {
 calculateSal(basesal);
 console.log(sal);

 }

 //Public

return {
 PrintSalary: printSal

 };

}();

salaray.PrintSalary(2000);

 

In above code snippet we have two private functions. One of private function is exposed at public in return statement. Since object is wrapped as self-executable function hence it works as singleton. We can call public functions on object itself.

If we want to remove singleton then two steps need to be followed,

  • Remove self-executable code
  • Create new object using new operator.

So above object salary can be modified as below. Now it will have private public property but it would not act as singleton


var salaray = function () {

//Private
 var sal;
 function calculateSal(basesal) {
 sal = basesal*1000;
 }

function printSal(basesal) {
 calculateSal(basesal);
 console.log(sal);

 }

 //Public

return {
 PrintSalary: printSal

 };

};

var mysal = new salaray();
 mysal.PrintSalary(789);
 var mysal1 = new salaray();
 mysal.PrintSalary(100);

 

In above code salary object is not a singleton and having private and public functions. In many terms Revealing Module pattern can be considered as one of the best JavaScript pattern. Three advantages of using Revealing Module Pattern are as follows,

  1. Achieve Singleton
  2. Get Private –Public method behaviour
  3. Better readability of code

I hope you find this post useful. Thanks for reading.