What Is Coupling?

Photo by Georg Eiermann on Unsplash

Today and tomorrow we’ll look at Coupling and Cohesion. You might have heard that Coupling is bad and Cohesion is good. Yes, that is true. These two concepts are mirror opposites of one another:

Coupling – Code that does not belong together 

Cohesion – Code that belongs together

If we achieve low Coupling and high Cohesion, our software should be easier to understand and simpler to change than vice versa; high Coupling and low Cohesion. 

Say, in high-level business logic we access a SQL Server database in this way:

  var database = new SqlServerDataAccess(connectionString);
  var orders = database.GetCustomerOrders(customerId);

In this example, the business logic has a dependency on data access. In the first line, SqlServerDataAccess is directly instantiated:

   var database = new SqlServerDataAccess(connectionString);

That is a problem. Why?

1. Hard to change. If we wanted to change our data access to a MongoDB database, we could not easily do so. We are already committed to SqlServerDataAccess.
2. Hard to unit test. We will have a hard time unit testing the business logic code without actually making calls to the SQL Server database. Unit tests don’t make calls to databases.

We have an undesirable dependency from the business logic to SQL Server data access code. We say that the business logic is coupled to the data access.

How do we identify Coupling?

Look for code that changes for different reasons. 

Business logic changes when business stakeholders change their minds regarding workflows. Data access changes when database admins and developers want to store or retrieve data differently. It doesn’t make sense to have the business logic depend on DBAs and developers’ whims.

Tomorrow we’ll explore Coupling’s polar opposite: Cohesion.

Coffee Mug Code

For Christmas, I received a hilarious coffee mug from my father-in-law.

Here is a photo of it.

It’s an amusing little program. I’ve transferred the listing:

  while (working)
  {
     coffee.drink();
     work.execute();
     if (coffee == "empty")
     {
        if (coffeepot == "empty")
           coffeepot.brew();
        coffee.refill(); 
     }
  }

I love coffee and programming—it’s the perfect present for me. 

But there is something that I love even more about the mug:

The code is so simple a layperson can understand it.

My 80-year-old father-in-law, who is not a programmer, could see the hilarity of the coffee-consuming code. Other non-programmer family members also immediately got the joke and smiled at its appropriateness.

And it had to be so. If the mug manufacturer had made the code too complicated and lost the joke, then no mugs would have ended up in Christmas stockings.

Not that it would fit on the side of a coffee mug, but 200 lines of over-complicated computer code indented to 6 levels, is not funny. On the contrary—it’s sad. A software developer would have to invest much time and effort to learn what is going on.

The mug’s lesson is simply this:

We ought to write our code so it’s easy to understand and simple to change.

That’s it.

Let me propose that we start 2021 out the right way and commit to writing easy-to-read code. To the best of our abilities, of course. And it’s a skill we can always get better at. There is no end goal. Imagine how much we could improve our working lives if we could stick to such a commitment! Who knows—maybe easy-to-read code will catch on with our fellow developers?

Tomorrow we’ll look at how we could improve the coffee mug code.

Question To You: Can you see ways of improving the code on the coffee mug? If so, please send me your ideas to olaf@codecoach.co.nz. I will publish the best responses tomorrow.

Promote Dependencies To Parameters

Photo by Emile Perron on Unsplash

Yesterday we discovered why we ought to favour unit tests over encapsulation. 

For our example, we had a CalculateStreak() method from an eLearning platform. Again, here is the listing:

  public int CalculateStreak(int streak, IEnumerable<StudentQuiz> quizzes)
  {
     var thisWeekFirstDay = _dtSvc.GetStartOfWeek(_dtSvc.UtcNow);
     var lastWeekQuizzeDates = quizzes.Where(q => q.startedAt >= thisWeekFirstDay.AddDays(-7) && q.startedAt < thisWeekFirstDay)
                                      .GroupBy(q => q.startedAt.Date);
     var thisWeekQuizzeDates = quizzes.Where(q => q.startedAt >= thisWeekFirstDay)
                                      .GroupBy(q => q.startedAt.Date);

     var lastWeekContinuity = lastWeekQuizzeDates.Count();
     var thisWeekContinuity = thisWeekQuizzeDates.Count();

     if (lastWeekContinuity < STREAK_CONTINUITY) streak = 0;
     if (thisWeekContinuity >= STREAK_CONTINUITY) streak++;

     return streak;
  }

This method comprises regular legacy code, nothing special. We get the gist of what it does, i.e. calculate the length of a learning ‘streak’ based on quizzes, but it is not that clear, at a glance, how it does its work. Yesterday we wanted to characterise the behaviour of CalculateStreak() by introducing unit tests. However, the method was private, and we could not call it in a test. We have fixed this problem by declaring it public, at the cost of compromising encapsulation a little.

Now we’re hitting the next obstacle. We should not be surprised; the standard operating procedure when trying to write unit tests for legacy code is to move from one dependency that we must break to another. That’s fine; ultimately, we’ll get there.

So which line poses the next stumbling block?

It’s 

  var thisWeekFirstDay = _dtSvc.GetStartOfWeek(_dtSvc.UtcNow);

_dtSvc is a reference to a class member of type DateTimeService. DateTimeService implements interface IDateTimeService. Good news should we need to mock or stub the service.

It appears the method invokes _dtSvc.GetStartOfWeek() to calculate the ‘first day of this week’ – the variable name could read more naturally, maybe firstDayOfTheWeek? 

_____________________

Aside: There is another problem with this line of code. It smacks of Feature Envy. The call to GetStartOfWeek() takes as argument a term that is also part of _dtSvc, specifically _dtSvc.UtcNow.

