Abstract Factory Vs Factory Method

Many times it seems like factory and factory method pattern are doing the same job. But the evil is hidden in details. Let me show you what I am talking about.

Car Factory Method Story

Consider a factory which is manufacturing cars. It builds different parts of the car such as Door, Steering, Body and Engine etc. Then it puts these parts on to the chassis.

CarFactory

Car factory method class looks like this

    public abstract class CarFactory
    {
        protected abstract string BuildSteering();

        protected abstract string BuildWheels();

        protected abstract string BuildDoors();

        public Car BuildCar()
        {
            var car = new Car();
            car.Steering = BuildSteering();
            Console.WriteLine("Steering is {0}",car.Steering);
            Console.WriteLine("Fit it with Bronze Bolts and Nuts on Chassis");
            car.Wheels = BuildWheels();
            Console.WriteLine("Wheels are {0}", car.Wheels);
            Console.WriteLine("Fit it with Bronze Bolts and Nuts on Chassis");
            car.Doors = BuildDoors();
            Console.WriteLine("Doors are {0}", car.Doors);
            Console.WriteLine("Fit it with Bronze Bolts and Nuts on Chassis");
            return car;
        }
    }    

Note that for all cars the parts are connected to chassis in the same way. All parts will be placed and fastened with bolts and nuts.

Company decided to manufacture sports car which has alloy wheels, fiber doors and power steering. All parts are manufactured and sent to assembly line for adding the parts. Now in assembly line same procedure of fitting these parts are followed (which is fastening with bronze bolts and nuts)

SportCar

So Sports car factory looks like

 public class SportsCarFactory : CarFactory
 {
   protected override string BuildDoors()
   {
     return "Fiber Doors";
   }

   protected override string BuildWheels()
   {
     return "Alloy wheels";
   }

   protected override string BuildSteering()
   {
    return "Power Steering";
   }
 }

codeTry the code here..

Competitor turned up :(

Company opened many similar factories with same assembly operations until one day competitor turned up.

Just like competitor, company decided to manufacture the sports cars and commercial cars differently. They feel instead of using bronze bolts and nuts for sports cars, they can use fiber bolts to give speed advantage. Yeah.. sure.. why not.. But what about Commercial cars? They are built with metal body, and they can not take fiber bolts. Errr… Problem :(

CommercialCar

Why problem? Because you can customize the parts, but can not customize the assembly operations.

 Into New Business with Abstract Factory :)

Company realized they need two different assembly operations for manufacturing cars.  But they are still building cars. Now car factory is just an abstraction. It doesn’t dictate any assembly operations.

 public abstract class CarFactory
 {
    protected abstract string BuildSteering();

    protected abstract string BuildWheels();

    protected abstract string BuildDoors();

    public abstract Car BuildCar();
 }

Now the Sports car factory and commercial car factory look like


 public class SportsCarFactory : CarFactory
    {
        protected override string BuildDoors()
        {
            return "Fiber Doors";
        }

        protected override string BuildWheels()
        {
            return "Alloy wheels";
        }

        protected override string BuildSteering()
        {
            return "Power Steering";
        }

        public override Car BuildCar()
        {
            var car = new Car();
            car.Steering = BuildSteering();
            Console.WriteLine("Steering is {0}", car.Steering);
            Console.WriteLine("Fit it with fiber Bolts and Nuts on Chassis");
            car.Wheels = BuildWheels();
            Console.WriteLine("Wheels are {0}", car.Wheels);
            Console.WriteLine("Fit it with fiber Bolts and Nuts on Chassis");
            car.Doors = BuildDoors();
            Console.WriteLine("Doors are {0}", car.Doors);
            Console.WriteLine("Fit it with fiber Bolts and Nuts on Chassis");
            return car;
        }
    }

    public class CommercialCarFactory : CarFactory
    {
        protected override string BuildDoors()
        {
            return "Metal Doors";
        }

        protected override string BuildWheels()
        {
            return "Alloy wheels";
        }

        protected override string BuildSteering()
        {
            return "Power Steering";
        }

        public override Car BuildCar()
        {
            var car = new Car();
            car.Steering = BuildSteering();
            Console.WriteLine("Steering is {0}", car.Steering);
            Console.WriteLine("Fit it with bronze Bolts and Nuts on Chassis");
            car.Wheels = BuildWheels();
            Console.WriteLine("Wheels are {0}", car.Wheels);
            Console.WriteLine("Fit it with bronze Bolts and Nuts on Chassis");
            car.Doors = BuildDoors();
            Console.WriteLine("Doors are {0}", car.Doors);
            Console.WriteLine("Fit it with bronze Bolts and Nuts on Chassis");
            return car;
        }
    }

codeTry the code here

We turned away from factory method to abstract factory.

Let me know what you guys think.. :)

