Tuesday, October 6, 2009 8:00 PM Sean Feldman

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.

Filed under: , ,

Comments

# re: Too Loosely Coupled Code – One Year Later

Wednesday, October 21, 2009 2:03 AM by Doug Wagner

Good to hear you are continuing to make progress on this. Always something to learn and so little time.

It is not only a certain level of development that applies but having the context and time to understand. Understanding the business domain, the conventions adopted by the team, etc. apply to the context. I think documentation has seldom helped after the passage of too much time whether it is the code, tests, comments or external.

The key is what helps the current team.

Cheers,

Doug