It is often difficult to build a framework or API in a way that users of that framework can easily know what exists and when to use what.

One of the main reasons why it is difficult to write a good framework is that many developers tend to create classes that are very loosely connected to other classes in that framework with which they are intended to interact.

Defining the island

When you create a series of classes, do you explicitly plan for those classes to depend on each other or do you try to design them in a way so that they are independent?

This question brings up the old topic of loose coupling and tight cohesion.

I consider a class to be an island if it is loosely coupled, but also loosely cohesive.

A class that is an island is a class that does its own thing with very little dependencies or very weak dependencies.

Imagine for a moment a CurrencyConverter class.

This class is designed to take an amount of one currency and convert it to another currency.

There are several ways we could create the API for this class.

Here is one of them:

public class CurrencyConverter
{
    CurrencyConverter(ICurrency destinationCurrency)
    { ... }

    ICurrency Convert(ICurrency sourceCurrency, decimal amount);
    { ... }
}

Now this seems like a pretty reasonable API, but there is a problem here.  The problem is if you have a class that implements ICurrency, you don’t have any good way to know that this class exists.

If we don’t do anything else, this class might as well not exist at all.  It is an island.

It can see classes it needs to use, but the classes that could benefit from CurrencyConverter don’t know it exists.

The developer that is using an ICurrency implementation has no good way to know that this convert exists.  Most likely a developer will end up writing their own implementation of a currency converter. 

Duplication! Bad!

The date and time link

You will often see this in code bases and frameworks.  You will have many different utility folders or classes that help do date and time operations.

The problem is that no one really knows these utility classes exist and so everyone ends up rewriting the functionality all over your code base and you have a mess.

Take a look at your own project, see if you can find all the utility classes that deal with date, time or currency.  Now check to see if those utility classes are being used everywhere they could be.  Chances are they are not.

Building bridges

We need to build a bridge to the island so that everyone can enjoy the nice beaches.

No point building your wonderful CurrencyConverter if no one knows it exists, right?

So how do we solve this problem?

It definitely is a tricky problem to solve.

The best way I have found is to tie the dependent class back to its dependency. 

Yes, I am advocating circular dependencies!

Don’t be alarmed, it is not that bad.  All you have to do is make sure that your ICurrency interface has a reference to CurrencyConverter so that someone using ICurrency will know it exists.

Now there are many ways of doing this.  Some involve using a base Currency class, others involve creating different static constructors for Currency classes.

I am going to show you a very simple example, just to make my point.

public interface ICurrency
{
    ConvertUsing(CurrencyConverter converter);
}

It really is that simple.  You have now built a bridge to the island that was CurrencyConverter.

Now when a developer types ‘.’ on an ICurrency implementation they will see a convert method that uses your converter and they will know it exists!  Joy!

Again, there are many ways you could build this bridge.  My intention is not to debate them here.

The point is… BUILD THE BRIDGE!

But it is a circular dependency, that is bad

Really?

It is worse than 5 implementations of currency conversion in your code base?

What we have really done here is build something that is extremely tightly cohesive.  This is not necessarily a bad thing.

What we don’t want to do is to tightly couple the currency conversion to our billing system code.  We don’t want to have some building system class being used by our CurrencyConverter.

Applying the idea further

The basic idea here is that every time you create a new class you should think about how someone will know it exists.

If the class is out there on its own and it is likely to be useful in the the future, you must do something to tether it back to its dependencies.

It is helpful to have the attitude that if a developer can’t discover your class by some other class through intelli-sense, your class might as well not exist.

Every time I create a class, I try to think of two things:

1. How will someone use this class
2. How will they know this class exists

We looked at how we can benefit from changing the control of the interface from the service to the client of that service.

This time we are going to tackle the more common form of IoC that is quite popular these days, and I’m going to show you why dependency injection is only one way to invert the control of the creation of objects in our code.

What is creation inversion?

In a normal everyday code we usually create objects by doing something like:

MyClass myObject = new MyClass();

We usually do this creation of objects inside of the class that is going to use or needs that object.

If we used interface inversion, we would probably end up with a declaration like:

IMyInterface myImplementation = new MyImplementation();

You can see that even though the interface may have been inverted we are still controlling the creation of the object from inside the class that uses the object.

Let’s withhold our judgment of whether this is a bad thing or not until we fully understand the idea of creation inversion and the problem it is trying to solve.

So we can see clearly that the normal control is that objects that are used by a class are created by the class using the object.

If we wanted to invert this control, we would say that objects that are used by a class are created outside of the class using the object.

There, you understand IoC in regards to creation.  If you create the object you are going to use inside your class, you are not inverting control.  If you create the object somewhere else, you are inverting control.

Before we talk about how, let’s talk about why

Why would you want to invert control of the creation of your objects?

If you are familiar with design patterns, factory pattern should have just popped into your head when you read that statement.  If you are not familiar with design patterns, let me suggest either reading the original gang of four Design Patterns book, or the highly recommended Head First Design Patterns.

I mention the factory pattern because you might want to implement inversion of control for the same types of reasons why you would want to use the factory pattern.

