Easy programming: Improving application flexibility by streamlining software dependencies

This article discusses:

The error of tightly coupled architectures

Testing and dependency disaster

Dependency inversion

Dependency Injection

This article uses the following techniques:

The. NET Framework

Almost everyone thinks it's unwise to pursue loosely coupled design. Unfortunately, the tight coupling of the software we are designing usually goes well beyond our expectations. How do you know if the design is tightly coupled? You can use static analysis tools such as ndepend to analyze dependencies, but the easiest way to understand the degree of coupling in an application is to try to instantiate a class independently.

Select a class from the business layer, such as Invoiceservice, and then copy its code into a new console project. Attempt to compile it. You are likely to lose some dependencies (such as Invoice, Invoicevalidator, and so on). Copy these classes to the console project and try again. You will also find that other classes are missing. When the final executable is compiled, you may find that most of the codebase already exists in the new project. It's like pulling a loose thread out of a sweater to remove the whole outfit. In your design, each class is directly or indirectly coupled to other classes. Changing such systems is really difficult because changes in any one class can be implicated in the rest of the system.

The point of solving this problem is not to completely avoid coupling, because that is impossible. For example:

String name 

= "James Kovacs";

I've coupled my code to the System.String class in the Microsoft®.net Framework. Isn't that right? I don't think so. The likelihood of unexpected changes to the System.String class is very low, and there are few ways that you might want to change the way I interact with System.String. So I'm pretty relieved about the coupling. The purpose of this example is to point out that coupling is not blindly eliminated, but to understand it and ensure that it is wisely chosen.

Take another code that often appears in many application data tiers:

SqlConnection conn = new SqlConnection

(connectionString);

Or the following code:

XmlDocument settings = new XmlDocument ();
Settings. Load ("Settings.xml");

How sure are you that the data tier will only interact with SQL server® or always load application settings from an XML document named Settings.xml? Our goal is not to build a generic framework that is infinitely extensible but extremely complex and unusable. But it is related to reversibility. Can you easily change your design decisions? Can your application architecture respond well to changes?

Why do I care so much about change? Because it is the only thing in this industry that does not change. requirements, technology, developers, and businesses are changing. Are you prepared for the contingency? By creating loosely coupled designs, software is better able to respond to inevitable changes that cannot be predicted many times.