Blame the Technology..

This is an instance from days when I was spending time in office late night root causing hidden bugs. Our program was running all fine for a month, then used to crash with out of memory exceptions. First response from me is “this .NET framework has bug”. We started root causing it with the help of available memory profilers. Slowly the ugly truth revealed. Its not the framework, but the piece of code which was not in right place was creating lots of weak handles in memory. Finally the memory crash. Fixing the code kept our system for months until any one takes the server for maintenance.

Second instance is when the MSMQ message sent appeared late at destination. Again my first opinion is MSMQ has BUG. We did talk to MS people sending them memory dumps over email. Meanwhile I was reading MSDN documents about MSMQ. After reading forums and documents I learnt that MSMQ is built around TCP/IP. When there are no messages the TCP/IP connection is broken, and re-established when a message arrives. Establishing this TCP/IP connection was taking sometime due to Active Directory authentication. After understanding the underlying design of MSMQ, I found a registry entry for this connection duration. This registry entry was modified to hold the connection for a day. And result was awsome.. Never again we saw the problem. Again I am proved wrong judging the technology and understanding the design.

Now this is an instance from current days. We had a .NET program running on top of communication framework. The framework used MSMQ as transport. The transport was changed to SQL server. Suddenly the program which was performing very well started slowing down. Again I blamed the technology. There was a challenge lying in front of me to fix it. Discussing with team and insight into the business logic showed the way. The program was duplicating the processing n number of times though the response for each input was same. Cutting down that extra processing brought down the latency by 80%.

 In all these situations my first response was to blame the technology. But in the end I am able to get the program healthy. Moral of the story is focus on problem, not on the technology. We can fix either the technology or the design to get the things working.

 Let me know what you guys think :)

Single Responsibility Principle – I Hate It

I am fond of Single Responsibility Principle.. But as the day passed I developed distaste for this principle. Why? The application I was working on grew with huge number of classes and interfaces. Code seemed like a spaghetti code. I started thinking that this principle instead of solving problems adding more to it. None the less the application became loosely coupled but grew into something that is difficult to understand. I would say the code became less cohesive. entangled wires

But I began realizing that the principle is not wrong, but the way I perceived it was wrong. When single responsibility says there should be one responsibility and one reason for change, the questions are

1. What is going to change?

2. What is the responsibility boundary? Is it class, collection of classes, module, collection of module?

If you take the WCF Service which serves product, is it not that the Product service following single responsibility?. When it changes it changes more for the reason that something related to product changed.

Or lets take an example of Employee detail. In order to display employee detail we go through employee UI, employee business layer, data access layer. Each layer is following SRP.

 If you take the employee detail class, you could have methods like GetJoiningDate, GetRelievingDate, GetPromotedDate, GetSalary, GetIncomeTaxOnSalary. All related to employee and I can argue that the only reason it could change is when I want to modify the employee related rules. That is perfectly normal.

And instead what I did is I over imagined that Dates and Salary are not same thing of an employee. Why not break it into EmployeeSalary and EmployeeChronology? We got 2 classes now. And when I am thinking in-terms of EmployeeSalary I feel that IncomeTax could be calculated annually and monthly. OOpss.. we need another class EmployeeIncomeTax.  Now we got 3 classes. Now employee could be rewarded with bonus. Argh.. Yes we need another class. EmployeeBonus. We made 4 classes. Employee could leave and we need to calculate his settlement and dues.. Ah.. Its a good idea to break it into another class EmployeeSettlement. We got 5 classes. See.. this is what happens when single responsibility boundary is not fixed :)

But notice that all these classes in reality are representing behaviors. Does this behavior change more often? Do you think you need to break classes this way where behavior wont change in another 100 years? Design principle says what changes should be kept apart from what doesn’t change.

If its not going to change then I am happy with Employee detail class. If the way the bonus is calculated more often changes , you got to change the logic more often, then move it apart.. How often bonus rules change is the call of the business.

Now easier it is to move the parts apart as long as you maintain unit tests. Otherwise you are on your own when playing something like this.

Thanks for reading.. Let me know your thoughts.

 

Writing Custom Framework – Good Or Bad

As per wiki framework is “an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software”  Interesting here is to see the word abstraction. What is abstracted by the software? 