Shh… I’ll tell you a little secret if you promise not to tell the cool IoC container / DI kids.  The factory pattern is inversion of control!

Let’s use factory pattern to tell us why we would want to invert control.  The description of factory pattern is:

Centralize creation of an object of a specific type choosing one of several implementations.

From that description we can deduce that we might want to use the factory pattern or some other form of inversion of control anytime we have an object or interface that has several different implementations and we want to put the logic of choosing which implementation to use in a single location.

Let’s use the classic example of having a skinnable UI.

If we have a UI framework that includes classes like Button, DropDownList, TextBox, etc, and we want to make it so that we can have differently skinned implementations of each UI control, we don’t want to put a bunch of code into all of our screens in our application like:

Button button;
switch(UserSettings.UserSkinType)
{
   case UserSkinTypes.Normal:
        button = new Button();
        break;
   case UserSkinTypes.Fancy:
        button = new FancyButton();
        break;
   case UserSkinTypes.Gothic:
        button = new VampireButton();
}

If we can somehow move the creation of the right kind of object outside of our classes and put it in one place, then we can eliminate all this duplication.  This prize comes at a price.  The price is control.  For convenience sake we must rip the control of the creation of button from our UI screens and give them to a central authority who doles out buttons at this whim.

We need a mediator that says to our UI screen classes, “You want a button?  I got button for ya, and you don’t need to know what kind, cause it’s none of your business.  All you need to know is it’ll be a button.”

I’ll harp on this more later, but I want to bring up the point here before we move on.  Why would you use inversion of control when you don’t have a problem of needing to select from more than one implementation of an interface or class?

How can I gets me some of this IoC goodness?

So let’s talk about how to implement inversion of control.

I’m not going to cover every conceivable way that you could invert control in regards to creation, but I will focus on a few common ways to do so.

Factory pattern

Let’s start here since we already mentioned it.  In our case above we could easily create a button factory that would be able to hand us the correct kind of button.  We would put all the logic for determining which button to use inside of the factory and let it hand us the correct kind of button.  Our code from the above example would be simplified to:

Button button = ButtonFactory.CreateButton();

Service locator

A service locator is very much like a factory.  You can even use a service locator to get you the right kind of factory that can make your object.  The difference is a factory creates a specific kind of object and a service locator can create different kinds of objects.

Using a service locator pattern, we might rewrite our example as:

Button button = ServiceLocator.Create(Button.class)

(We could also use generics here and do Create<Button>())

Dependency injection

(Notice I’m not saying IoC container based dependency injection.  I’m talking about dependency injection in general here.  You can use an IoC container to do it, but it is not required.)

This is the one most people are most familiar with.  We can use a special class that maps interfaces to their implementations, and then injects those implementations into our class via one of several ways.

Some of the common ways to inject the implementation into the class are:

• Constructor injection – pass the dependency into your class via the constructor.
• Setter injection – pass the dependency into your class by setting it on your class.
• Interface injection – implement an interface that allows another class to call your class to give it the dependencies.

Using constructor based dependency injection we could rewrite our example like:

Button button = GetTheRightDangButton();
OurScreen ourScreen = new OutScreen(button);

Notice in this example, we are showing how to create our class.  We don’t have to do anything special inside our class besides provide a constructor that take our dependency.

But dependency injection looks silly in this example

Right you are!

What if we have more than one button we are going to use in our screen?  Seems pretty silly to put a single button in the constructor.

If you already know about IoC and dependency injection, there are two important things you should be taking away from this look back to the basics of creational IoC patterns.

1. IoC doesn’t even require interfaces, it just requires that an object be created outside of the class that uses it.
2. IoC does not always mean IoC container and dependency injection.  Many times the best solution is to directly instantiate an object or use a factory or service locator.  (Especially when you are using multiple instances of a class.)

Before embarking on an IoC journey, it is important to understand what problem you are trying to solve by introducing IoC and to understand the differences between using IoC to invert interfaces, using IoC to invert flow control, and using IoC to invert creation control.

In almost all cases the correct application of creational IoC involves solving one of two possible problems.

1. I have multiple implementations of an interface or class and I need to be able to have the logic to choose which one all in one place.
2. I have only one implementation of an interface or a class, but I need to completely decouple the interface from the implementation for a really good reason.  (A really good reason is something like: “I am writing the code that will use the implementation of this interface, but another company is going to provide the implementation in another library.)

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

We also talked a little about IoC and the three main forms of control that can be inverted; interface, flow, and creation.

In this post I want to dive a little deeper into IoC as it relates to interfaces and creation, we’ll ignore flow inversion for now, because it is often used in a way that is completely unrelated to the other two.

We’ll focus more on creation since we already covered interface inversion a bit and creation inversion is the “hot thing” right now.

Interface inversion

Why would we want to invert interfaces?

We covered much of the reasoning in my post on dependency inversion, but there are some important points that specifically relate to interfaces in programming that I would like to address here.

First we must understand what non-inverted interfaces are.

