This is my third in series of “reporting”  from Qcon. My earlier posts are here and here.
In this post, I will briefly talk about few Design and Architectural strategies that I came across at Qcon. Some of these were new to me and others I have used\known in some form or other for sometime, but it was good to hear about them as established patterns.
Here goes…

Feature toggle
This is a common problem in Scrum, but I am sure other methodologies can find a spot for this as well. You have two or more features under development – with all code being checked into Trunk (Branches are evil- remember ?) One of the feature reaches the finish line first and is now ready for prime time. The other one is still in progress. How do you now release one feature alone from a trunk which has both features ? One (non-)solution would be to work on feature branches or roll back changes for one feature later on. One of this is ugly and the other is insane.
Consider Feature Toggle.
Continue reading »


This is the ‘eye’ of SOLID software design principles.


Clients should not be forced to depend on methods that they do not use.

Alternate Definition (s):

The dependency of one class to another one should depend on the smallest possible interface

The idea

Consider two components- which interact with each other. The interaction between the two is defined by the API calls that one makes onto another. The component which makes calls to the other serves as the client.

The methods that the client can call upon the component serves as the contract between the two.This contract should be kept thin. It should have all that the client needs- and nothing more. Keep in mind- what the component exposes to the client is not limited only to the interface explicitly implemented by the component – but also included all the behavior inherited by that component from classes\interfaces up the hierarchy

Example of violation

Lets say I have  domain classes- PurchaseOrder, Appointment , Invoice etc. All domain classes  extend the same base class- DomainClass which contains common behavior.

All my domain class can be published to external entities. So we have a  method publish (). Now if we want to keep this behavior internal to these objects- i.e. only the domain classes will decide when its the time to be published- this method should be declared as protected. If we declare this method as public- all clients would have access to this method- if that was not the intention- we have violated the Interface Segregation Principle.

Another common violation is when we have an interface  say Animal with methods – run (); swim (); fly ()

And Classes – Fish , Horse etc.- all implementing the Animal interface

Now since flying is a behavior not exhibited by all animals- we provide a dummy implementation and throw and Error “NotSupported”. This is a voilation of the principle. You have exposed the method fly () to all clients of the class Horse when they didn’t even need it.

In fact – in a twisted sort of way – the Object class,the Parent of all classes in Java, is a violation of Interface Segregation Principle. All methods in Object are exposed to all clients.

The Benefits

This principle is important because it encourages two very important ingredients of a good software design

High cohesion – Keep all related methods together

Low coupling  – Keep dependence of one another to the bare minimum

Changes to fat interfaces tend to cause a ripple affect to classes who shouldn’t have been affected in the first place.


Read more about this from the Master , Robert Martin himself.


Visit to the bank

You walk in to the bank- to deposit cash.

You stand in the line- meet the Teller who does the transaction with you.

Do you really  care whether its Joe or Mary behind the counter?

No. You do not.

Because your contract with the Bank is via the teller (:read interface) not Joe who happens to be there – that day or maybe everyday (:read implementation)

It’s all about the contract

Interface is nothing but a formal contract . All classes which implement that interface- are basically declaring that we will honor this contract and will provide you the service as said by this interface.

The beauty of this paradigm is that – this keeps your two classes blissfully unaware of each other – allowing you to change one without drastically affecting another or at least controlling the affect on another.


Java API is actually full of very good examples of this.

e.g. JDBC Driver . All JDBC applications use the Driver interface – to get a connection etc.

Because we program against this Driver- we do not care what that implementation is.

The implementation could be an Oracle Driver or a MySQL Driver.

Your application would work the same- for both the databases- as long as you have programmed to the interface- without depending upon the actual implementation.

Another example: Java Collection API List,Set,Map Interfaces.

If your classes take as input one of these interfaces- the caller may send you a different class- ArrayList or LinkedList- and you wont notice a thing. That’s why its strongly encouraged that your input parameters or return types should be an interface rather than a class.

And Spring

The best thing I like about Spring is- it strongly encourages you to program to interfaces by using Config files- which bind implementing classes to each other using interfaces

You code uses only interfaces you refer to implementation only in the config file

How do I know if I did program to interfaces or not ?

Look at the input parameters and return type of your public API.

If you return a class rather than an interface- you are exposing your implementation detail.The caller is not programing to your interface -but to your classes.

If the input parameters of your public API is a class- you are dependent upon the internal implementation of the caller- and not on it’s interfaces.

© 2011 Technology Cafe Suffusion theme by Sayontan Sinha