I am reading Head first Design Patterns nowadays and I come across command pattern. The example given in the book for command pattern is of a remote where one has to assign different tasks to the different remote buttons. There are some client classes, which are given, that contain the information of switching the various appliances on and off, on a click of a single button of remote.
The remote had 7 slots and for each slot a command was configured. Command contained the details of switching on or off a particular type of equipment. So the code flow is like this
button is pushed cmd.execute() switch on the light Remote --------> Command is assigned the task------->Light(Client class)----->
And hence we achieved the decoupling of the client classes from the remote class.
Now, lets come to my question. It is being very a little hard for me to digest all these. We are saying that we have achieved decoupling but whats the benefit? We have created ourselves a lot of not so necessary classes like commands etc. We have added a little complexity in the total code flow, so if one is going to maintain this code one must be familiar with the command pattern to understand it better.
We are also saying if some new kind of appliance comes in then we won't be making any changes to the remote class and hence the chances of creating any new bug in the remote class are almost zero.
So the whole purpose of this decoupling thing is to ensure that we don't spend time on a class which has already been tested for various functionalities by making any changes in one particular type of functionality? We want to decouple the client classes from the remote class to ensure that if any new client class comes in tomorrow we will be writing new code for the class but won't be changing any existing code and as the existing code has not been touched we are making it easier to maintain?
The main reason for loosely coupling parts of your software is indeed maintenance. If all the parts of your software is tightly coupled, it means that each part depends on how exactly each other part works. It will be very hard to change something in the program, because if you change one thing, you'll need to change lots of other parts too. It will also be very hard to understand what the program does, because if you want to understand what one part does, you'll need to know what all the other parts do too.
So making the dependency between parts in your program as small and clear as possible will help you greatly to write software which is easier to understand and maintain.
Google for "Open Closed Principle" to get lots of interesting stuff on this topic. (It's one of the basic OO design principles.)
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus