Growing Redundancy: An architectural disease

As software engineers, we are always against the redundancy of code. Occasionally, the redundancy is known as the fault of developers, and it mostly happens when the developer suffers from code myopia! He has not a good overview of the code, and just seeing what is being written, not seeing the solution as a whole.

Code Myopia: It happens when a developer have not a good overview of the code. The developer is just seeing what is being written, not seeing the solution as a whole.

As a matter of fact, this is not the main idea of this blog! I want to talk about something related, but totally different: Growing Redundancy.

Growing redundancy is a disease in software which is not developer's fault. In fact, it is an architectural disease.

As a developer when you want to write a piece of code that do X, you should write it somewhere! So you should make 2 important decisions: What to write, and Where to write.

Sample

Consider you want to write a code that returns available products in a shopping center.

What to Write?

You may decide to write a method for this. It can be simply:

List<Product> GetAvailableProducts(ShoppingCenter shoppingCenter)
{
    // Query from database and return the list.
}

That is fair enough. You decide to avoid redundancy of writing this business by creating a reusable method: GetAvailableProducts.

Where to Write?

So far, we decided to write a method, but where should we write it? Here are some possible solutions.

Solution 1:

Writing in ShoppingCenter class:

class ShoppingCenter
{
    public List<Product> GetAvailableProducts()
    {
        // Return products of 'this' shopping center.
    }
}

It sounds a good solution because getting available products is related to a shopping center. Also calling this method looks fine:

var availableProducts = shoppingCenter.GetAvailableProducts();

Solution 2:

Creating a static method in Product class:

class Product
{
    public static List<Product> GetAvailableProducts(ShoppingCenter shoppingCenter)
    {
    }
}

So we can call it like:

var availableProducts = Product.GetAvailableProducts(shoppingCenter);

Putting a static method like this sounds cool. In this way we could have all kinds of queryings here. For example we could have lots of methods in Product class like:

class Product
{
    static List<Product> GetAvailableProducts(ShoppingCenter sc) {}
    static List<Product> GetDisconinuedProducts(ShoppingCenter sc) {}
    static List<Product> GetAvailableProducts(Manufacturer m) {}
    static List<Product> GetOwnedProducts(Customer c) {}
    // ...
}

Learning from the sample

Here in this sample, we see that there is 1 answer for what, but 2 answers for Where! We have 2 available spaces which seems appropriate to write our business. What happens next? Solution 1 or Solution 2?

The developer may decide to write it at ShoppingCenter class. But what if some other developer wrote it in Product class before!? Or even worse, what if:

• another developer wrote it in a method with different name:

  List<Product> GetAvailableProductsOfShoppingCenter(ShoppingCenter sc)

• another smart developer created a more general method like:

  List<Product> GetProducts(
      ShoppingCenter sc, 
      Manufacturer m, 
      Customer c, 
      bool isAvailable)

As you see, there are lots of possible spaces for writing that code.

This architectural disease causes the generation of unwanted methods (spaces) in the code.

I'm using the term Space, as I defined it before in following posts:

• Software Architect: It's all about spaces!
• Spaces Shape Your Software Architecture

So this architectural disease causes to generate new unwanted spaces within your code. This is what I'm calling: Growing Redundancy.

This architectural disease make developers tired. They look lazy, but they're tired in fact!