Let’s take an example.  Suppose I have a Kangaroo class that has several methods, among them is Punch. Normally, Kangaroo defines the interface that has to be used if you want to use the Kangaroo class.

By default the constructor for the class and the method signatures all make up an interface that the user of the Kangaroo class must adhere to in order to use the Kangaroo class.  The module that contains the Kangaroo class usually also would include the interfaces if one is defined.  In this case the interface would be something like IKangaroo.

Why do I say this is normal and not inverted?  Because it makes sense that a class would define what it does and how to use it, not some other entity.

An inversion would be if some other class or module told Kangaroo what its interface needed to be.  Kangaroo would stop being an independent definer of a service it has to offer and instead become a provider of a service someone else wants.

From our narrow viewpoint of the Kangaroo class we don’t know what kind of interface to provide, so we have to assume it is something like IKangaroo.  The way we look at the Kangaroo class can completely change though, if we consider the BoxingMatch class.

If we create a BoxingMatch class, we really want that class to define the interface that all boxers must adhere to.  We don’t want to have to have the BoxingMatch class know how to make multiple classes with different interfaces box.  So within the module that the BoxingMatch class is defined, we define an interface called IBoxer.  Within the BoxingMatch class itself we use IBoxer instead of specific classes that we want to use in our boxing match.

Now we have given Kangaroo a suitable interface to implement.  IKangaroo hardly makes sense, but IBoxer gives our Kangaroo a purpose.  Our little Kangaroo class is providing a service.  He can box!

In this example you can see that we have inverted the control of the interface.  Instead of letting the provider of the interface define that interface, we have made the user of the interface define it.

The value we gained here is that we have given control to the higher level module and reduced the complexity of its logic by preventing it from having to deal with every different interface defined by classes that can box.

Up next creation inversion

I’m going to end this post here, since creation inversion is going to be a longer topic, and I am on vacation right now.

In my next post we’ll cover creation inversion and talk about how it relates to Dependency Injection or DI.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

It’s a hefty book that you could definitely use to cause some major kidney trauma to an unsuspecting DBA if you sneak up on him from behind and jab the pointy end of the book into his unprotected backside.

I finally got around to reading this because it is one of my last remaining analog books.  It is part of my quest to cleanse my life of all possessions that are not digital or are not monitors.

This book is really about messaging.  Don’t let the title fool you.  Definitely consider picking up this book if you want to use a messaging platform like BizTalk, MSMQ, or JMS to integrate several applications together.

The good:

• This book is extremely detailed about each messaging pattern, when to use it, and how to implement it.  If you are seriously going to consider implementing a messaging solution, you need this book.  Honestly, I have done some messaging without it and now that I have read it, I feel like I really missed the whole point before.
• Multi-language / technology.  This book is generalized enough to not push you in a language or technology decision, but has specific examples in Java and C#.
• Simple to understand.  I was rushing through this book because I wanted to get through it and I found that I was picking up pretty much every concept being thrown.
• Excellent reference.  I can see using this book in the future to go back and solve some sort of problem dealing with messaging.
• Broken down into perfect size pieces.  If you read this book, you should have all the tools you need to solve any kind of complex messaging scenario.  By thinking of messaging in terms of the patterns or blocks in this book, very complex problems become much simpler.

The bad:

• It is freaking long.  Seriously.  This is a long book.  It has some diagrams and some code, but it is long.  Get ready for an adventure.
• It’s a little dry, probably because it is so long.  Some of the code examples are a bit repetitive, and no one ever wants to see XML soap bindings on pages in a book.

What I learned:

I have to say that I really did learn a large amount of information from this book.  I really feel like I got a good understanding of how to apply messaging patterns to various sorts of problems.

I feel like this book gave me a really big toolbox of all the possible tools that I would need to solve any messaging pattern.

I also learned just how easy it is to use MSMQ and JMS and throw messages on a pipe.  It’s really not that bad.

After having used BizTalk a while ago and not really understanding what it was or what it was trying to do besides allow you to change file formats between a bunch of different clients, I feel like this book definitely opened up my eyes to the true value of a solution like that.  If I had a BizTalk project now, I am sure I would be much more effective after reading this book.

Overall, I would definitely recommend that every developer that is working with messaging read this book.  Even if you are not, I would still recommend reading it so that you can have your eyes opened up to how messaging can solve many of the problems we try to solve in create-ftp-batch-cron-jobish ways.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

This post is going to focus much more on the details and how it relates to code.

Back to your code…

Now let’s look at a code example to see how dependency inversion helps us out. Let’s say you are creating a high level module for parsing log files and storing some basic information into a database.

In this case you want to be able to handle several different log files from a number of different sources and write some common data they all share to a database.
One approach to this kind of problem is to have your module handle each kind of log file based on what kind of data and format it contains and where it is. Using this approach, in your module you would handle various kinds of log files based on the interface those individual log files present to you. (When I use interface here, I am not talking about the language construct, but the concept of how we interface with something.)

Using this approach, in our module we might have a switch statement or series of if-else statements that lead us to a different code path depending on what kind of log file we are processing. For one log file we might open up a file on disk, and read a line, then split that line based on some delimiter. For another perhaps we open a database connection and read some rows.

