In the beginning there was... logic. Logic was all there was.
Software is about behavior. When triggered by a user, e.g., by clicking on a button, it's supposed to produce a response. Activity is kicked off, transforming input into output, a request into a response - plus possibly changing some state stored internally, in a database, or in some other software.
Take this little program as an example:
It's run like this:
The behavior is triggered by starting the program on the command line. It asks for input from the user. Then it transforms the input and prints a response on the console.
The purpose of the code is to check if the string entered is a palindrome, i.e., it reads the same backwards and forwards.
The code of the program is pure logic:
Logic is the non-whitespace part of code to which any change will cause a change in program behavior.
Logic consists of:
expressions
control flow statements (if-else, for, while etc.)
calls to I/O functions (or more generally: calls to functions whose source code you don't have access to)
Logic is "the magic dust" mentioned in
The "unnamed 'stuff' that actually creates behavior in software" and which is contained in objects to let them react to messages:
The logic inside an object is what transforms an input message into zero, one, or more output messages plus possibly changes to some state:
Logic seems so innocent and innocuous, it's so natural, it's everywhere. Why bother to talk about it much and name it? The reason is simple: it's not only what actually does the job, it's also very, very hard to understand and needs rigorous testing.
All the fuss about object-orientation only makes sense if you really grasp how difficult it is to deal with a growing amount of logic. The above might not make that palpable for you; it's just a couple of lines of logic. I told you what the code's purpose is, you have a quick look, and understand it. Excellent!
But step back a second and look at what you had to do: during your "quick look" you had to interpret the logic. That means, you had to simulate its functionality in your head. You executed the program at least in a rough manner in your mind, e.g.
"First the user is asked for a string to check. Then the string is cleaned. Hm... what does that mean? Ah, any whitespace is removed and it's made all lowercase.
Then a reversed version of the input is produced. The loop starts at the end of the string and runs to its beginning. Each character is appended to a new string which thus contains the characters in reverse order. Ok, that's straightforward. But, hm... isn't there a simpler way?
Finally the reversed string is checked against the cleaned input string. If they are the same, then the input string is a palindrome. This result is printed to the console."
Sure, you are an experienced developer. You immediately get how the program accomplishes its task. You even have a solid sense of the logic being correct.
But what about the following code? It's pure logic again. How long does it take you to understand what it's doing and if it's correct?
If that became a very frustrating task quickly, I understand. It's really not fun to understand and reason about logic. It requires a lot of effort and experience.
To make it easier there are of course all sorts of recommendations, e.g., use meaningful identifiers, use whitespace, use comments. But there is only so much you can do with and around logic to make it easier to understand.
And what about testing? Do you want to manually run a program like this again and again while implementing the logic? No, you want automated tests. But where to apply them? Do you always want to check the full logic? Surely not, when it's growing even further due to new requirements.
You see, logic is really tough. It's "magic dust," it solves problems for users, but you need to get a grip on it. It needs more code and concepts to manage larger and larger code bases.
That's what drove the demand for structured programming in the 1960s. That's what motivated Alan Kay to come up with object-orientation.
Let's see how logic can be tamed with Radical Object-Orientation...
Stay tuned for articles introducing you step by step to using the means of a object-oriented 3GL programming language of your choice to build code bases following the principles of Radical Object-Orientation.