Windows Communication Foundation (WCF) abstracts communication mechanism. Developer can use this framework to build applications which can talk to each other. WCF abstracted various communication mechanism such as MSMQ, HTTP, TCP. Also the framework addressed the concerns such as security, serialization that revolve around the communication requirements.

Similarly there are various frameworks for building UI such as MVC, ASP.NET, WPF so on. On top of these framework people try to write their own custom framework. Ofcourse the custom framework written on top of these various framework do fit the domain, but did anyone  consider the downside of it?

One of My experience with custom framework is awful. The framework offered nice features such as caching, hosting service and what not. I had installed windows azure bus on my machine. And the custom framework I was using started breaking. Having no clue and no one to go to, I had to debug into the framework code. I did find a place where this heavy weight custom framework is scanning all communication channels. Framework picked azure bus as its communication mode, and was missing configuration for it. I am sure the guys who wrote framework missed this scenario which could happen, and did not add configuration for it.  

What is the result of this mishap? The framework which is intended to reduce development time added hurdles to it. I spent first half of day contacting the framework developers, and then second half of day debugging the framework myself. 

The funny part is framework developers could not root cause the problem because there was no windows azure bus installed on their machine. More embarrassing is to say “it doesn’t work on my machine, but works everywhere else”

Like the framework definition goes the framework should solve the problem for only one abstraction (single responsibility). Does wiki say abstractionS? Should the framework choose the communication channel for the user, or user should choose the channel :)? 

 

Testable Objects

I have seen companies where unit testing is a theory than practice. Some think that creating a unit testing project in Visual Studio is unit testing.

What is unit testing then? Like a building constructed brick by brick, software is built with classes. Similar to faulty bricks can cause damage to the structure of the building, a badly written class can harm the application code.

I started my career writing bad code, and improved my coding style with constant learning under great Teachers. I know what is a bad code because I have written lot of it :D

So how do we write testable code?

Lets take a simple example of layered architecture which is very much prevalent in the industry. A three layer architecture will have Data Access Layer (DAL), Business Layer (BL) and Presentation Layer (PL).
So sample code looks like as shown below.


class Program
    {
        static void Main(string[] args)
        {
            PresentationLayer presentationLayer = new PresentationLayer();
            presentationLayer.Call();
        }
    }

    class PresentationLayer
    {
        BusinessLayer _businessLayer = new BusinessLayer();

        public void Call()
        {
            Console.WriteLine("Presentation Layer Called");
            _businessLayer.Call();
        }
    }

    class BusinessLayer
    {
        DataAccessLayer _dataAccessLayer = new DataAccessLayer();
        public void Call()
        {
            Console.WriteLine("Business Later Called");
            _dataAccessLayer.Call();
        }
    }

    class DataAccessLayer
    {
        public void Call()
        {
            Console.WriteLine("Data Access Layer Called");
        }
    }

Presentation layer makes a call to business logic layer, which in turn calls data access layer. Now unit testing means we should be able to test single functionality of one class. Can we test the call in business layer without having reference to data access layer? To make matter worse data access layer will mostly be written tightly coupled with database. So you can not test business layer until you have the  data access layer and database.

Still this is a not a convincing answer for having unit test? Then answer to question “how do you test all business scenarios around the BL?” could be more reasonable :)

Without unit test, business scenarios will be lost under the pile of code. And no one in the team can be sure that they did not break the component they touched.

To make the component testable one of the technique is to use Dependency Inversion Principle. With dependency inversion principle, we are going to compose the class as shown below.


class Program
    {
        static void Main(string[] args)
        {
            IDataAccessLayer dataAccessLayer = new DataAccessLayer();

            IBusinessLayer businessLayer = new BusinessLayer(dataAccessLayer);

            //We are composing the object
            PresentationLayer presentationLayer = new PresentationLayer(businessLayer);

            presentationLayer.Call();
        }
    }

    class PresentationLayer
    {
        IBusinessLayer _businessLayer ;

        public PresentationLayer(IBusinessLayer businessLayer)
        {
            _businessLayer = businessLayer;
        }

        public void Call()
        {
            Console.WriteLine("Presentation Layer Called");
            _businessLayer.Call();
        }
    }

    interface IBusinessLayer
    {
        void Call();
    }

    class BusinessLayer : IBusinessLayer
    {
        IDataAccessLayer _dataAccessLayer;

        public BusinessLayer(IDataAccessLayer dataAccessLayer)
        {
            _dataAccessLayer = dataAccessLayer;
        }

        public void Call()
        {
            Console.WriteLine("Business Layer Called");
            _dataAccessLayer.Call();
        }
    }

    interface IDataAccessLayer
    {
        void Call();
    }

    class DataAccessLayer : IDataAccessLayer
    {
        public void Call()
        {
            Console.WriteLine("Data Access Layer Called");
        }
    }

