2

To my knoweldge so far I thought that coupling relates to the degree in which two or more classes are "interconnected". In other words in which extent a class makes use of methods or variables of other classes. Our goal in a well designed Software System is of course to keep the coupling low (loose).

I am reading though currently a book, which states explicitly, that the objective of loose coupling is achieved by designing the System, so as every class to use only the API (public methods) of other classes and not directly their instance variables. Consequently the instance variables must be private. If that is the point, what is the difference between loose coupling and strong encapsulation? As far as I am concerned the later refers to encapsulation. What is actually true regarding the above notions of OO Software Development?

arjacsoh
  • 8,932
  • 28
  • 106
  • 166

3 Answers3

4

Loose coupling is more than just using a public API, it's also an ability to understand only that API, and not be dependent on specific implementations. It also includes limiting the amount of change required in dependent code across implementation differences.

Encapsulation isn't just about disallowing direct property access. It also includes making sure that internal data isn't exposed in a way that can cause unintentional behavioral (e.g., returning defensive copies of internal structures), and ensuring behavior, not just data, is properly isolated, and responsibilities are implemented in appropriate places.

Dave Newton
  • 158,873
  • 26
  • 254
  • 302
3

Loose coupling is properly achieved by the judicious application of strong encapsulation. Weak encapsulation may provide loose coupling but may also introduce loopholes that allow for visibility of methods and variables outside of the abstraction's scope (inadvertant tight coupling). Strong encapsulation however, does not imply anything about coupling since a class of this nature can be designed to couple loosely, tightly, or not at all with external entities.

Todd Margules
  • 41
  • 2
  • "Weak encapsulation may provide loose coupling"? How? On condition that instance variables are exposed to client code (weak encapsulation), that leads to tight coupling as well, according to the definition of coupling provided in some books, as I cite it in my question. – arjacsoh Jan 31 '13 at 20:42
  • I've added "inadvertant tight coupling" to the end of this statement as a clafification based on your comment - thank you. One may have intended to implement loose coupling and exposed an API according to those abstactions, but the aformentioned loopholes (due to weak encapsulation) allow for exploitation of code that could result in tight coupling – Todd Margules Jan 31 '13 at 21:21
2

You may achieve loose coupling with strong encapsulation but encapsulation itself does not yet guarantee good code and loose coupling. Despite encapsulation you may still write tightly coupled code.

Loose coupling (a rule that no unnecessary dependencies between objects/modules are introduced) may be achieved without formal encapsulation (accessors/setters and restricted visibility).

But... If you write code for yourself or for a small set of skilled co-developers then referring directly to class members (thus breaking encapsulation) may facilitate keeping code smaller and easier to read and understand. C# has partially done it with properties - they look like plain class members but are in fact accessors and setters.

For bigger teams or reusable code I would say that strong encapsulation is a must. However you should always keep in mind flexibility - if you restrict your API too much it will become unusable. This is especially important if your code is not yet mature enough to handle all use cases with "official" API.

Grzegorz
  • 504
  • 1
  • 3
  • 14