Loose coupling is a pattern that embraces a high degree of entity separation. It describes a resilient relationship between two or more objects or systems where information can be exchanged or invoked with minimal dependency on one another. The term dependency can be used to describe a number of different aspects of reliance between two things, some of which may be more valid than others. In the case of enterprise development, a dependency is typically used to describe a runtime need for one class by another. The goal of loose coupling is to minimize these runtime links.
When it comes to enterprise development, loose coupling may be one of the strangest shifts you ’ ll make when coding. Up until now you ’ ve likely been quite comfortable with a very traditional flavor of object - oriented programming. You define classes that perform various tasks, and provision them with attributes accordingly. The class might need some form of initialization so that you code a constructor that creates new objects, connects to different services, and populates properties accordingly. This approach is fine for small systems, but it ’ s far from ideal for a large system that interacts with multiple services and consumers. The problem with this approach is that it prevents the creation of autonomous units. Recall that a unit of code is a class or entity designed to perform a single task. If a unit of code requires the consuming of services from other parts of the system, these services should be passed into the unit abstractly. It should never be the job of a unit to create the dependencies it needs.
Right about now you ’ re likely sporting a tightly furrowed brow and a nasty, doubting scowl on your face. Object - oriented design has embraced the heavy constructor model for years. Some of the best books on C++ and C# list countless examples of classes that instantiate their own object instances. After all, isn ’ t that a facet of well - encapsulated design? The answer of course is yes. All of the tenets of OO design still stand firm. Encapsulation and abstraction are still driving factors of your code design. Loose coupling does not aim to bend the time - honored rules of OO design; rather, it serves to embrace them at a new level. It combines OO methodologies and patterns with a much stronger degree of modularity. This approach not only yields much more reusability but also enables the designer to achieve perhaps the most important theme of enterprise programming: testability. To better grasp this concept let ’ s dig into a little bit of code. Think back to the list of discounted auto parts. To simplify the example, we ’ ll just assume that your job is to build a console application that uses a single database connection and a hard coded list of discounts based on geographic region in which a customer resides. We could take the quick - and - dirty approach and just throw all of the code together the non - enterprise way. By that we mean one big block of non modularized code. The code block would likely be placed with a Console application ’ s Main method. It would create all of the requisite ADOET.NET objects needed to extract data from a customer database and then loop through each data row. With each row iteration, the data would be pieced together starting with last name, first name, middle name, and then email address, ending finally with a price calculated on that row ’ s value for the customer ’ s region.
Source of Information : Wrox Professional Enterprise dot NET
When it comes to enterprise development, loose coupling may be one of the strangest shifts you ’ ll make when coding. Up until now you ’ ve likely been quite comfortable with a very traditional flavor of object - oriented programming. You define classes that perform various tasks, and provision them with attributes accordingly. The class might need some form of initialization so that you code a constructor that creates new objects, connects to different services, and populates properties accordingly. This approach is fine for small systems, but it ’ s far from ideal for a large system that interacts with multiple services and consumers. The problem with this approach is that it prevents the creation of autonomous units. Recall that a unit of code is a class or entity designed to perform a single task. If a unit of code requires the consuming of services from other parts of the system, these services should be passed into the unit abstractly. It should never be the job of a unit to create the dependencies it needs.
Right about now you ’ re likely sporting a tightly furrowed brow and a nasty, doubting scowl on your face. Object - oriented design has embraced the heavy constructor model for years. Some of the best books on C++ and C# list countless examples of classes that instantiate their own object instances. After all, isn ’ t that a facet of well - encapsulated design? The answer of course is yes. All of the tenets of OO design still stand firm. Encapsulation and abstraction are still driving factors of your code design. Loose coupling does not aim to bend the time - honored rules of OO design; rather, it serves to embrace them at a new level. It combines OO methodologies and patterns with a much stronger degree of modularity. This approach not only yields much more reusability but also enables the designer to achieve perhaps the most important theme of enterprise programming: testability. To better grasp this concept let ’ s dig into a little bit of code. Think back to the list of discounted auto parts. To simplify the example, we ’ ll just assume that your job is to build a console application that uses a single database connection and a hard coded list of discounts based on geographic region in which a customer resides. We could take the quick - and - dirty approach and just throw all of the code together the non - enterprise way. By that we mean one big block of non modularized code. The code block would likely be placed with a Console application ’ s Main method. It would create all of the requisite ADOET.NET objects needed to extract data from a customer database and then loop through each data row. With each row iteration, the data would be pieced together starting with last name, first name, middle name, and then email address, ending finally with a price calculated on that row ’ s value for the customer ’ s region.
Source of Information : Wrox Professional Enterprise dot NET
