Practical .NET

Best Practices for Loosely Coupled Classes

In an object-oriented world you create flexible applications by combining objects. You'll want to keep those objects loosely coupled, though, so that a change in one class doesn't force you to rewrite every class. Here's how to keep them loosely coupled.

• By Peter Vogel
• 10/10/2016

When one object (the "client") uses another object, we say that the client has a dependency on that other object because changes in that "other object" may force changes to the client using it. If your goal is to create loosely coupled applications, managing these dependencies is a critical issue: If you're not careful you can so tightly couple the classes that make up your application that changes in one class end up rippling through your whole application, forcing changes in multiple locations. This is why an application's maintenance costs can skyrocket.

One best practice (which I've discussed elsewhere) is to follow the Interface Segregation principle: Organize the members of the "other class" into a series of interfaces that contain all -- and only -- the members that particular clients need. This ensures that a client only needs to be changed if a member in the interface it uses changes (and, ideally, that change is forced by the client changing its requirements -- see the same article for a discussion of the Dependency Inversion principle). Following these principles gives you some flexibility in how the other class can be enhanced without impacting every client that uses it.

When you follow the Interface Segregation principle, code in the client only refers to the other object using an interface. It's the difference between the client having this code:

Dim so As SalesOrder
so = New SalesOrder("A123")

or this code:

Dim so As ISalesOrder
so = New SalesOrder("A123")

But, while protecting yourself against enhancements to the other object is a good start, for maximum flexibility you also want to give yourself the flexibility to replace the other class with a different class. Simply declaring variables with interfaces isn't going to do that. The reality is that loose coupling is primarily driven by how the code in the client acquires its dependencies on those other objects, not in how the variables are declared.

Two Kinds of Dependencies
Fundamentally, there are two ways that a client can acquire a dependency on another object:

• The client can instantiate (or "new up") the other object
• The client can be passed the other object from some outside source

These days, newing up an object may not be considered a bad practice but it's certainly considered to have a definite code smell. The reasoning is that, once you write the code to instantiate a particular class, you're now stuck with that class. If you want your client to use a different class then you'll have to rewrite, recompile and redeploy your client. As a result, it's now considered a better practice to manage your dependencies by calling some static method on a "factory" class and delegating the work of instantiating the other class to that factory. Coupled with using interfaces, this gives you the ability to replace one object with another object.

What we have, then, is the difference between this old-fashioned code:

Dim so As SalesOrder
so = New SalesOrder("A123")

and this newer, more "with-it" code:

Dim so As ISalesOrder
so = SalesOrderFactory.GetSalesOrderById("A123")

Because my so variable is declared using the interface ISalesOrder, the factory method GetSalesOrderById doesn't have to return any particular class: The factory method can return any class … just so long as that class implements the ISalesOrder interface.

There's another benefit to this design if you use Test Driven Development (TDD): Using factory methods and interfaces makes TDD considerably easier. In my test methods, I can, for example, swap out the factory that retrieves SalesOrders from the database for some mock factory. That mock factory can return a class that implements the ISalesOrder interface but is designed to let me test how my application deals with a salesorder-related scenario (a sales order that's slipped past its "guaranteed delivery date," for example).

The Next Step: Configuring Objects
Applying this approach does lead to other changes in your application because that SalesOrder class may, itself, have quite a lot of dependencies. This is especially likely if you're applying the Single Responsibility principle that says each class should do one thing and one thing only. It's considered better, under this principle, to have lots of simple objects that you can combine in interesting ways than to have fewer, more complicated objects.

As a result of applying the Single Responsibility principle, that SalesOrder object might well use a Customer object, a couple of CustomerAddress objects (one for shipping and one for billing), a Shipping object that calculates shipping costs, and a Billing object that ensures that accounting information is maintained … and that's probably not all. Developers now need to "configure" the SalesOrder with the right set of objects before they can use it.

But if you move to a design that requires configuring objects, you don't want to end up saying to a developer that needs a SalesOrder, "OK, when creating a SalesOrder, don't forget that you have to go get the relevant Customer, Billing, Shipping, and CustomerAddress objects and stuff them into all the right places in the SalesOrder object." Forcing the developer who just wants to use SalesOrder object to correctly assemble all that would just be mean. It would also spread that configuration code throughout the company, repeating it wherever a SalesOrder object is needed. There's also a real chance that different developers might configure the SalesOrder differently (I'm trying to avoid saying that a developer might configure the SalesOrder "wrongly").

The current "right answer" is to have a factory method that not only creates the SalesOrder but also configures it. Centralizing that configuration code in a GetSalesOrderById method not only simplifies life for the developer who needs a SalesOrder object but also helps ensure that every SalesOrder object is always created correctly. Centralizing the SalesOrder configuration code also makes it easier to change the code by centralizing it into a single place -- the factory method. Again, this design supports TDD because it allows you to create special factory methods to support specific tests.

Isolating Configuration from Data Retrieval
The first step in my factory method is to retrieve the "base" SalesOrder object (that is, the object before configuration) from the database. These days, to retrieve the original SalesOrder object, I'll probably be using Entity Framework and LINQ. However, I won't put that code into this factory method. Instead, I'll have a SalesOrder repository object that handles communication with my database. The first lines of my factory method, therefore, look like my revised client code because they call a method on a repository class:

Dim so As ISalesOrder
so = SalesOrderRepository.GetSalesOrderById(Id)

Again, this is the result of applying the Single Responsibility principle: My SalesOrderFactory is responsible for correctly configuring (and otherwise managing) my SalesOrder objects; my SalesOrderRepository is responsible for talking to the database.

This structure also supports TDD because I'm going to want to test my SalesOrderFactory to make sure that it configures my SalesOrder correctly. Separating out my data access into a different repository class lets me replace that repository with a mock class that returns SalesOrders that I'll use in testing my SalesOrder configuration code.

But that just moves you onto the next problem: In that factory method, you'll have to decide how you'll pass objects to the SalesOrder as you configure it. I'll discuss that in a later column.