Monday, May 26, 2014

Loosely-coupled code - what does it really mean?

What is "loosely-coupled" code?

  • Does this mean it is configurable?
  • Is loosely-coupled code necessarily a product of a smart developer?
  • Is the code loosely-coupled because you used a cool new feature in your platform?
  • Does it mean that you used a cool design pattern?


A lot of times we developers believe that if you write code that is configurable, it is automatically loosely-coupled code. The configuration is sometimes taken to extreme levels that it takes a long time to edit configuration files or configuration tables in database. It gets so complicated that for example the XML configuration in the config files becomes its own programming language that a human cannot maintain properly.

Let me answer one of above questions. No, a configurable application does not necessarily have loosely-coupled code.

Let me use the following analogy. Let's say you have a car engine with all necessary parts: the engine block, alternator, water pump, air filter, radiator and other parts. You can decide to change your air filter and replace it with another stock filter or an aftermarket filter. If you decide to change the water pump, any mechanic can change that easily for you. The conclusion is that you can change some stuff without major re-work; this is a good example of how things are configurable down at the low-level (i.e. changing an air filter with a different one), but the configuration here does not mean that the overall design of this engine and other parts is loosely-coupled. What would make it more loosely-coupled? If I wanted to change the location of the air filter totally, can I do that? If I wanted to change the location of the water pump, can I do that easily. None of this would be a simple task and it would require some major re-work.

The same applies to software applications. Let's say you developed an application and this application performs a set of tasks. I am sure you would make the items configurable within each task and that you would make some high-level features in the application configurable, but does it really make it loosely-coupled? You need to take it a step further. What about if I asked you that I don't want to be forced to use all the these tasks and that I want to build another smaller application that would only perform a smaller number of tasks of my choice. Would I be able to do that easily? If your response is that you have to re-work some of your code to make it reusable, then we know that the code is not loosely-coupled enough.

If I had to describe "loosely-coupled" code in a few bullet points, I would say the following:
  • modular
  • integration points would need to be as weakly typed as possible
  • keeping it simple
  • coding to solve a problem and not to use features from a programming tool that are cool.
  • usage of enterprise products instead of re-inventing the wheel, but not marrying yourself too much with third party tools
What does "modular" mean? It does not mean that you just break your code into methods/function. It means that you break it into meaningful modules that are small enough that you can utilize as building blocks.

Integration points? If you component X is making a call to a web service Y, you need to design it in such a way that you don't have to introduce new signatures of your methods every time a new requirement comes your way. You could use the concepts of overloading and utilizing the code between the overloaded methods; however, if you find yourself overloading too much, then you need to question your design.

Keeping it simple? It is exactly what it says: "simple". Don't get over-excited and start over-configuring things and making the code less maintainable. Step back and think about your fellow teammates and ask yourself: "what trouble would my teammate need to go through in order to work in this code that I am about to write?". How would they feel making changes in this code 6 months from now? There is more on this in this post:  Keeping it Simple.

Coding to solve a problem instead of coding to use new features from a programming language/tool?? A lot of times we developers fall in the trap of wanting to code on the new stuff or the cool stuff; this is what looks good on our resumes. When you have a problem to solve, we need to focus on coming up with a solution and if that solution ends up being a specific design pattern and a use of a specific feature in your selection of tools, that is great; however, please don't start by saying "let me see what design pattern or tool I should use to solve the problem".

If all of the above is done right, then you have more loosely-coupled code and the key word is "more" because there is no code that is perfectly loosely-coupled. It is a constant learning process for all of us, and keep in mind that the code is as good as it is maintained.

Thanks for reading and Happy Coding !!!
Almir


- almirsCorner.com -

#programming #programmer #softwareengineering #softwaredevelopment #architecture #tools #designpatterns #keepitsimple #code #coding #coding101 #programming101




No comments:

Post a Comment