Too Loosely Coupled Code – One Year Later

More than a year ago, I have posted a blog entry related to what I was trying to implement in one of the projects. Unfortunately, not my team could understand what I was trying to do, neither I was able to make myself clear. Either way, I ended up closing the blog with a question “can code be too loosely (coupled), or your code is so coupled, that anything else is difficult to digest?”. Now I can answer my own question question.

Today, my current team had a team learning session, when the latest project demonstration showed what are we doing with a IoC container we started to leverage (StructureMap). The team is not the same one I had back a year+ ago. This team has also had same difficulty in the beginning – code that was too coupled. We have started from “Poor mans’ injection”,  moved to home-grown Dependency Resolver with a typical Startup Task, and now have reached the point, where a third party open-source IoC container is used. I think that could be achieved because:

  • We worked on decoupling code, learning the pros and cons
  • We got to the point were SRP is followed
  • We have got to the point were Design by Contract is almost entirely how we develop
  • We have a complete TDD development in place

So why I could not root the idea in my previous team? Because it was way too early for my team mates and I was not ready to wait.

Oh, and how the code looks now? Even better than before ;)

 

public class ComponentB : IComponentB   
{
  private IComponentA dependency;   
 
  public ComponentB(IComponentA dependency)    
  {   
    this.dependency = dependency;  
  } 
 
  public void SomeFunctionality(string param)
  {
    var result = dependency.OperationDefinedByDependencyContract(param);  
    return DoSomethingWith(result);   
  }
}

Benefits:

  • TDD/BDD development style is enforced better when there’s no default constructor with Dependency Resolver or Poor’s man injection
  • No messy Startup Task that is a must when doing Dependency Resolver
  • Can leverage smarts of IoC container to perform tasks on a massive scale (interceptors, events, etc)
  • Easy way to verify if all dependencies are wired or not (contract based dependencies)

And as one commenter of the original blog post has asked correctly: “The question might be more appropriately be, is the code self-documenting? Can someone who did not write the original code follow the logic and modify and maintain it?”. The answer is: it depends.

You have to get to a certain level to answer Yes. Until you get to that level, the answer will always be No. In order for code to be self-documenting, it needs to be of high quality and accompanied with tests/specifications. In order to be modified, maintained, and logic followed by a person who did not write it, it has to have the listed above AND have the person to be at a certain level of skills.

No Comments