Fighting Complexity of a Simple Calculator App

Encouraged by Dmitry aka Senior Software Vlogger recently I read an interesting paper called “Out of the Tar Pit” by Ben Moseley and Peter Marks. Good 50% of the article is way over my head.

According to the paper the two most important ways of how complexity comes to our apps are State and Control. Control is order in which things happen inside app. State is variables that change what and in which order program does. Both of them make an app hard to understand hence to modify.

The less State and Control a computer program has the better. The simplest program “Hello world!” does not have State and has only one thing to do (console output of a hard-coded string).

That’s all right but the authors say that OOP (which I like a lot) does not help fighting complexity. And this conclusion surprised me because… it really does! I wanted to check the authors conclusion by practice.

Now let me try to make my Calculator console app as simple for understanding as possible. At first I am going to do it in a lazy way:

All the code is placed into one method. 58 lines. It’s not so readable, is it? Let’s split it using OOP approach:

Now it’s nine methods and it’s easier to read and modify the program even there is more lines (94) of code. Lets go further and split the Calculator class into six classes: 

Now it’s twelve methods and 161 lines of code. Nevertheless it looks much more readable then the first two versions. Why?

Probably because there are less focuses of my attention needed when I read the code. When I look at the last version of Main() I can see control expressed with very few lines. Also if I want details I go with classes and their methods and each level of abstraction comes with only few elements.


I understood that there is two kinds of complexity: objective and subjective.

Objective one can be described with number of states or steps of control. Okay, OOP will not help fighting this complexity.

OOP does help making programs more readable splitting them into small, easy to read pieces. This way code gets subjectively less complex.

Leave a Reply

Your email address will not be published. Required fields are marked *