About Eyal Golan

Eyal is a professional software engineer and an architect. He is a developer and leader of highly sophisticated systems in different areas, such as networking, security, commerce and more.

Why Abstraction is Really Important

Abstraction

Abstraction is one of the key elements of good software design. It helps encapsulate behavior. It helps decouple software elements. It helps having more self-contained modules. And much more.

Abstraction makes the application extendable in much easier way. It makes refactoring much easier. When developing with higher level of abstraction, you communicate the behavior and less the implementation.

 

General

In this post, I want to introduce a simple scenario that shows how, by choosing a simple solution, we can get into a situation of hard coupling and rigid design.

Then I will briefly describe how we can avoid situation like this.

Case study description

Let’s assume that we have a domain object called RawItem.

public class RawItem {
    private final String originator;
    private final String department;
    private final String division;
    private final Object[] moreParameters;

    public RawItem(String originator, String department, String division, Object... moreParameters) {
        this.originator = originator;
        this.department = department;
        this.division = division;
        this.moreParameters = moreParameters;
    }
}

The three first parameters represent the item’s key. I.e. An item comes from an originator, a department and a division. The “moreParameters” is just to emphasize the item has more parameters.

This triplet has two basic usages:

  1. As key to store in the DB
  2. As key in maps (key to RawItem)

Storing in DB based on the key

The DB tables are sharded in order to evenly distribute the items. Sharding is done by a hash key modulo function. This function works on a string.

Suppose we have N shards tables: (RAW_ITEM_REPOSITORY_00, RAW_ITEM_REPOSITORY_01,..,RAW_ITEM_REPOSITORY_NN),
then we’ll distribute the items based on some function and modulo:

String rawKey = originator + "_"  + department + "_" + division;
// func is String -> Integer function, N = # of shards
// Representation of the key is described below
int shard = func(key)%N;

Using the key in maps

The second usage for the triplet is mapping the items for fast lookup. So, when NOT using abstraction, the maps will usually look like:

Map<String, RawItem> mapOfItems = new HashMap<>();
// Fill the map...

“Improving” the class

We see that we have common usage for the key as string, so we decide to put the string representation in the RawItem.

// new member
private final String key;

// in the constructor:
this.key = this.originator + "_" + this.department + "_"  + this.division;

// and a getter
public String getKey() {
  return key;
}

Assessment of the design

There are two flows here:

  1. Coupling between the sharding distribution and the items’ mapping
  2. The mapping key is strict. any change forces change in the key, which might introduce hard to find bugs

And then comes a new requirement

Up until now, the triplet: originator, department and division made up a key of an item. But now, a new requirement comes in. A division can have subdivision. It means that, unlike before, we can have two different items from the same triplet. The items will differ by the subdivision attribute.

Difficult to change

Regarding the DB distribution, we’ll need to keep the concatenated key of the triplet. We must keep the modulo function the same. So distribution will remain using the triplets, but the schema will change and hava ‘subdivision’ column as well. We’ll change the queries to use the subdivision together with original key.

In regard to the mapping, we’ll need to do a massive refactoring and to pass an ItemKey (see below) instead of just String.

Abstraction of the key

Let’s create ItemKey

public class ItemKey {
    private final String originator;
    private final String department;
    private final String division;
    private final String subdivision;

    public ItemKey(String originator, String department, String division, String subdivision) {
        this.originator = originator;
        this.department = department;
        this.division = division;
        this.subdivision = subdivision;
    }

    public String asDistribution() {
        return this.originator + "_" + this.department + "_"  + this.division;
    }
}

And,

Map<ItemKey, RawItem> mapOfItems = new HashMap<>();
// Fill the map...
// new constructor for RawItem
public RawItem(ItemKey itemKey, Object... moreParameters) {
    // fill the fields
}

Lesson Learned and conclusion

I wanted to show how a simple decision can really hurt.

And, how, by a small change, we made the key abstract. In the future the key can have even more fields, but we’ll need to change only the inner implementation of it. The logic and mapping usage should not be changed.

Regarding the change process, I haven’t described how to do the refactoring, as it really depends on how the code looks like and how much is it tested. In our case, some parts were easy, while others were really hard. The hard parts were around code that was looking deep in the implementation of the key (string) and the item.

This situation was real

We actually had this flow in our design. Everything was fine for two years, until we had to change the key (add the subdivision). Luckily all of our code is tested so we could see what breaks and fix it. But it was painful.

There are two abstraction that we could have initially implement:

  1. The more obvious is using a KEY class (as describe above). Even if it only has one String field
  2. Any map usage need to be examined whether we’ll benefit by hiding it using abstraction

The second abstraction is harder to grasp and to fully understand and implement.

So, do abstraction, tell a story and use the interfaces and don’t get into details while telling it.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

2 Responses to "Why Abstraction is Really Important"

  1. Great post, is really useful for novice and expert programmers, thanks for sharing.

  2. Eyal says:

    Thanks !

    Glad you liked it.

Leave a Reply


+ two = 9



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close