Flaws of Object Oriented Modeling

At the beginning of the computer era the system designers came from the world of hardware and it is noticeable. In hardware there are many working elements that can operate in parallel and most times at different rates of operation. This requires hi degree of accuracy in system timing. Chip designers count the number of transistors between two elements to make sure that the Operation Flow is maintained.

The Assembly language defines a set of primitive / native operations. The programming process and software design using Assembly is in direct correspondence with the execution flow. If you want the flow to break then you use the Jump operation explicitly. This is because Assembly was originally designed by hardware developers and was written to accommodate the hardware.

The C language is a procedural language. It was originally created by Assembly programmers (as 'B'). We can still see Assembly type of thinking operations built in the language, for example:
++ is INC
-- is DEC
[A] ? [B] : [C] is equal to:
[A] ;// do operation [A]
JZ ;// if true go to [B]
[C] ;// else do [C]
JMP ;// go to end
[B]
When you are used to working with Assembly you get used to thinking in "test" – "do this if so" – "do this if not". C programmers hardly ever use this.
The C language is a procedural language. It helps us group together sets of operations and also releases us from the need to use Jumps or Go To-s, which can be very simple to track execution flow if you use it correctly but can be easily abused into what was coined as "Spaghetti Code" because of all the lines you need to draw when you try to track the execution flow of an application that was designed incorrectly.

Next evolution, came the language of C++ which is Object Oriented in design. This allows the separation of code modules into discrete software units called a class. Object Oriented programming allows multiple teams of developers to work on the same project very easily. Object Oriented languages can really help the developer manage the code.

The problems that came with Object Oriented programming is that these languages are really designed to help the developer manage the code…
Now it is almost impossible to follow the execution flow. When you want to know what happened in your application when the error message popped up you have to go over all the objects and all the classes that the execution flow went through and many times execution flow travels between several member functions before leaving to another object. Following the execution flow today is almost impossible.

Many times I have seen 'Pure' Object Oriented design producing a code that is a collection of many three-line functions that call each other. Every button click in the application travels through ten or more small functions. You can no longer follow the execution flow by reading the code. This brings two major problems that we face today.

The first problem is that it is no longer possible to detect execution flow bugs with a simple code review. Going over an Assembly code it is very easy to detect simple bugs such as down-casting, potential overflows etc. Reading an object oriented code you can't see the big picture and it is often impossible to review all the small functions that call the one function that you modified.

The second problem with this model is the "Not my fault" syndrome. "I only called a member of another object and it returned FALSE. Don’t ask me why". This is how you get an error that says "Problem with saving the document. Reason is '0x8000745 – unknown', What would you like to do?" What do YOU think I should do?! The programmer got this return value from some object that he is not familiar with and has no idea what this value means so he just pushes that to the higher level. The last level that you can propagate to is the user, and so my mother keeps facing these interesting decisions when she is trying to save a picture.

Object Oriented Modeling was invented to help developers manage the code but had no regard for execution flow. Up till now we used to use step-by-step debugging to see the execution flow. This is no longer relevant when we plan on having multiple threads going over our code. You single step one thread and another completes 5000 loops in the background. If you have multiple threads going over the same function they might all stop on the same breakpoint and you have no way of telling which is which effectively.

Following execution flow today is a terrible problem.

This is the first in a collection of articles that will introduce a new model called the Operation View Model with motivation for using it. This model can define any element in the computer world and it is the next step in software evolution.
Next article will demonstrate how operating systems follow an evolution pattern that is similar to the ones described here.

For more complete information about compiler optimizations, see our Optimization Notice.

28 comments

Top
anonymous's picture

I too work at Intel and am absolutely humored when a fellow hardware engineer / electrical engineer bags on object-oriented programming or C++. To be fair, arming a hardware engineer with C++ turns out to be a really, bad, bad idea: amazing when you consider the parallels of silicon design with object-oriented decomposition. In any case, like most non-software engineers, Asaf completely misses the point of OO. Simply put, OO design exists to manage complexity. And yes, when you're working on 100K+ line programs, it's OK to defer ownership to other folks on the team...

As many mentioned above, you evade the issues mentioned by (1) architecting up front, (2) writing decent code, and (3) using ULTs to validate classes, modules, and layers. And specifically addressing the jumps / multithreading, knowing how to use the debugger often goes a long way in flushing out issues. Of course, considering multithreading in the design phase is probably the only way 100% to the code right. That's kind of a trick one learns when suffering through an Ada class in college instead of electromagnic-theory. :)