The problem is the log files are defining the interface our higher level code has to use. They are in effect “in control” of our code, because they are dictating the behavior our code must conform to.

We can invert this control, and invert the dependencies by specifying an interface that the log files we process must conform to. We don’t even have to use a language level interface.

We could simply create a data class called LogFile that is the input to our module. Anyone who wanted to use our module would first have to convert their files to our format.

We could also create an ILogFileSource interface that classes could implement to contain the logic of parsing log files from different sources. Our module would depend on ILogFileSource and specify what kind of methods and data it needs to parse the log files instead of the other way around.

The key point here is that our high level module should be controlling the interface (non language construct kind) that the lower level modules need to adhere to instead of being at the whim of the interfaces of each lower level module.

One way to think of this is that lower level modules provide a service to higher level modules. The higher level modules specifies the interfaces for that service and the lower level module provides that service.

One thing I want to point out in this example is that we knew there would be more than one log file source. If we were writing a log file parsing module that was only ever going to work against one source it might not be worth trying to invert this dependency because we wouldn’t see any benefit from doing so. It isn’t very hard for us to write out code as cleanly as possible working with one source and then refactor it later to invert the dependencies once we have additional sources.

Just because you can invert dependencies doesn’t mean you should.

In this case since we are always writing to a database, I don’t feel any particular need to invert our dependency on writing out the log files. However, there is some real value in encapsulating all of our code that interacts with the database into one place, but that is for another post.

Notice we haven’t talked about unit testing yet

You see the problem of dependency inversion and inversion of control has nothing specifically to do with unit testing.

Simply slapping an interface on top of a class and injecting it into another class may help with unit testing, but it doesn’t necessarily invert control or dependencies.

I want to use the log parsing example to illustrate my point. Let’s say we had created our log parser to have a switch statement to handle each type of log file, and now we want to unit test the code.

There is no reason why we can’t create IDatabaseLogFile, ICSVFileSystemLogFile, IEventLogLogFile and IAnNotReallyDoingIoCLogFile, pass them all into the constructor of our LogFileParser as dependencies and then write our unit tests passing in mocks of each.

That in an extreme example for sure, but the point is slapping an interface onto a class does not an IoC make.

We shouldn’t be trying to implement this principle to make it easier to write unit tests. Difficult to write unit tests should give us hints like:

• Our class is trying to do too much
• Our class has lots of different dependencies
• Our class requires a lot of setup to do work
• Our class is just like this other class that does the same thing only for a different input

All of these kinds of hints tell us that we might want to invert control and invert dependencies to improve the overall design of our class, not because it makes it easier to test. (Although it should also make it easier to test.)

Ok, ok, so is dependency inversion the same as inversion of control or what?

Short answer: yes.

It depends on what you mean by control. There are three basic “controls” that can be inverted.

1. The control of the interface. (How do these two systems, modules, or classes, interact with each other and exchange data?)
2. The control of the flow. (What controls the flow the program? This control inversion happens when we go from procedural to event driven.)
3. The control of dependency creation and binding. (This is the kind of inversion of control IoC containers do. This inversion is passing the control of the actual creation of and selection of dependencies to a 3rd party which is neutral to either of the other 2 involved.)

Each of these 3 is a specific form of dependency inversion and may even involve multiple kinds of dependencies being inverted.

So when someone says “inversion of control”, you should be thinking “what control is being inverted here?”

Dependency inversion is a principle that we use in architecting software.

Inversion of control is a specific pattern that is applied to do so.

Most people only think of inversion of control as #3 above, inverting the control of dependency creation and bind. This is where IoC containers and dependency injection take root.

What can we learn from this?

My goal is that we stop grouping the concepts of inversion of control and dependency inversion automatically with dependency injection.

We have learned that dependency inversion is the core principle that guides many of the other practices that have derived from it.

Whenever we apply a pattern we should be looking for the core principle it is tied to and what problem it is helping us solve.

With this base understanding of dependency inversion and inversion of control, we have the prerequisite knowledge to look at dependency injection and understand better what specific problem it tries to solve. (Which I will cover in another post.)

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

It’s not completely important that we understand the specifics of each of these names, because many people end up using them interchangeably.  It’s pretty unlikely that we are going to correct all that in this blog post.

What is important is that we understand the concepts and ideas behind each of these topics and understand what architectural problems each one is trying to solve.

Today, we are going to focus on Dependency Inversion and get a little bit into inversion of control.

Dependency inversion is the root

It all started with this simple concept introduced by Uncle Bob in his article in the C++ Report of May 1996, The Dependency Inversion Principle.

If you have the time to read through that article, do yourself a favor and do it.  You don’t need to know much C++ to understand it, and it really sheds a light on the problem Bob was trying to solve.

Bob talks about this principle in his excellent book, “Agile Software Development, Principles, Patterns, and Practices, and Agile Principles, Patterns, and Practices in C#”

This principle is actually very simply stated:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend upon details. Details should depend upon abstractions.