A better way to express this behaviour would have been to add a parameterless GetStartOfWeek() overload that internally makes a forwarding call to the parameterised overload:

  public DateTimeOffset GetStartOfWeek()
  {
     return GetStartOfWeek(UtcNow);
  }

The call in CalculateStreak() then reduces to

  var thisWeekFirstDay = _dtSvc.GetStartOfWeek();

We could go even further and condense this into a getter property.

Isn’t that much nicer?! 

_____________________

Let’s return our attention back to the call to _dtSvc.GetStartOfWeek().

Stubbing the DateTimeService for a single value seems a bit of overkill. Is there an easier way?

Yes, there is. 

We could make thisWeekFirstDay a parameter on CalculateStreak() and move the call to the DateTimeService outside the method. It would mean that for unit testing, we don’t have to stub DateTimeService; we could pass thisWeekFirstDay argument values, as appropriate. 

  public int CalculateStreak(int streak, IEnumerable<StudentQuiz> quizzes, DateTimeOffset thisWeekFirstDay)
  {
     var lastWeekQuizzeDates = quizzes.Where(q => q.startedAt >= thisWeekFirstDay.AddDays(-7) && q.startedAt < thisWeekFirstDay)
                                      .GroupBy(q => q.startedAt.Date);
     var thisWeekQuizzeDates = quizzes.Where(q => q.startedAt >= thisWeekFirstDay)
                                      .GroupBy(q => q.startedAt.Date);

     var lastWeekContinuity = lastWeekQuizzeDates.Count();
     var thisWeekContinuity = thisWeekQuizzeDates.Count();

     if (lastWeekContinuity < STREAK_CONTINUITY) streak = 0;
     if (thisWeekContinuity >= STREAK_CONTINUITY) streak++;

     return streak;
  }

We can turn the existing version of CalculateStreak() into a forwarding overload to ensure those existing callers of CalculateStreak() work as before:

  public int CalculateStreak(int streak, IEnumerable<StudentQuiz> quizzes)
  {
     var thisWeekFirstDay = _dtSvc.GetStartOfWeek(_dtSvc.UtcNow);
     return CalculateStreak(streak, quizzes, thisWeekFirstDay);
  }

Promoting a difficult-to-stub local variable to a parameter has significantly simplified the process of arranging unit tests for our method. Additionally, the data retrieval logic of the DateTimeService didn’t gel well with the rest of the behaviour in CalculateStreak() which is business logic solely concerned with how we calculate the length of a student’s streak.

Prefer Monostate To Singleton

Photo by Raymond T. on Unsplash

Yesterday we explored the famous The Singleton Pattern – Code Coach. Today we’ll look at the Monostate Pattern which we can often substitute for Singleton. Both Monostate and Singleton solve the same problem: 

The data must always be in sync and in a single location. 

That is the only reason we should apply either of these patterns; not because it makes the logic simpler to have only a single instance. Most of the time, you want to use regular instance objects, where each holds its own internal state different from the others. 

OK. Let’s take a look at the Monostate. How do we create a Monostate class?

• We declare our backing fields as static.

I like to think of static state as utterly separate from instance state. It’s memory that is not part of the instance at all. When we declare a field or property as static, it means we have only a single copy shared by all objects.

Here is a simple Monostate class definition:

  public class Monostate
  {
     private static string data;

     public string Data
     {
        get { return data; }
        set { data = value; }
     }

     public Monostate()
     { }
  }

It looks deceptively like an instance class. But having the backing field declared as static makes all the difference: There is only one copy of the data.

How does our Monostate behave?

var monostate1 = new Monostate();
var monostate2 = new Monostate();

monostate1.Data = "blah";

Console.WriteLine($"monostate1.Data: {monostate1.Data}");
Console.WriteLine($"monostate2.Data: {monostate2.Data}");

And the output will be

monostate1.Data: blah
monostate2.Data: blah

Yet we only set monostate1.Data. monostate2.Data contains the same value since it is pointing to the same backing data.

It means we can create as many instances as we see fit, and they will all represent the same data. 

One of the criticisms the Monostate pattern attracts is that from the outside it looks like a regular class, but on the inside it behaves differently. My view differs – I believe that this is a strength. It’s an example of object-orientation (OO) at its best – using Abstraction and Encapsulation. 

We should ask the question: Why do the callers need to know the internal implementation? It’s none of their business. The static backing state is encapsulated and hidden from callers of the class. The class does its job – how it does, is not a concern of the calling code.

OK, here are some further points comparing Monostate and Singleton:

• Singletons use a static factory method to return the single instance. Monostate objects can be instantiated the usual way – using the new operator.
• Both Singletons and Monostate are classes and can implement interfaces. When working with the abstracting interfaces, both can be mocked in unit tests easily enough. On the other hand, when we must overcome instantiation of Singleton (static method) or Monostate (new operator) in a chunk of code we are trying to unit test, then this is equally awkward and difficult.
• Suppose we want to move away from Monostate to a regular, instance class implementation. In that case, we can inject an instance class against the interface without having to modify the calling code.
• With multiple concurrent threads accessing the Singleton instantiation logic, we could end up with more than a single instance. Monostate does not have this problem; simultaneous threads can safely create Monostate objects. 
• Both Monostate and Singletons require locking on access to static fields to be threadsafe.

Monostates objects look and feel like instance objects, but their implementation differs to suit their ‘single copy data’ requirements. Why should we need to use a different programming paradigm (i.e. Singleton) because we desire a different implementation? We don’t;

Prefer Monostate to Singleton.