Posted on by Dmitrii

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:

using System;
using System.Linq;
namespace ConsoleApp4
{
class Program
{
static void Main()
{
int? firstOperand = null;
int? secondOperand = null;
char operation = '0';
int? result;
Console.WriteLine($"Enter first integer number:");
var success = int.TryParse(Console.ReadLine(), out var intValue);
firstOperand = success ? (int?) intValue : null;
Console.WriteLine($"Enter second integer number:");
success = int.TryParse(Console.ReadLine(), out intValue);
secondOperand = success ? (int?) intValue : null;
Console.WriteLine($"Enter operation sign:");
char.TryParse(Console.ReadLine(), out operation);
if (firstOperand != null &&
secondOperand != null &&
"+-*/".Contains(operation))
{
switch (operation)
{
case '+':
result = firstOperand + secondOperand;
break;
case '-':
result = firstOperand - secondOperand;
break;
case '*':
result = firstOperand * secondOperand;
break;
case '/':
result = firstOperand / secondOperand;
break;
default:
result = null;
break;
}
Console.WriteLine(result == null
? $"Can't calculate this"
: $"The result is {result.ToString()}");
Console.WriteLine($"Press any key");
Console.ReadLine();
}
}
}
}
view raw Calculator_AllInOneMethod.cs hosted with ❤ by GitHub

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

using System;
using System.Linq;
namespace ConsoleApp2
{
class Program
{
static void Main()
{
Calculator.Clear();
Calculator.GetFirstOperand();
Calculator.GetSecondOperand();
Calculator.GetOperation();
if (Calculator.IsInputValid())
Calculator.Output();
}
public static class Calculator
{
private static int? _firstOperand;
private static int? _secondOperand;
private static char _operation;
public static void Clear()
{
// setting operands and operation to not valid values
_firstOperand = null;
_secondOperand = null;
_operation = '0';
}
public static void GetFirstOperand()
{
Console.WriteLine($"Enter first integer number:");
GetOperand(out _firstOperand);
}
public static void GetSecondOperand()
{
Console.WriteLine($"Enter second integer number:");
GetOperand(out _secondOperand);
}
private static void GetOperand(out int? operand)
{
var success = int.TryParse(Console.ReadLine(), out var intValue);
operand = success ? (int?)intValue : null;
}
public static void GetOperation()
{
Console.WriteLine($"Enter operation sign:");
char.TryParse(Console.ReadLine(), out _operation);
}
public static bool IsInputValid()
{
// returns true if both operands were set correctly
// and operation is from valid list
return _firstOperand != null &&
_secondOperand != null &&
"+-*/".Contains(_operation);
}
private static int? GetResult()
{
switch (_operation)
{
case '+':
return _firstOperand + _secondOperand;
case '-':
return _firstOperand - _secondOperand;
case '*':
return _firstOperand * _secondOperand;
case '/':
return _firstOperand / _secondOperand;
default:
return null;
}
}
public static void Output()
{
var result = GetResult();
Console.WriteLine(result == null
? $"Can't calculate this"
: $"The result is {result.ToString()}");
Console.WriteLine($"Press any key");
Console.ReadLine();
}
}
}
}
view raw Calculator_Class.cs hosted with ❤ by GitHub

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: 

using System;
using System.Linq;
namespace Calculator
{
class Program
{
static void Main()
{
UserInterface.AskUserForState();
StateParser.Parse();
if (StateValidator.IsStateValid())
{
var result = Calculator.GetResult();
UserInterface.OutputResult(result);
}
else
{
UserInterface.ErrorMessage($"Something is wrong with input");
}
}
}
/// <summary>
/// Container for user input data
/// </summary>
public static class State
{
public static dynamic FirstOperand;
public static dynamic SecondOperand;
public static char Operation;
public static string FirstOperandString;
public static string SecondOperandString;
public static string OperationString;
}
/// <summary>
/// Parser for State
/// </summary>
public static class StateParser
{
public static void Parse()
{
ParseOperand(State.FirstOperandString,
out State.FirstOperand);
ParseOperand(State.SecondOperandString,
out State.SecondOperand);
ParseOperation();
}
private static void ParseOperand(string operandString,
out dynamic operand)
{
if (int.TryParse(operandString, out var intValue))
operand = intValue;
else
if (double.TryParse(operandString, out var doubleValue))
operand = doubleValue;
else
if (decimal.TryParse(operandString, out var decimalValue))
operand = decimalValue;
else
operand = null;
}
private static void ParseOperation() =>
char.TryParse(State.OperationString,
out State.Operation);
}
/// <summary>
/// Checker for State based on a set of rules
/// </summary>
public static class StateValidator
{
public static bool IsStateValid() =>
IsOperandNotNull(State.FirstOperand) &&
IsOperandNotNull(State.SecondOperand) &&
IsOperationValid() &&
IsNotDivisionByZero();
private static bool IsOperandNotNull(dynamic operand) =>
operand != null;
private static bool IsOperationValid() =>
Calculator.CanDo(State.Operation);
private static bool IsNotDivisionByZero() =>
!(State.Operation == '/' &&
State.SecondOperand == 0);
}
/// <summary>
/// Does operation on operands defined by State
/// </summary>
public static class Calculator
{
/// <summary>
/// Returns true if operation is provided by Calculator
/// </summary>
public static bool CanDo(char operation) =>
"+-*/".Contains(operation);
public static dynamic GetResult()
{
switch (State.Operation)
{
case '+':
return State.FirstOperand +
State.SecondOperand;
case '-':
return State.FirstOperand -
State.SecondOperand;
case '*':
return State.FirstOperand *
State.SecondOperand;
case '/':
return State.FirstOperand /
State.SecondOperand;
default:
return null;
}
}
}
/// <summary>
/// Responsible for user-computer operations
/// </summary>
public static class UserInterface
{
public static void AskUserForState()
{
Console.WriteLine($"Enter first integer number:");
State.FirstOperandString = Console.ReadLine();
Console.WriteLine($"Enter second integer number:");
State.SecondOperandString = Console.ReadLine();
Console.WriteLine($"Enter operation sign:");
State.OperationString = Console.ReadLine();
}
public static void OutputResult(dynamic result)
{
Console.WriteLine(result == null
? $"Can't calculate this"
: $"The result is {result.ToString()}");
Console.WriteLine($"Press any key");
Console.Read();
}
public static void ErrorMessage(string message)
{
Console.WriteLine(message);
Console.WriteLine($"Press any key");
Console.Read();
}
}
}
view raw Calculator_SixClasses.cs hosted with ❤ by GitHub

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.

Summary

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 *