As far as the tools comment and Intel...folks in the real world have no idea :) To get a software design/modeling tool in Intel requires an act of congress. (In the Window's world) if you can't get by with Visual Studio, power-point, and maybe Visio, you'll quickly find yourself on the validation side of product development :). And don't get me started on the home grown tools :).

Asaf Shelly's picture

See more comments here:
http://www.reddit.com/r/programming/comments/7b09p/flaws_of_object_oriented_modeling

Asaf Shelly's picture

See a discussion about this also here:
http://www.reddit.com/r/programming/comments/7b09p/flaws_of_object_oriented_modeling/

anonymous's picture

Tad: have you used Lisp, Smalltalk or Self? They included many (all?) of the editing features you mentioned... decades ago.

anonymous's picture

Damn! I lost the tabs in that post.....

anonymous's picture

I agree with this to a point. Sometimes flow control is very important, sometimes it is not.

I write videogames. Often we have many objects that move about in a physics modeled world. These are best handled as objects.

But you also have ui control with dialog boxes, pause the game states, switching from level to level, showing reward moments in sequence: these things can be difficult to time right if done as objects.

Thus I like to have a scripting language that can sleep and wait for things to happen to manage the overall game logic.. where the top level of this script code looks like this (and you can extrapolate this down a few levels into the subfunctions)

do
answer = MainMenu()
if answer == newGame then
PlayGame(nil)
elseif answer = loadSave then
game = AskWhichSave()
if(game != nil) then
PlayGame(game)
end
elseif answer == quit then
break;
end

while (true)

anonymous's picture

* Ralf transfers 10 Hail Richards to Tad *

I felt a litle bit trollish and knew some people would get a litle bit upset if I mention Notepad together with vim and Emacs. ;-)

Well I have used all 3 of them. Ok, ok Emacs is slightly more powerfule than Notepad...

Anyway, its always funny to watch some hardcore linux/unix coworkers navigating in the source with their stone age tools.

It's not about point and click. Its about automatically showing the source of a function underneath the cursor in another window (Source Insight). It's about automatically showing all places where the function under the cursor is referenced - in another window (Source Insight). It's about an integrated debugger (Visual Studio). It's about refractoring...

Well I think the current IDEs are not the end of the story. I predict a time where source code is no longer stored in text files. Instead all functions / classes / etc are stored in a database as an AST. There will be the possibility to show and edit the source in your prefered style. For example: curly braces, python indent, pascal begin -end, etc.
There will be an integrated revision control system in the database. You will "assemble" your "source views" on the fly to have all functions for a use case or and execution flow in one editor window. There will be the possibility to expand a function call under the cursor: The IDE will show the source code of the function inlined in the editor with a different background color. Imagine starting from the main function and then "open/expand" the relevant functions in the same editor window. You can edit these expanded functions. Debugging will be similar. There is no need to jump between different source file if the debugger can display the functions you step into in one source window and automatically close them if you step out of the function. There are much more possibilities if you get rid of flat text files.

But we are no there, yet. Meanwhile I try to use the best what I can get.

anonymous's picture

Ralf, I take issue with your Emacs/Vim hating, if only for the fact that you lump them in with Notepad, the god-awful demon-child of Redmond. Obviously, you've never taken the time to master (and customize!) either one; otherwise, you'd realize that point-and-click IDEs don't stand a chance compared to an interactive, self-documenting and self-extensible runtime.

And calling Emacs an 'editor'? There's a reason people choose to check their email, browse the web, step through their source code, and launch nuclear missile strikes without leaving the safety of Emacs, and that's because it's an operating system, not an editor.

You owe me 10 Hail Richards for your blasphemy.

anonymous's picture

You can (and probably should) use unit tests to isolate and test execution in a single class.

Crap user error messages are not the tell tale sign of objected oriented software they're the tell tale sign of crap software

anonymous's picture

This is one of the most stupid blogs I have read so far.

What is you solution? Functional programming - for example - will not solve the "problem" of non linear execution flow!
Remove all function calls and inline everything in on big function? - In a program consisting of more than one million lines?

One of the best possible solutions to mannage complexity is to divide it: Build components and modules.

What do you think how a car is engineered? A plane? A spaceship? Your computer?

Clay Breshears (Intel):
Whats wrong with using IDEs? If you think using notepad is the right tool to programm - Do you think paint is the right tool for professional design?

IMO programming productivity will increase with even more sophisticated IDEs and source code management tools like it is increasing with more powerful languages. At one point using notepad/vim/emacs for programming will be like carving stones instead of using a word processor.

I don't understand people who insist on using editors, because they think thats l33d - instead of looking for the most powerful tools which help them to achive a goal.

Do you really work at intel?

Pages

Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.