I think this concept is easily misunderstood and misapplied, because the reason why we apply this principle is often neglected.

If you are familiar with IoC and Dependency Injection, you can see how both are based from this definition of Dependency Inversion.

What problem does dependency inversion solve?

Dependency inversion solves the problem of higher level modules being dependent on and coupled to the interfaces of lower level modules and their details.

Let me give you a real world example of a current problem that could be solved by dependency inversion.

Take a look around your house and count up all the devices that have batteries that must be charged somehow.

Things like:

• Digital camera
• Cell phone
• Camcorder (flip cam)
• Wireless headphones
• Game controllers

What do all of these things have in common?  They don’t have a charging interface in common.  Some use micro-usb, some use mini-usb, some use their own funky plug.

So as a result, you can’t just have one thing that charged all your devices.  You have to have a different thing for each device.  Your home’s “charging mobile devices module” is dependent on the device.  If you change your cell phone, you need a new charger.  If you upgrade your camera, you need a new charger.

The dependency is going the wrong way.  Lower-level appliances are defining the interface that your home has to use to charge them.  Your home’s charging capability should define the interface the devices have to use.  The dependency should be inverted.  It would make your life a lot easier.

Let’s look at one more example of a place where I would bet dependency inversion is used.  Now, I don’t know about Walmart’s IT structure, but I would venture to guess that when they receive invoices from all of their many distributors the invoices come in the file format that Walmart specifies and not the other way around.

I would bet that Walmart specifies the schema for all of the data it receives from its many business partners.  Let’s assume they do.  In this case they have inverted the dependency, actually they have inverted the control.  Instead of their vendors controlling their interface, Walmart controls the vendors through their interface.

What this means is that every time the vendor changes their internal system they have to still conform to Walmarts interface instead of Walmart having to make changes to accommodate each vendors changes to their format.

To be continued

In my http://simpleprogrammer.com/2010/11/16/basic-to-basics-what-is-dependency-inversion-is-it-ioc-part-2/#mce_temp_url# I am going to actually give a code example of dependency inversion, address unit tests and finally answer the question of whether dependency inversion is the same thing as inversion of control.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

In my last post I talked about what cohesion and coupling are and I talked about some of the benefits of each.

Now I want to take a look at the actual application of cohesion and decoupling on software systems.

Granularity affects cohesion and coupling

Here is the key misunderstanding with cohesion and decoupling.

Cohesion and decoupling are completely relative to the granularity of what is a module.

From here on out, I won’t say class or software or system, I am going to say module when referring to cohesion and coupling.

See, the problem is that we need to be able to define what a module is in order to determine if something is loosely coupled or highly cohesive.

Let me give you an example.  Let’s take that linked list class we talked about above.  If we define a module to be any class in our code, then it is pretty decoupled.  But, if we define a module to be any class or primitive type in the system, suddenly our linked list implementation is going to be dependent on many other things.  Now all the variables we declare in our class are dependencies on things like the Array and the String class or integer implementations.

When we zoom deep down into the above level of what a module is we end up with many more dependencies which represent tighter coupling.

What about cohesion?  Consider if you will, Enterprise FizzBuzz.  This is an implementation of the FizzBuzz problem:

• Print the numbers from 1 to 100
• If the number is divisible by 3 print “Fizz” instead
• If the number is divisible by 5 print “Buzz” instead
• If the number is divisible 3 and 5 print “FizzBuzz” instead

It is an implementation of this simple problem using 3 assemblies and 16+ classes.  If we consider a module to be a class, it is not very cohesive at all, since the responsibilities of what should be in a single method or two are spread out across 16.  If we consider a module to be an assembly, it still isn’t very cohesive.

We have to zoom all the way out to the module is a program level before this software becomes cohesive, but at that level it is very coupled to all the the various other frameworks that it depends on.

There are two important takeaways from this section:

1. How we define a module when looking at software affects cohesion and coupling.
2. The granularity we use to build the software affects cohesion and coupling.  (This one was hidden in the enterprise FizzBuzz example.  In this case the author of the code defined a responsibility to be something very very small.)

To summarize, we can look at code from different levels of zooming in and out and determine its coupling and cohesiveness.  We can also build software as different size “Lego blocks” which has the same effect.

When cohesion and coupling are inversely related

With that background, we can finally answer the question of whether or not it is possible to achieve high cohesion and loose coupling.

The answer is “to a degree.”

If we try to push too far into the loose coupling zone, we will find that we end up making our definition of a responsibility very very small at which point we lose the quality of cohesion.

I’m going to pick on overuse of interfaces again to give you an example.

Consider what happens when we create an interface to “reduce coupling” so that we can create unit tests.  We end up decreasing cohesion because the class our class was referencing (one jump), now is an interface which is implemented by a class (two jumps.)

Now consider what happens when we add a dependency injection module or even just a factory to get the implementation.  Our once simple and highly cohesive implementation is spread out across an interface which is implemented by a class that we have to look up in a factory which contains some sort of a mapping file to map the interface to the implementation. (3-4 jumps.)

I know this concept seems very strange, but let me see if I can explain it with a real world example.

