wood burning stoves 2.0*
The moose likes Beginning Java and the fly likes Decoupling: Whats the reason? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Decoupling: Whats the reason?" Watch "Decoupling: Whats the reason?" New topic
Author

Decoupling: Whats the reason?

Rah Gupta
Greenhorn

Joined: Nov 20, 2007
Posts: 3
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?

Is the reason correct?

Thanks,
RG
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14192
    
  20

Welcome to JavaRanch.

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.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Rah Gupta
Greenhorn

Joined: Nov 20, 2007
Posts: 3
Thanks a lot guys!
 
GeeCON Prague 2014
 
subject: Decoupling: Whats the reason?