Category Archives: Clean Code

Object Oriented Design and Clean Code

Unit Testing Basics

Episode 62

Previous episode was about talking to database in Spring. Today we will continue exploring basics of building web applications, and talk about unit testing. This time, however, we are going to leave Spring alone for a moment and focus on plain unit tests using JUnit, Mockito and DataProvider.


As usual, all the code presented in this article is available on my GitHub in the same project as before. This tag corresponds to project state at the time of writing this article. Let’s start with some basic ideas, and why write unit tests in the first place.

Client does not pay for unit tests

Well, I have heard that once. I was in a project where code coverage was around 2%, and when I was actively trying to improve upon that, manager took me to a one on one discussion to a small room. Starting to cover old projects with tests is often difficult, but in the end the business pays much more for not having decent automatic test harness than saving on skipping it and only producing features. It simply pays back in the long run. There are less unnoticed bugs, design is cleaner, the amount of tedious repetitive work is dramatically reduced. Often it is much faster to Read the rest of this entry »


Posted by on March 23, 2017 in Clean Code, Spring, Technology


Tags: , , ,

Pay your debts

Episode 41

I’ve seen recently a nice movie based on actual events – the Deepwater Horizon. Aside from being well made and entertaining, the movie had an additional value to me. It was a story of what happens to a project with insufficient tests and short sighted management putting pressure to release unfinished product with monstrous technical debt. It blows up in huge ball of fire.


Technical debt

Ward Cunningham coined the term technical debt while working on financial software. The idea is, that when developing software, you can often go in two directions. You can spend more time and implement the new functionality cleanly, soundly and with respect to existing architecture. If the functionality does not Read the rest of this entry »

Leave a comment

Posted by on October 27, 2016 in Agile, Clean Code, Technology



I know what you committed last summer

Episode 31

            As promised, the continuation of Code of Principles is here. This time I’m going to talk about stuff that is less canonical and perhaps not so well known. Today’s motto is that you are not alone. There are strangers, psychopaths, users, fellow developers and good scouts out there.

Don’t talk to strangers


            Let’s discuss Law of Demeter also known as Principle of least knowledge. Proposed in 1987 by Northeastern University, can be informally described in four bullet points:

  • You can play with yourself (naughty boy).
  • You can play with your own toys (but you can’t take them apart).
  • You can play with toys that were given to you.
  • And you can play with toys you’ve made yourself.

Which basically means that object should assume as little as possible about its environment, surroundings, its structure, properties and anything else, especially about Read the rest of this entry »


Posted by on August 18, 2016 in Clean Code, Sweet Sixteen


Tags: , ,

Code of Principles

Episode 30

            Enough about recruitment, let’s get back to code. This article is (more or less)  going to be a continuation of Rock SOLID Code. I’ve talked about five principles forming letters in the SOLID acronym, now I’m going to talk about further set of well known (hopefully) programming (and not only) concepts.

(K)eep (I)t (S)imple, (S)tupid

kiss problem

            “Everything should be made as simple as possible, but not simpler.” Albert Einstein once said. KISS acronym was coined by Kelly Johnson, U.S Navy engineer in the sixties. Basically, simple thing doing the same job as complex thing is better. It’s easier to understand which means being less error-prone, easier to maintain, cheaper and more efficient. Always try to Read the rest of this entry »


Posted by on August 11, 2016 in Clean Code, Sweet Sixteen


Tags: , , , , ,

How to slim down your Java

Episode 16

This article is the second part of my Java performance guide. After concentrating on how to make code fast, let’s turn to how to make code eat less memory. There are two important things to consider:

First, in modern computers, memory access time is more limiting than CPU frequency.

Second, when talking about algorithms from academic point of view, it is said, that there is a tradeoff between speed and memory. That’s of course true, however keep in mind, that memory allocation takes time, memory read/write takes time and finally garbage collection takes time. If you turn on heap status in Eclipse, you can sometimes literally see how the code is reaching 99% percent of the heap and then execution time hits the wall and things slows down a lot. GC is working hard to make things possible. If it is possible, otherwise you are getting OutOfMemoryError and you are done.