Consider again the highly cohesive baseball.  It’s already at the optimum coupling of 0.  It doesn’t depend on anything else.  But, if we wanted to we could try to decouple it.  How?  We have to zoom in to a point where we could consider that the outer stitching is coupled to the casing which is coupled to the inner ball.

We could decouple that baseball by taking it apart and design some kind of interface which allows for different kinds of binding mechanisms for the outer shell and some kind of substrate to prevent the outer shell from directly touching the inner ball.

If we did that we’d have pieces of the ball lying all over the place and it wouldn’t be very cohesive or even functional.

We can do that exact thing with software.  There is a point where we have achieved the maximum qualities of loose coupling and high cohesion, and we can try to push decoupling at the cost of cohesion.

Cohesion is more important

It probably appears that I am saying that cohesion is more important than decoupling, and actually I am.

Why?

If you remember the advantages of tight cohesion and loose coupling, you might have realized that most of the advantages are the same except tight cohesion gives us the benefit of increased understanding.

I tend to value understanding and simplicity in software above most other things, because they aid the most in maintenance and debugging.

It is very important that we consider cohesion when we seek to increase decoupling.  It also can help give us a very clear measure of when we have maximized decoupling.  At the point where any more decoupling will harm cohesion, we are done.

So is dependency injection bad?

No, not at all.  Dependency injection and other methods of decoupling have their places, but it is very important that we don’t just blindly use them for every class in every situation.

We have to be conscious of what we are losing in cohesion and understandability when we consider using any kind of framework or pattern to decouple our software.

I’ll pick on one more thing here, since I think it is not very obvious.  Consider how good a message bus can be for integrating different applications together.  Messaging systems can decouple the different applications that need to communicate with each other making them highly cohesive and very loosely coupled.

Now, consider how bad a message bus can be inside of an application.  I know it is a fairly popular solution for decoupling events, commands, and other communication within an application, but many times the cost of the decoupling is a very high hit to cohesion and understandability.

Don’t get me wrong, sometimes an internal message bus is a good solution for an application, but in many cases it is going to hurt you more than help you.

It’s all about right sized Lego blocks

Scott Hanselman often likes to talk about “right sized Lego blocks”, and I agree with him 100%.  Figuring out how to appropriately decouple your application while maintaining cohesion is all about figuring out what the ideal size of a module is.

Sometimes the answer might even be to split your application into multiple applications.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Someone mentioned in the comments that it wasn’t very clear exactly what was going on with the final code.  I tend to agree that this:

LogOnError(_riceCooker.Cook);

… is not very clear.

Really, there are two problems with this code that I can see.

1. It is not clear what this is going to do or whether or not LogOnError or Cook is the method we are concerned about.
2. It’s not very self-discoverable at all.  If we had a library of useful wrapper methods like these, we wouldn’t have a good intellisense way to know what they are.

I can solve both of those issues, but doing so starts to move us into a weird zone where I am not quite sure I feel comfortable.  But, nevertheless, in the name of science…

Let’s start backwards

Liking fluent interfaces, here is the kind of syntax that I would prefer to be able to use:

Wrapper.Wrap(_riceCooker.Cook).With.LogOnError();

It is a little bit longer syntax, but I like it for a few reasons:

1. It clearly indicates what is going on here.  We are wrapping a method call using a wrapper.  We are wrapping with a method called LogOnError.
2. You get intellisense all the way.  The correct implementation of this, should let me Type With + ‘.’ and then see a list of all the possible wrapping methods I have implemented.  This makes the wrapping set of methods self-discoverable.

I really like the idea of being able to easily change the functionality of the wrapping just by changing the last part of the line.  For example, if we had implemented a wrapping method that was LogAndAbortOnError(), we could change our code to use that pretty easily.

Wrapper.Wrap(_riceCooker.Cook).With.LogAndAbortOnError();

If we implement this correctly, intellisense will give us our options.

Making it so

Creating a fluent syntax in C# can often involve quite a bit of magic and voodoo.  I always like to gather my reagents before embarking on such a journey.

So grab a live chicken, a stapler, and a sharp knife and let’s go!

First step, let’s simplify this.  The With is nice, but it is just for flow, we don’t really need it.  So let’s figure out how to implement our syntax without the With and add it in afterwards.

Wrapper.Wrap(_riceCooker.Cook).LogOnError();

First the easy way.

1. Create a static Wrapper class with a Wrap method that takes an Action and returns an Action.  (We’ll use this to convert whatever we pass in to an Action, so that we can use a Lambda expression or any method call there.)
2. Create a static extension method that operates on an Action.  Call it LogOnError.

public static class Wrapper
{
    public static Action Wrap(Action action)
    {
        return action;
    }
        
    public static void LogOnError(this Action action)
    {
        try
        {
            action();
        }
        catch (Exception exception)
        {
            // Log the exception here
        }
    }
}

Not too bad.  Not a large amount of magic going on here.  Just using an extension method.

