Archive for January, 2011

In any jQuery Plugin there JavaScript local alias pattern is being used as a best practice. They have localized the global jQuery object as an alias $. It is a handy and popular pattern for JavaScript developer however, that is not very well know from C# developers or fledging JavaScript people.
Local alias pattern has 3 benefits:
1)      It allows using short-cut custom name for a global namespace, thus shortening the code writings, page size decreases.
2)      It does not populates the global scope variables
3)      It allows us to make global variable to make it localize and thus faster to refer the variable.
As we know to refer the global variable is slower than to referring the local scoped variable.

See the below example:
(function ($) {
        $.fn.myPlugin : function(){
        …//new plugin code.

In the above code jQuery object is being passed as an argument to the self executing function which is being aliased by $. Therefore, inside the function we can use the alias $ without any hesitation as it is referring to the jQuery object.

If we had just used $ as an alias to jQuery without passing it as an argument and bringing it inside out local scope then there would have lot of chances that in some other JavaScript library $ may be overridden by some other object or value and it might have broke our code.
In below code if you see window object is being passed as an argument.

(function( window, undefined ) {
//jquery code..
// Expose jQuery to the global objectwindow.jQuery = window.$ = jQuery;
}) (window);

By passing one argument “window” while calling it, we are able to localize the window object. The second argument is not being passed therefore; the 2nd parameter would be assigned as undefined.
There is a chance that in somewhere else the undefined is assigned with some other value that may be overridden by the jQuery code therefore, in jQuery function they have made undefined as a local parameter so that they can use the undefined without worrying about the external world.
By making our object locale we are not populating the global scope with other variables.

namespace Rupesh.AliasDemo {
    using System;
    using System.Collections;
    using CountriesCode = Utility.Constant.Countries;

In above code you can see that one alias has been created for Utility.Constants.Countries as CountriesCode.
So now under the Rupesh.AliasDemo namespace in each class, CountriesCode can be used as shortcut alias instead of writing the whole name (Utility.Constant.Countries).
This will make more easiness while writing the code, will save time and number of lines of code.
After knowing this I am vastly using this pattern in my C# as well as JavaScript code.


At the outset, I used to write programs that just work because, I had to complete and deliver the project on time.

I remember, when was assigned a task to create web application that will create New Enrollment request on a given account number. After slogging the whole day, writing code and proper testing, I created one small application that was allowing user to upload an Excel Sheet consisting of list of Account Number. This application iterates through each account number validates and creates one New Enrollment Request on each account. If it fails then moves to create request on next account number without breaking the execution. Application worked splendidly and my manager became happy that I did the job on time and application was working fine… J

As software programmer, you might know that software project never becomes perfect and client requirement never ends. Same thing happened to me and on the next day, my Manager again came and asked to update the application so that it will also create Account Maintenance Request. I worked for that, done changes throughout the application, put everywhere if else condition needed to check the new account maintenance request type, and finally gave him the application. It worked good… But my manager’s expectations never stopped…

In my project work story the pain part was…, for every new requirement in project, I had to change each and every page, class and doing that repetitively made my code much confusing and disordering.

Then I read about the Open/Closed Principle (OCP) of Object oriented programming. This principle states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. What I understood from this principle that software application should be designed such that, if eventually new requirements comes up then project should not allow any changes and it can only be extended.

I planned to re-create my application in such a way that it fits with the idea of Open/Closed Principle. Therefore, implemented Factory Pattern to make project more object-oriented. Converted each request as an object, created one base abstract class (BaseRequest)having one abstract method like CreateRequest inherited by an Interface (IRequest) hence followed Template pattern as well. Created New Enrollment and Account Maintenance classes inherited form the BaseRequest class and implemented the CreateRequest method in each request class. Created one Factory class that returns the required request Object based on the request type and made its return type the interface IRequest that was pointing to the real request concrete object hence maintained the loose coupling architecture.

After doing all above mentioned stuffs, project became more object-oriented and loosely coupled architecture by adhering to the precepts of OCP and factory design pattern. Now, life became little easy, say if some new requirement comes up in future for adding one new request type say “withdrawal request” in project then I just have to introduce one new “withdrawal” request class inheriting with the BaseRequest class, implanting the create request method. Changed the Factory class to return withdrawal request object based on some logical condition. That’s it, my work is done and project is ready. Project became more extendable and less changeable, that is very close to the precepts of Open/Close principle.

After redesigning project, comparatively it required fewer changes and efforts to implement new requirements. However, you can see although after implementing the open closed principle and factory design pattern, I had to change the code in Factory class to handle the new Request added in application. That code modification in factory class was compulsory and it could not be avoided.

I read all design patterns, analyzed my project requirement and made best attempts to make an architecture that will never allow any changes in project under any circumstances for implementing new requirement but, failed.

In order to implement new requirements in existing software project, changes have to be done. However, software architecture should be such that it should allow fewer changes and more flexible to extend.

The moral of the story is obvious that there exist no software program that is 100 % closed for changes and 100% adheres to the Open/Closed Principle.