Java, wat r u doin! Java, staph…

Of course, you can increase heap space to make things happen. However you can’t do that indefinitely (unless you are Google). Although one of my PO’s said once that we shouldn’t worry because clients have unlimited memory, you should worry. Not always, and maybe not even half the time, but being reckless with memory might hit you hard in some particular cases.

Code that is memory efficient might be complicated, hard to maintain and error prone, but there are few thing you can keep in mind and use without introducing unnecessary complications. Sometimes, as I said in previous article, code that is faster or takes less memory may be even more elegant and readable.

So when to optimize size?

Again, get to know your code. Study, experiment, check out the production database (if you have access), do some statistics. If you have a collection containing all your users, check out how much user you have. If it’s a problem, look for high level solution. Perhaps you don’t need all users at one time? Maybe you can process them in batches? Maybe you can load lazily? Maybe you can construct some kind of cache?

If this approach fails, you can tweak stuff at lower level of abstraction, and that’s what we are going to discuss now.

Objects size

Object header in Java takes 12 bytes. However objects on heap are allocated in 8 bytes blocks, thus making smallest Objects take 16 bytes. Primitive sizes are:

  • byte – well, 1 byte
  • short, char – 2 bytes
  • int, float – 4 bytes
  • long, double – 8 bytes
  • Reference – 4 bytes if heap is under 32 GB with default VM settings and 8 bytes otherwise.

So if you are thinking of reducing your object size from 32 to 28 or 26 bytes, I have bad news for you. It will still take 32 bytes no matter what.

byte and short pitfall

Primitives as objects fields always take a minimum of 4 bytes. So using bytes or shorts instead of ints as fields to save memory is useless. Arrays however are dense packed, so you may use byte and short array to get some savings.

Primitives vs wrappers

Wrappers carry the Object overhead. They take at least 16 bytes, and Long and Double takes 24. Plus 4 bytes for each reference to them. If you have a lot of data, and don’t need a null value, you can use primitives instead of wrappers to save memory. For example in a User object, if you only read data from database, you can probably use long instead of Long for primary key and save 16 bytes per object. On the other hand, if you use ORM framework, you may create objects by hand and then persist them, which means that primary key will be null at some point.


  • Primitive array of length n: 16 + (1 to 8) * n depending on primitive type.
  • Objects arrays: 16 + (4 + object_size) * n on heap below 32 GB.


Each String contains a few ints, a reference to char array and the array itself. It all takes 40 + 2*n depending on number of characters. What does it mean? If you have a lot of very short Strings, you have a lot of overhead. If you have only one-letter strings, it’s probably better to use chars instead.


Now it’s getting interesting.

  • ArrayList: 40 + (4 +object_size) *n + 4 * unused_capacity
  • LinkedList: 48 + (24 + object_size)

Yes, LinkedList has 6 times more overhead per node. That’s another reason to use ArrayList instead most of the time. Array list resizes itself automatically, so it usually has some unused space. If you know that no more data will be added, you may use it’s trimToSize method to remove unnecessary overhead. Not very much, but with lots of small objects it might be visible.


  • HashMap: 56 + (32 + object_size + key_size) * n + 4 * capacity
  • LinkedHashMap: 56 + (40 + object_size + key_size) * n + 4 capacity
  • TreeMap: 56 + (40 + object_size + key_size) * n + 4 * capacity

I had a situation where there was a graph node object, that contained several eagerly initialized collections, that were empty 95% of the time. It turns out that when number of nodes went in millions, it was a serious problem. Creating collections lazily might save you some space.

By the way, Sets in Java contains Maps, so they have same size per node, with additional overhead per Set Object.


There are libraries of specialized collections, like Trove. They are optimized for memory footprint. For example THashMap takes only 8 bytes per key / value pair instead of 40 as standard HashMap

EnumMap, EnumSet – specialized collection in standard Java. As, most of the time, Enums do not have more than 32 or 64 values, Set of enums may be represented as bit mask based on int or long. It reduces a lot of overhead for MapEntry objects.

