Hello everyone, in this tutorial I want to provide you with a simple as possible, yet comprehensive enough example of what loose coupling really is and why it’s useful. Understand loose coupling and you’re going to have another advanced software engineering concept under your belt.<\/p>\n
Before we start, I’m going to borrow the Loose Coupling definition from Wikipedia<\/a>: The key takeaway from this is the phrase “little to no knowledge”. Object oriented programming and design offers multiple layers of abstraction for your application. That’s another key-word, “Abstraction”. Everyone who has ever taken a course on OOP or read an OOP book has stumbled upon this word and probably knows how OOP helps you achieve Polymorphism. The benefits of loose coupling include:<\/p>\n \t\u2022 Cleaner Code: After applying loose coupling your code is going to be much easier to read The easiest way to explain loose coupling is actually to explain the exact opposite, tight coupling. Tight coupling is when one or more classes in your application is highly dependent on one or more other classes. Take this class hierarchy for example:<\/p>\n In this simple example, ClassB contains an instance of ClassA and ClassB is responsible<\/strong> for creating that instance. So in this implementation ClassB needs to have knowledge<\/strong> about the inner workings of ClassA. Remember that we want ClassB to have little or no knowledge about how ClassA operates or how its objects get instantiated. The above code using loose coupling will look like this:<\/p>\n An interface, in this very simplistic example called MyInterface, is introduced to solve the conflict. That way, any class that implements IMyInterface can be passed to class B who no longer needs to know how to instantiate it.<\/p>\n To provide a more real-world example, I will create a Console Application project with some rather simple functionality. It\u2019s going to display some to-dos in the console and whether those To-Dos have been completed or not. (The full code of this project can be found here<\/a>).<\/p>\n I’m going to create a “Models” folder to place my ToDo class first:<\/p>\n
\nIn\u00a0computing\u00a0and\u00a0systems design\u00a0a\u00a0loosely coupled\u00a0system is one in which each of its\u00a0components\u00a0has, or makes use of, little or no knowledge of the definitions of other separate components. Sub-areas include the\u00a0coupling\u00a0of classes, interfaces, data, and services.<\/p>\n
\n\t\u2022 More Maintainable Code: Your code will also be easier to change
\n\t\u2022 Testable Code: This is the reason why beginners see no need for loose coupling. Because most beginners do not unit test and don’t know how hard it is to unit test tightly coupled code
\n\t\u2022 Scalable Code: I understand that in a small application loose coupling might not make any noticeable difference but in large scale projects it just makes your life a lot easier<\/p>\n\r\nclass ClassA\r\n{\r\n public ClassA() { }\r\n}\r\n\r\nclass ClassB\r\n{\r\n public ClassB()\r\n {\r\n _foo = new ClassA();\r\n }\r\n\r\n private ClassA _foo;\r\n}\r\n<\/pre>\n\r\nclass ClassA : IMyInterface\r\n{\r\n public ClassA() { }\r\n}\r\n\r\nclass ClassB\r\n{\r\n public ClassB(IMyInterface foo)\r\n {\r\n _foo = foo;\r\n }\r\n\r\n private IMyInterface _foo;\r\n}\r\n<\/pre>\n