5

Can the fact that the business logic is mapped to interfaces instead of implementations actually hinder the maintenance of the application in certain situations?

A naive example with the Java's Hibernate framework would be, that for example (provided I don't have the whole code-base in my head, the project structure is a mess and classes are named with arbitrary names) if I wish to see what's going on in a certain DAO, to see if it actually is doing what it's supposed to do, then instead of traversing backwards up the tree from the point where the data service is invoked (where the tree will end in an interface with no implementation details whatsoever apart from the signature) I have to for example go and look for a configuration XML file to see which class is mapped to said interface as the implementation before being able to access the actual implementation details.

Are there any situations where having loose coupling can actually hurt maintainability?

  • 1
    It primarily depends on the coupling, but yes, loose coupling can definitely hurt. Consider what happens when part of the coupling is maintained in a different language (JSP) or a different form (database tables). How does any sane IDE allow you to backtrace usage? How do you refactor? – BobDalgleish Jun 9 '14 at 13:45
  • Can huge, configuration-based frameworks sitting on top of very verbose languages hurt maintainability? Yes, they can. Can decoupling hurt when using a small set of libraries of a concise language? Probably you have to work very hard to do so. – logc Jun 9 '14 at 15:15
  • What does DAO refer to? – user129679 Jun 10 '14 at 18:24
2

Trade offs are inherent in software design. Decreasing coupling almost always makes it more difficult to find the concrete implementation your code eventually depends on. We accept that cost because it makes it easier to change that implementation and test it in isolation, which minimizes the times we need to find the concrete implementation, and minimizes the ripple effects of any changes we make to it. Don't fool yourself. Just because a cost is worth paying doesn't mean it isn't there.

1

Developing code to an interface is, as far as I know recommended since it allows you to make changes without having to rewrite and/or refactor your code.

That being said, I do believe that having loose coupling can to a certain degree hurt maintainability. The main problem that I see is that people can loose track of what where they doing in the previous methods, which can cause headaches when debugging problems, an overly simplified example would be:

public class Login
{
     public void verifyLogin(...)
     {
         if(VerifyUtlis.isUserValid(...))
         {
             //redirect to home 
         }
         //redirect to somewhere else
     }
}

public class FTPHandler
{
     public void verifyLogin(...)
     {
         if(VerifyUtlis.isUserValid(...))
         {
             //redirect to home 
         }
         //redirect to somewhere else
     }
}

public class VerifyUtils
{
     public boolean isUserValid(...)
     {
         ...
     }
}

When debugging code in VerufyUtils a developer (maybe someone who has just joined) might find it hard to keep track from where he/she got from (admittedly, the above is over simplified, but I hope you understand how things get when you have 100 classes calling each other).

If the developer can have a hard time in tracking what method is used where, any changes he/she makes can potentially make the application unstable. So if you are going for a loosely couple approach, make sure that the code you have and any changes you made are documented. No need to have thousands of words, but usually explaining why things are the way they are (as opposed to writing comments to explain what the code is doing) helps in keeping loosely coupled systems in scope.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.