BitSet. Dense packed bit vector, that only takes, well, only 1 bit per bit or boolean value. Normal boolean in Java occupies 4 bytes if it’s a variable or 1 byte if it’s in an array.

What’s next?

Perhaps I will come back to the topic of performance. I have a new book, Java Performance The Definitive Guide added to my long reading list. I hope it will be interesting and third episode about performance will be born on this blog afterwards.

Speaking of reading list, next episode is going to be a book review. Stay tuned ;)


Leave a comment

Posted by on September 28, 2014 in Clean Code, Technology


Tags: ,

Lightning Fast Code

Entry 15, Day 51

As promised, today’s episode is going to be about low-level optimization. First, a quote.

„Premature optimization is the root of all evil”

   – Donald Knuth

Yes indeed. We all love when things go faster than slower, but deadlines are tight and working, stable software with acceptable performance is better than software which is fast but unstable or not working at all. There is no point in tuning your Java computation to take 5 milliseconds instead of 50, when you are going to wait for database query that takes 5 seconds (optimize the query, maybe?). Also, in case of web application, there will be network latency of tenths or hundreds of milliseconds. Another issue is code readability. Sometime, to run faster, the code has to be more complicated and that’s always pain in the ass…


So when to optimize?

First, get to know your API. There are many small problems, that are already solved by standard Java library. And solved well, for example using Read the rest of this entry »


Posted by on September 21, 2014 in Clean Code, Sweet Sixteen, Technology


Tags: ,

Rock SOLID Code

Entry 12, Day 27

          You came back to me, good, good. As I’ve promised, this episode will be about SOLID. What’s that? It’s an acronym for five fundamental principles in object oriented programming coined in early 2000’s by Michael Feathers and Robert C. Martin (aka Uncle Bob). I’ve added Michael’s and Robert’s blogs in Places section, it’s highly recommended reading. Each principle is also covered by an article under “Read more” link. There are C++ examples, but it doesn’t really matter, ideas are valid for any statically typed language.

Now, let’s get down to business. Letters in SOLID stand for:

(S)ingle Responsibility Principle

          A class should have one, and only one, reason to change. Class should do one thing. Or broadly speaking, the context (method, class, package, module, etc.) should have a single responsibility and that responsibility should be encapsulated by this context. Why? Imagine a Read the rest of this entry »


Posted by on August 28, 2014 in Clean Code, Sweet Sixteen


Tags: , , , , ,

Legacy of the Void

Entry 11, Day 24

I’ve promised you episode on database, but I’ve lied. Okay, not exactly. Database was my plan, but I haven’t managed to play with the tools before leaving Wrocław for my short vacation. I’ve left behind my dev machine so let’s leave tools too for a week or two. But I’m not leaving you, dear reader.

Until now, I was mainly writing about enterprise stuff connected with my project. There are however many other topics I’d like to touch in this blog. One of them is Object Oriented Design. So today, for starters, since at the beginning there was nothing, I’m going to tell you about the Null Object, behavioural Design Pattern.

The definition says:

In object-oriented computer programming, a Null Object is an object with defined neutral (“null”) behaviour. Example:


Why bother? Because using Null Objects protects you from Null Pointer Exceptions and lets you get rid of ever-present null check logic in the code. So, instead of using null Animal references, you want to use NullAnimal objects. It will not throw NPE in your face, you don’t have to check if it’s there. It will just gracefully do nothing if interacted with. This is the classic – dedicated Null Object class, now let’s move to other, not so obvious usage.

Say you have some kind of state in the form of an enum. But sometimes the state is not present, or somehow unknown. You may use null for that, but you may also add an additional value – “UNKNOWN”, “NONE”, “SHIT_HAPPEND” or something like this. Usually cleaner and safer than null reference.

Third idea, if your object contains a collection, initialize it. Don’t rely on it being delivered via setter later. It is likely that the setter won’t be called, “because of reasons”. But if you put an empty collection at object creation, you are safe to iterate over it later, unless somebody explicitly sets null there, which is rather unlikely (you may also hide the setter itself if you like). There are situations where such practice turns out to be bad however. Be aware that empty collection has some size. It depends on system and VM implementation, but you can count from 40 bytes on ArrayList to around 70 on HashSet. Not much, but I had a case where graph node had several empty collections and when node numbers went into millions, there were corpses of virtual machines lying everywhere.