But, we already have a problem.  Using a plain old Action is going to give us too many choices in the intellisense drop down.  It could make it hard to know what our real options are and when we try and add the With syntax later, we will need to use a property off of an object we return from the Wrap method.

Making it better

We can fix this by actually wrapping the Action with a custom type that we can add our methods to.

Instead of Wrap returning an Action, it will return a WrappedAction.

public static class Wrapper
{
    public static WrappedAction Wrap(Action action)
    {
        return new WrappedAction() {Action = action};
    }
        
    public static void LogOnError(this WrappedAction wrappedAction)
    {
        try
        {
            wrappedAction.Action();
        }
        catch (Exception exception)
        {
            // Log the exception here
        }
    }

    public class WrappedAction
    {
        public Action Action { get; set; }
    }
}

Looking better.  Now when we put a ‘.’ at the end of our Wrap call we only see LogOnError as an option.

We can be sure now that if we create an extension method for a WrappedAction, we will make sure that method is self-discoverable.  Before, the generic Action extension  method could make our method show up places that we don’t want it to and can get lost in the other methods on Action.

Making it done

The last thing we need to do is add the With.

Ideally, when we hit the ‘.’ on the end of the Wrap method, we want to see With as an option.  When we hit the ‘.’ on the end of the With property, we want to see LogOnError as an option.

In order to accomplish this we need to:

1. Add a With property to the WrappedAction.
2. Have the With property be of a new type (WrappedActionTarget) so that we can add our extension methods for that new type.
3. Change the extension method to operate on the new type.

Here is what we end up with:

public static class Wrapper
{
    public static WrappedAction Wrap(Action action)
    {
        return new WrappedAction() { Action = action };
    }

    public static void LogOnError(this WrapperMethodTarget target)
    {
        try
        {
            target.WrappedAction.Action();
        }
        catch (Exception)
        {
            Console.Write("Logging this error");
        }
    }
}

public class WrapperMethodTarget
{
    public WrappedAction WrappedAction { get; set; }
}

public class WrappedAction
{
    public Action Action { get; set; }

    public WrapperMethodTarget With
    {
        get
        {
            return new WrapperMethodTarget() { WrappedAction = this };
        }
    }
}

Now we can use the syntax of:

Wrapper.Wrap(_riceCooker.Cook).With.LogOnError();

We can move that LogOnError method out to another class, or create new extension methods somewhere else.  I just put it in there to avoid creating another class.

Is this really practical?

I don’t know.  To be honest, I was playing around with creating extension methods that work on Actions and I came up with this way to use them.

I could see making a wrapping library that had different kinds of ways you would wrap method calls built into it.  It could allow you to specify how you log in a configuration and then you would get all of this common stuff automatically.

Even if it is not practical, it’s pretty fun, and it demonstrates the power of Action, or rather functional programming in general.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

It is a little difficult to implement though.

To be honest, I don’t think I’ve ever really seen it successfully implemented.  I mean sure, I’ve seen examples of how you could use it for “cross-cutting” concerns like logging.

The problem is it is usually pretty difficult to use, and the only real practical application I can ever come up with is logging.  I know, it is probably just my lack of knowledge in the area, but if you bear with me I’ll show you a neat little trick you can use to address cross-cutting concerns by doing something similar to what AOP does using Action<>.

Putting it all in one place

The main problem AOP tries to solve is taking aspects of your software that exist in many different places and condensing them into one place for you to maintain.

Exception handling and logging tend to be the most infamous of these cross-cutting concerns.  Many places in your code you no doubt have many instances where you catch an exception and the only thing you can really do is log it.

I’m going to show you a little easy way to do that using Action<>.

Giving credit where credit is due, I got this idea from some code that a coworker of mine, Subha Tarafdar, wrote.  (He is a genius.)

He wrote some code to basically do what I am going to show you, but with retrying database queries.  He was able to reduce many places in the code base where we had repeated logic to retry executing database queries when getting a deadlock or timeout.

Does this code belong to you?

public void MakeRice()
{
    try
    {
        _riceCooker.Cook();
    }
    catch (Exception exception)
    {
        // Don't care if this fails,
        // there is nothing we can do about it.
        Logger.Log(exception.Message);
    }
}

Ignore that I am catching a general exception here.  It is a bad practice, but sometimes all you are going to do is log whatever bad thing happens and move on.

It’s pretty common to do something in a try block and catch an exception only to log it.

Think about how many times this code or something similar to it might be sprinkled throughout your code base.

Action<> to the rescue

If you’re not familiar with Action<> take a look at this post I did that gives a very simple explanation for how it works.

We can take the logic of the try, catch, and log exceptions and put it into a method that only varies by what action we do.

public static void LogOnFailure(Action action)
{
    try
    {
        action();
    }
    catch (Exception exception)
    {
        Logger.Log(exception.Message);
    }
}

I’m not a big fan of static methods but in certain cases they make sense.  The alternative is to have all of this code sprinkled throughout your code base.

Now that we have this method, we can do anything we want and know that if there is an error it will be logged.

Check this out:

LogOnFailure(_riceCooker.Cook);
LogOnFailure(KickACat);
LogOnFailure(() =>
                    {
                        Wakeup();
                        SmellTheRoses();
                    }
            );

