Understanding levels of abstraction can improve your code design

The right level of abstraction in coding helps your code become easier to read/understand and bringing consistency and a logical design to your code. When you see the right level of abstraction used it intuitively seems right.

Getting the correct level of abstraction is creating a consistent level of design in your code.

Understanding Abstraction

Understanding Abstractions in code design is difficult and takes repeated attempts at learning the concepts. It’s worth persevering with because abstractions play a key role in code design and two important concepts of good code design

Encapsulate what varies
Code to an interface not a concrete class

To get started with abstraction in code design and understand the benefits read my blog post below

Why understanding abstractions can help you write better code

The right level of Abstraction

There are many articles/books which mention the concept of getting the level of abstraction right in your when designing code but not many of them explain the concept clearly.

To know if you understand something you should be able to explain it someone (or yourself) in simple terms don’t understand it well enough.

Albert Einstein

I found the concept of the right level of abstraction difficult to understand until I read a great section on exceptions in Code Complete 2. The chapter described defensive programming and exception handling. Below I will go through a similar example found in the book.

When you choose to pass an exception to the caller, make sure the exception’s level of abstraction is consistent with the routine interface’s abstraction

If I had a class called car with a method to return the engine size


Class Car{

Public GetEngineSize() throws&amp;nbsp;ArrayTypeMismatchException

}

Calculating the engine size if all the correct fields aren’t set the code throws an ArrayTypeMismatchException, so the code throws this error.

Now ask yourself the question, is this exception the right level of abstraction?

The calling code doesn’t need to know the detailed error about arrays or type conversion errors. Instead the calling code is more interested in data is not available.

The right level of abstraction would be improved with this error

Public GetEngineSize() throws CarDataNotAvailable

The calling function level of abstraction is concerned about the Car data, the original error message was at a lower level of detail. The lower level of detail is the correct error to the concrete car class which implements the code logic, it’s useful to know what type of exception is thrown because it might deal with different errors in different ways.

The interface is a higher level, Engine, wheels, colour. Classes using the interface are only interested in problems with the data, not the actual error which caused the problem.

The benefits of getting the right level of abstraction are

The code feels right
The design of the code is logical and easy to understand
Consistency

Why should I care about the level of abstraction

Setting the right level of abstraction is one small part of the process of improving the design of your code to make it easier to maintain in the future.

Finding the right level of abstraction for your code is often done after the initial code has been written.

Creative writers have to edit their first draft, advice to writers is to give themselves permission to write a bad first draft.

Writing code is similar because the first draft of code is focused on getting the code working, delivering the required functionality. Designing good code is an emerging process, which I discuss in this blog post

Unit tests are a vital part of emerging code design

Developers should refactor their code after the initial draft. The initial draft usually gets the code to work (short term goal) further iterations should improve the code by

simplify the code
reduce complexity
Improve readability
Improve the naming of classes, methods and variables
reduce coupling by creating new classes and methods
Setting the right level of abstraction and putting code in the right place

Another similarity with writers emerges because hopefully we are removing unnecessary lines (and methods). In coding terms fewer lines of code means fewer lines of code to maintain, debug and read.

The refactoring and improving the design of the code is a stage often missed out by many developers. The code will still work the same so many developers don’t see the value of refactoring and improving the design of the code.

The code working as required is the initial requirement

Refactoring and improving the design fore fills the long term requirements of maintaining code once written, such as

Reading/understanding the code
Resusing code
Easier to debug
Easier to extend
Reduces the effects of change on the code

If you miss out the refactoring stage you will soon end up creating legacy code and technical debt. Read the articles below for more information

Conclusion

Good development is as often making lots of small good choices and avoiding making mistakes. Each complex method/class you avoid writing should be replaced with something simple. Putting code in the right place and getting the level of abstraction correct is one of many small good design choices.

If you add put together lots of good code design choices you will end up with good code.