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.


This is one of the most powerful principle of OOP.

The Principle

Simply stated- what this means is- once you are done coding an entity – e.g Class,function etc- you should have no reason to modify it again (…hence closed), but that entity should be available for modification via extensions e.g inheritance or any other smart mechanism you can think on (…hence open)

The only exception – when you would ‘open’ the class for changes is- to fix defects. That’s it

And why do we have this principle?

The rationale behind this s pretty simple. If you don’t touch it you can’t break it. It gives you a better and a solid design- which is resilient to changes and is yet adaptive to ever evolving nature of software

In extreme

The principle in extreme would mean- that once you are done with the class- you will never- ever again modify it (unless of course -you find a defect) – What that would mean is – any new method taht you would like to add should go to a different class- because any such change is not a bug-fix and hence is not a change to be made to this class

Hmmm…Sounds a bit extreme to me

I went and took a look at API for java.lang.String

So if Java team has been following this principle- they wouldn’t have added any new method to this class. Any new feature they would want to provide to this class- they would conjure some other mechanism .

Well- they didn’t do that . I found at least 4 new methods added in 1.5.

If you think about it- even though you have technically open the class for modification- you haven’t increased the chance of any new defects getting reported for the existing methods- though yes- as a whole- this class has become more prone to defects- just because it has newer methods added to it

So what really is a problem?

Software are ever evolving. New features are continuously being added, defects fixed, underlying technologies change.

The question is- how adaptive is your software to all this.

Consider a railway booking system. When it was first launched – the only way to book a ticket was via a terminal at the booking office. Later on – support for online booking is added. Now how does your booking engine adapt to this change? Do you go and start changing code all over to accommodate request coming in from a new medium or do you simply plug in new medium to the existing system ?

One good rule of thumb is

Whenever you see code using if- then-else statements or switch statements- you ‘could’ have stumbled upon a violation of this principle (This is not to mean that any usage of these constructs is a violation !!!)

Related Design patterns

Many design patterns help you confirm to this principle. Decorator, Strategy, Chain of Responsibility.


Like I said before- all classes cannot be coded to confirm to the Open Closed principle. You have to pick and choose where would you like to apply these principles. Adding this principles adds complexity- You will want to add to those corner spots which are subject to extensions.

The credits

Dr Meyer- read more about him at wikipedia


If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that

Sounds confusing? It sure does to me at least.

Here is an easier version

If you have sub-classed a given class- in that case any program that uses your parent class via  a pointer or a reference – should continue to be able use any of the sub class that it may get instead of the Parent class- without any change in behaviour.

Now why is this important ?

Polymorphism was designed to provide a run-time binding that would make possible to use a different set of behavior depending upon the context. Which is all nice and cool- except that when you switch the behavior with another behavior which is semantically not compatible with the behavior of the parent class

Example- when its violated

We have a class Product. This has a method- order().The behavior of this method is that it places an order with  the vendor.

Now your inventoryControl System uses many Products and uses this method to order goods.

We decide to introduce a new range of products- Guns.

And since this needs authorization- the Guns class instead of placing the order with the vendor- sends an email to the Manager.

This would serve the purpose of informing the Manager that someone wants to purchase a Gun and may initiate a sequence of events leading to that. But it would create confusion for the system which would be waiting for a conformation from the vendor that the order was placed or may start a check as to why the Vendor hasn’t received an order yet…

Whenever you extend a class and override an already implemented method- watch out.You need to make sure that you are not violating the contract established by the Parent class. In contrast – its OK to override abstract methods.

Design by Contract (Dbc)

This principle leads to a very parallel concept- Design by Contract

What this basically says is – that whenever you subclass-

A) You should not impose newer or  stricter preconditions. Example : The method in the parent class accepts an int type parameter and has no problem with a negative value. If the method in the child class is unable to handle negative parameters while the parent class can- we are violating Dbc.

B) You cant weaken the post-conditions. Example: The method in the base class- places an order with a vendor and send you a confirmation email. If the method in your child class- simply places an order- but fails to send a confirmation email- it is violating Dbc.

On the same lines- a method in the child class- cant throw an exception- which is not in the throws class of the Prent class. The obvious reason is that the programs using references to parent class- would not be coded to handle this exception .

Who do we thank for this ?

Barbara Liskov:

Interactive Software Engineering for Design by contract

© 2011 Technology Cafe Suffusion theme by Sayontan Sinha