And if you decide you want to change how you log the error or what you do on it, you can change it all in one place.

Not just for logging

You can apply this kind of solution in many places where you have cross cutting concerns in your code base.

Here are a few suggestions for places you might consider this kind of a solution:

• Retrying on failure logic
• Using an alternative service for a failure (web service “A” failed, but we can use web service “B”)
• Database connection and connection closing logic.  (Open connection, do something, close connection.)

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I talked about refactoring helper classes before, but this is slightly different.

In this case I want to talk about refactoring classes that you want to keep around, but have all or many static members.  A good example of this is some kind of service class that returns data from the database.

It’s not always very clear whether that kind of class really is some sort of helper class.  It is a bit of a judgment call.  If you do find a helper class though, don’t just leave it there.

So, basically if you have determined the class you are working with is going to stay, but it does have static methods and you need to get rid of them, because you are doing dependency injection or mocking, read on.

Defining the two approaches

What do I mean by step-wise refactoring?

Here is the basic outline of the first approach:

1. Make the method you need to be non-static, non static.
2. Add an interface with just that one method in it.
3. Implement the interface.
4. Change the references to that method to use the interface instead.

Let’s take a look at an example:

public static class LostOrderService
{
    public static IEnumerable<Orders> GetLostOrders(int customerId)
    {        
    }

    public static IEnumerable<Customer> GetCustomerWithLostOrders()
    {
    }
}

If we are interested in the GetLostOrders method, we can apply steps 1-3 to get:

public interface ILostOrderService
{
    IEnumerable<Orders> GetLostOrders(int customerId);
}
    
public class LostOrderService : ILostOrderService
{
    public IEnumerable<Orders> GetLostOrders(int customerId)
    {        
    }

    [Obsolete("If you touch this refactor to make it not static. 
                      Be a man, do the right thing.")] 
    public static IEnumerable<Customer> GetCustomerWithLostOrders()
    {
    }
}

Now we can go in and change references in our code for just that one method.

public void ProcessLostOrders()
{
    var orders = LostOrderService.GetLostOrders(_customerId);
    foreach(var order on orders)
    {
        ReprocessOrder();
    }

}

// Refactored becomes:

public void ProcessLostOrders(ILostOrderService lostOrderService)
{
    var orders = lostOrderService.GetLostOrders(_customerId);
    foreach(var order on orders)
    {
        ReprocessOrder();
    }

}

Now let’s look at the 2nd technique, wrapping and delegating.  Here is the outline of the wrapping and delegating approach:

1. Create a wrapper class that’s going to be used to wrap the static classes calls.
2. Implement all the methods in the static class as non-static methods in the wrapper class.  Each method just delegates to the static method in the static class.
3. Create an interface which contains all the methods.
4. Have the wrapper class implement the interface.

Here is an example of doing it this way, given the same original code as the first example:

public interface ILostOrderService
{
    IEnumerable<Orders> GetLostOrders(int customerId);
    IEnumerable<Customer> GetCustomerWithLostOrders()
}

public class LostOrderServiceWrapper : ILostOrderService
{
    public IEnumerable<Orders> GetLostOrders(int customerId)
    {      
        LostOrderService.GetLostOrders(customerId);
    }

    public IEnumerable<Customer> GetCustomerWithLostOrders()
    {
        LostOrderService.GetCustomerWithLostOrders();
    }
}

The references to the LostOrderService will be refactored exactly the same as in the first example, so I won’t include it here.

You can see in this example, we didn’t touch LostOrderService itself.  Except, you probably want to put an Obsolete attribute on the class to tell users to not use this, but use the wrapper class instead.

Which is more bettah?

I’ve tended to use the wrapping and delegating approach in the past, but I am starting to think the step-wise approach is better for a few reasons.

• The step-wise approach is a bit more obvious to someone later using the class.  When you wrap and delegate, someone has to know there is a wrapper class.  With the step-wise approach, there is no choice.
• With the step-wise approach, you are actually getting rid of the bad and evil static methods.  When you wrap and delegate, you are still leaving them there, just hiding them behind a wrapper.

To me, the wrapping approach feels more like I am working around things rather than cleaning them up.  I also feel like someone can see what I started and pick it up from there step-by-step.  Where with the wrapping approach, the mess may never get cleaned up, because there is a workaround.

Where wrap and delegate shines

There is a place that wrap and delegate wins hands down though.

If you don’t have control over the source code of the static class or static calls, you cannot do the step-wise approach.

The wrap and delegate approach can be a lifesaver when you are dealing with static references in your code to an external library that you can not change.  You can simply wrap the external library calls and instead reference the wrapper in your code.  Now you can actually unit test that code.

Anytime you are using an external library, you should consider putting some kind of protective wrapper around it.  You never know when you may want to replace it or upgrade the library.  You don’t want to go hunting through all your code looking for references.

So, while either way will work, I prefer to use the step-wise method if I have access to the source code of the static class.

What do you think?  Do you have any other solutions?

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.