• Here is the way we used today checking the quality of client side javascript code.

    Launch Firefox, access the site under developing, open Firebug console and run the scripts below:

     for(var property in window){
         console.log(property);
     }
    

     
    We get a list of properties directly defined in window instance, which is the place where all global functions and variables exist.

    Filter out the build in properties and the ones introduced by the external libs, like jQuery, Prototype, and we get all the global functions and variables defined by the team.

    Then ask:

    • Do we have too many of them and is it a sign of lacking encapsulation?
       
    • Are all of them worth being introduced with global accessibility?

     
    We really got some clues of refactoring, cool!

    The key is that try object oriented javascript before the plain global functions and variables run out of control.

     

  • My Object Mother is easily messed up with overload methods

    Object Mother is usually used as a test fixture to create objects for testing purpose. e.g.:

    Contact contact = ContactMother.CreateContact();

    A typical simple contact will be assembled through the call. As project goes on, ContactMother may probabily looks like below:

    CreateContact(string firstName, string lastName)
    CreateContact(string firstName, string lastName, string organizationName)
    CreateContact(string organizationName, string email)
    ...

    Every reasonable combination of parameters may want to overload the method. The class is messed up and becomes hard to use and maintain.

    .NET 3.5 Object Initializer could do a better job than overload methods

    Object Initializer is one of the language enhancements of .NET 3.5, you can create object like this:

    SomeObject object = new SomeObject{Property1 = "foo", Property2 = "bar"};

    It's a short version of creating object with default constructor and setting properties as your needs.

    You may have the feeling that we could create our parameter combination with this much flexible manner.

    Create an Object Builder which holds properties used for creating object

    public class ContactBuilder
    {
    public string FirstName {get; set;}
    public string LastName {get; set;}
    public string EMail {get; set;}
    public string OrganizationName {get; set;}
    // other customizable properties may be used by tests

    public ContactBuilder()
    {
    // set all to default value
    FirstName = "foo";
    LastName = "bar";
    EMail = "foobar@abc.com";
    OrganizationName = "ABC";
    // set other properties...
    }

    public Contact Build()
    {
    // create dependent objects including Organization
    // assemble the final contact with the properties and return it
    }
    }

    Then, contact can be created with any parameter combination:

    Contact simpleContact = new ContactBuilder().Build();
    Contact foobar = new ContactBuilder{FirstName = "foo", LastName = "bar"}.Build();
    Contact contactWithOrganization = new ContactBuilder{OrganizationName = "Freeway"}.Build();
    ...

     

    Combine with a Call-Chain style builder

    Typically, Object Builder build object as below:

    Contact contact = new ContactBuilder()
    .WithName("foo", "bar")
    .WithEmail("foobar@abc.com")
    .Build();

    The trick is obviously returning 'this' in all WithXXX methods.

    The object initializer style builder is very similar as the call-chain style builder, and some time it's meaningful to combile these two. e.g. if you want to add common behaviours into builder as well, like this:

    Contact foobar = new ContactBuilder{FirstName = "foo", LastName = "bar"}
    .AttendAMeeting("Sales Meeting")
    .Build();