Our sample unit test around business layer with a stub data access layer is as shown below.


[TestClass]
    public class UnitTest1
    {
        public class DataAccessStub : IDataAccessLayer
        {
            public void Call()
            {
                Console.WriteLine("Data access stub called");
            }
        }

        [TestMethod]
        public void TestCall()
        {
            IDataAccessLayer dataAccessLayer = new DataAccessStub();

            IBusinessLayer businessLayer = new BusinessLayer(dataAccessLayer);

            businessLayer.Call();
        }
    }

Instead of using database dependent data access layer, we are using DataAccessLayerStub. We can now test all business scenarios around the business layer with the help dependency inversion principle.

I will explain more about stub in my next post. So keep watching :)

Tell, Dont Ask? Do we care?

Tell Don’t Ask Programming was something I never considered until I came across it.  I was designing the classes in a way I liked, without ground rules of OO programming.

Just like you got rules in every game, Object Oriented programming has its rules. One such rule is Tell Don’t Ask.

To give a background, lets take a problem. A software developer goes to his company. His Manager comes in, and asks him where is his computer. Then he asks him what are his log in credentials. Then he asks him how to write a program. Then he asks him how to compile it, and on and on. Basically Manager is taking up the developer’s  responsibility.

So our program looks like this.


    public class Manager
    {
        Developer _developer = new Developer();

        public void GetTheSoftwareProjectDone()
        {
            string loginName = _developer.LoginName;
            string computer = _developer.Computer;
            string programming = _developer.ProgrammingConstructs;
            string ideRules = _developer.IDERules;
            Console.WriteLine("Software written by Manager using all the above details from developer");
        }
    }

    public class Developer
    {
        public string LoginName { get; set; }

        public string Computer { get; set; }

        public string ProgrammingConstructs { get; set; }

        public string IDERules { get; set; }        
    }

Instead Manager should Tell developer to write the program instead of asking him too many questions :).  Developer’s reaction will be Tell, don’t ask :D

Lets illustrate it through the program.


    public class Manager
    {
        Developer _developer = new Developer();

        public void GetTheSoftwareProjectDone()
        {
           var software = _developer.WriteProgram();
        }
    }

    public class Developer
    {
        private string LoginName { get; set; }

        private string Computer { get; set; }

        private string ProgrammingConstructs { get; set; }

        private string IDERules { get; set; }

        public string WriteProgram()
        {
            Console.WriteLine("Software written by Developer using all the above details");
            return "Software";
        }
    }

Notice the details for writing the program is private to developer. Manager will tell the developer to write the software. Manager is only interested in the running software, and not the internal details of it. Developer writes the software and gives it to manager.

Best designed class will have high cohesion with all its responsibilities held in it. Internals of how it achieves this responsibility is not accessible to outside world.

Will discuss more rules in the coming posts. Let me know what you guys think :).

DDD – What is it?

Lots of buzz around DDD (Domain driven development). The concept most elaborately explained by Eric Evans in his book

I am not an expert in DDD, but have some feel of it which I would like to share here. Usual practice of web software development is 3 tier architecture. You got a business layer, data access layer and presentation layer. When developer writes code, he thinks only in terms of which table he is accessing, which component he is calling. This mental model of developer makes the real business cases invisible in the code. Code doesn’t reflect what business rule says. Eventually the business scenario will be lost under the code that no one can remember.

Not only helping preserve the business cases in the code, DDD helps developer and business speak the same language. Both communicate with each other using common language called ubiquitous language. Requirement gathering, and customer evaluations will be easy when both speak the same language.

DDD also helps in defining the boundaries across the domain using bounded contexts. Each context is bound for a given scenario. For example, customer is opening a savings account that is linked to his home loan account. There are two contexts

1. Customer opening a savings account

2. Customer’s home loan account

In the scenario when home loan is deducted from savings account, two contexts work with each other.  That makes both of them in one bounded context.

Similarly DDD will help in identifying the bounded contexts, which will help application maintenance and enhancements.

DDD helps work with domain objects. Domain objects are mostly the ones whose names are  nouns in the domain. For example if you say person is  a senior citizen, you can see two objects

1. Person

2. Citizen

Seniority can be treated as an attribute.

These are some of the things I could recollect from DDD. For more information and detail you can read the book by Eric Evans.  http://domaindrivendesign.org/books/evans_2003