The name of the game in software development is to write code that is easily readable and maintainable. To do this programmers have been practicing the art of loose coupling and high cohesion. For those not familiar with those concepts, coupling is the degree by which one piece of code relies on another piece of code to function. For instance, a car relies heavily on an engine to function. This would be an example of “tight coupling”. We know it is tight coupling because we know that a car is dependent on the engine to function. Without it and the car is broken. If we were to move the car somewhere else, we would have to take the engine “class” too. High cohesion is the degree by which a piece of code contains pieces that belong together. The engine has high cohesion because it contains nothing that is not essential to the functioning of the engine. You can’t simply remove a spark plug because it is “extra”.
So as programmers we strive to create classes that don’t rely too much on one another (making them easy to reuse and move from project to project) and they themselves contain only the elements that are essential to the operation of the class.
The other day someone came into the Dream.In.Code web board asking about removing a dependency in their code. They had constructed two classes which both implemented a custom interface and this made for a very loose coupled design… awesome! The two classes handled different ways to send out messages for the user. One would email the message and the other would alert it. To determine which style of message sending the user wanted, the GUI would choose the correct class and save it in a variable of the interface type. Here is the gist of the idea…
private IMessageSender obj;
public void Button_Click(...) {
if (oneCondition) {
obj = new EmailObj("tom@smith.com")
}
else {
obj = new AlertObj();
}
}
public void SendMessage(){
obj.SendMessage("Your message here");
}
The programmer wanted to get rid of the obj part even though this setup is quite loosely coupled. They felt that this GUI was relying on the IMessageSender object to carry out its work. They are certainly right! There is a dependency here. That is why we couldn’t transport these two items (the button click event and the SendMessage method) without also bringing along the IMessageSender interface code and objects along with it.
But this is ok, we strive for loose coupling and that doesn’t mean that there won’t be any coupling! Often times our GUI code, or a controller class, is going to need to know about other classes and rely on them to do the work needed. Perhaps just for message passing, a low form of coupling. EmailObj and AlertObj don’t rely on one another, they are not coupled to one another. We can simply plug in another class that implements IMessageSender and be golden here. Our changes are minimal. Since we don’t know when SendMessage may be called, we would need this obj variable to hold our object for the time being. Even SendMessage knows nothing about what obj really is yet uses it. Truly awesome.
In the end it turned out the programmer was attempting to try and avoid having to make any changes and recompiling. The plugin approach we talk about later in this article might be their best choice then.
Let’s, for a minute, assume that we could have a system with no coupling what so ever. No class knew about any other class. You could relate this to a child with a set of wooden toy blocks. Each block is high cohesion but no block new anything about other blocks. Without some form of coupling from the child nothing could be built. If the child wanted to build a pyramid, it would have to gather some blocks and set them as the foundation and set other blocks on top. Those blocks would still be independent, but the child is putting them in such a way that they would still have to rely on one another to create the structure. In this situation you could say that the child class has to know about the block classes to build the system. I can plug in another block easily, I could change a block’s orientation easily, but when it comes to the system they are dependent on one another to form a pyramid.
What about implementing a plugin type of mechanism? With something like this the GUI could use a unit of code, the plugin, generically and not know anything about how it works. This would free the GUI from needing changes and that would allow for a completely decoupled design right? While this would break the GUI coupling on the classes, the plugin itself is coupling its classes internally. We have just shifted the responsibility from the GUI onto the plugins. Each plugin would have the responsibility of coupling its classes together to form a high cohesion unit. It would be like taking our child’s pyramid, wrapping it up in a package and then giving it to another child. The new child doesn’t have to know anything about the plugin other than perhaps some basic info on how to use it (meta data) but the plugin would bind its block classes together.
So while we can have some pieces of code completely independent of another piece, there are going to be some functions, classes or method that will have to tie them together and make one dependent on the other in some form. We need some form of coupling to keep systems together and functioning. We may have an engine, we may have a car, but it will take a mechanic who knows about both to put them together, show them how to work together to perform.
Don’t be afraid to couple, just do the lowest form of coupling you can given the situation. For further information on the levels of coupling check out the Wikipedia article for Coupling with emphasis on the types of coupling section. Thanks for reading! 🙂
