Create Internal Structure

Photo by JJ Ying on Unsplash

One of the problems I repeatedly see within our industry, i.e., software engineering, is that not nearly enough engineering is taking place. I believe that software engineers, if that is what we are, should always have ‘better engineering‘ at the front of their minds: ‘How can I structure this better?’, ‘This code is useful—how can I make it reusable?’, ‘What are the different responsibilities here, and how can I separate them?’, etc..

I know that the degree of engineering a programmer brings to their code comes down to experience. And that’s why I write this blog—so that it can be an agent for change and help uplift those programmers who want to become better at their craft and write ‘less crappy’ code each day. I am not being haughty; that’s my goal too—to improve a little each day so that the code I write tomorrow is a little bit less crappy than my programming today. The goal is getting better, not perfection.

Rant of the day out of the way—let’s get into it.

Today I would like us to look at one of these engineering oversights and fix them. Let’s look at the Customer constructor example from yesterday’s article on parameter ordering:

  public Customer(string firstName, string lastName, int age,
                  string streetAddress, string townOrCity, Country country,
                  int loyaltyPoints, int loyaltyScore)
  {
     FirstName = firstName;
     LastName = lastName;
     Age = age;
     StreetAddress = streetAddress;
     TownOrCity = townOrCity;
     Country = country;
     LoyaltyPoints = loyaltyPoints;
     LoyaltyScore = loyaltyScore;
  }

This constructor is taking a lot of parameters and setting those to 

individual properties. 

Yesterday we discovered how this set of parameters falls into three cohesive groupings:

• Personal data
• Address data
• Loyalty data

Sometimes a developer will even go ahead and make readers aware of the groupings with comments: 

  public Customer(string firstName, string lastName, int age,
                  string streetAddress, string townOrCity, Country country,
                  int loyaltyPoints, int loyaltyScore)
  {
     // Customer Details
     FirstName = firstName;
     LastName = lastName;
     Age = age;
     // Customer Address
     StreetAddress = streetAddress;
     TownOrCity = townOrCity;
     Country = country;
     // Customer Loyalty
     LoyaltyPoints = loyaltyPoints;
     LoyaltyScore = loyaltyScore;
  }

A comment is good but comments have their problems. We can do better than comments.

Given that the data in these groups belong together, i.e. are cohesive, let’s use our engineering skills and group them together more formally in three separate classes:

• CustomerDetails
• CustomerAddress
• CustomerLoyalty

Here is what the constructor looks like now:

  public Customer(string firstName, string lastName, int age,
                  string streetAddress, string townOrCity, Country country,
                  int loyaltyPoints, int loyaltyScore)
  {
     Details = new CustomerDetails(firstName, lastName, age);
     Address = new CustomerAddress(streetAddress, townOrCity, country);
     Loyalty = new CustomerLoyalty(loyaltyPoints, loyaltyScore);
  }

Such a simple solution yet so often overlooked.

We are the architects of small-scale structure in our program! The comments are no longer required. We have formalised the groupings expressed in the previous comments to the point where readers are in no doubt about which parameters belong together and which don’t. 

Today’s guidance is to formalise cohesive groupings by putting them into classes or similar structures. It’s well worth our while to do this and engineer structure into our programs.

There is more work to be done on the Customer constructor—we’ll do that tomorrow.