Finally, there is a nice class in Google Guava, the Optional<T>. It’s an immutable wrapper that can contain another object or null. It can return this object, or null or some default value. It can tell if there actually is an object, or not. It’s good, because you explicitly say that it’s okay to have null value here. The value is optional, as the class name says. Let’s see how it looks like in practice:


That’s about it. There are some issues to consider though. For example – Null Objects shouldn’t change their neutral behaviour. If they do, they actually belong to State Pattern. Null Objects may be special case of Strategy Pattern, representing strategy that well… does nothing.

There are also some caveats in Null Objects. Sometimes clean logic and lack of exceptions may hide erroneous program execution. So, for example, if you expect collection not to be empty, you should do some check before simply iterating over it zero times and move on in silence.

Project-wise, well… I’m proud owner of domain now, where you will find the application’s production environment in the future.

In the next episode, we will talk about SOLID code. Stay tuned.

Legacyof the Void

Leave a comment

Posted by on August 25, 2014 in BookSentry, Clean Code, Technology


Tags: ,

The Matrix

Entry 5, Day 8

The first matrix I designed was quite naturally perfect. It was a work of art. Flawless. Sublime. A triumph only equaled by its monumental failure.

– The Architect

Software Architecture is the high level structure of a software system. Now I’m smart, I have Wikipedia.

Sometimes, if you ask a developer what is the architecture of the system he is working on, he would say something like, “Well, we have a JSP view, we use EJB to figure things out, Hibernate to persist and everything sits on top of Weblogic server”. Actually, this is not an architecture description, this is a list of technologies used to create the system (or, if you need a fancy term: the technology stack). Of course, there is a slight hint, that we are dealing with a client – server application with at least three layers.

Architecture might be client – server, peer to peer, event driven, rule based, plug-in based or other. Or the combination of them.

As I said before, I’m aiming for agile, emergent design. It does not imply, that I don’t have some kind of vision of what I want to write. I will probably go with client – server, multi tier application. What does this mean? We know more or less, what is 3 – tier architecture: we have a Presentation layer, Business Logic layer and Data layer. So where is the fourth and fifth or any further layers? Well, you may divide those layers further. Let’s take a look.

Presentation is well… presentation. But if you go beyond simple CRUD, it might turn out, that you need some kind of logic just for managing presentation (fancy drag n drop and dynamic stuff support for example), not really business logic layer, but layer separate from static HTML inputs. So, you may split this into two.

Business Logic might have controllers, which glues together front end and back end. And then, they might have EJBs or Spring Services, which performs actual computations or choices having data and given user input. Or other input for that matter, say JMS messages or WebServices calls from foreign systems. Also, you may split service in as many layers as you need depending on the case. Some systems might be very sophisticated, and saying that there is just one business logic layer would not be an understatement.

Data layer may consists of Data Access Objects, which gives you data in the form of cute little Java objects magically drawn from the database. Then there is the magical Object Relational Mapping Framework at work, preparing and running queries in SQL native to the database, transparently for the user. Database is the, more or less, final layer, and besides table definition it may consists of triggers, scheduled jobs (for partitioned tables periodic cleanup, for example) and some other nasty things. Perhaps there are also other layers in the database department, but well… I’m more like in the Java department, so I won’t dig deep here.

Some developers shun the idea of doing any logic outside of Java code (I’m not talking about external libraries, but I will later). I was such developer once. But I’ve figured out, that some things may be better done outside of Java, even though I cannot put a breakpoint there. I’d love to think about them as Java minions who do some magic yet inferior things, but as long as they do it well, I have no objections. Otherwise I will have to frown my eyebrows, get out of coziness of my beloved Eclipse and step in to figure out why SQL or ant script is behaving badly.




Leave a comment

Posted by on August 9, 2014 in BookSentry, Clean Code, Technology


Tags: , , ,