Is OOP over rated ?

Ok, just posing this question alone will prevent many readers from going further. Yet, I do believe it is a valid question ? Why ?

OOP is a theory, not a fact !

Object oriented programming is a concept, a theory, about how programming can be improved. From the early days of OOP, object oriented programming was basically promoted as a way to build software faster and better. It supposedly would increase code reusability, code readability and in so doing improve programming. But has it ?

OOP or Procedural ?

As far as I can tell, there has been little research which proves OOP is better than procedural coding. Oh sure, college professors will tell students that OOP is superior, but that does not prove anything. How many college professors are actually writing real world software while being under a time constraint, like a programmer who does it for living ? In the real world, software projects are started and then at times fail, because of being over budget, poorly designed or just plain buggy.

What is software really ?

Software simple solves a problem or handles a task. For example if all you needed from a program was to allow a user to input two numbers and then have the program do a complex calculation, this should only take just a very few lines of code. No complex planning needed here. Just create a form, put two input fields on it and a button with the word “Calculate”. Click the button, read the two text fields, convert them to numbers and calculate and then display a messagebox with the answer. Not so hard was it ?

But, this simple task does not have anything to do with objects. Besides, what is an object anyway ? An objects purpose is to store data per an instance and then allow feedback between the application and that data. In some cases the data is displayed (aka. a control like a listbox), while in other cases the data is simply data related to a task. The idea behind objects is that by building objects which can be reused (or even inherited by a bigger object), that you end up writing less code, because you can reuse objects over and over again. Seems to make sense, doesn’t it.

I recently watched a training video about C++ which discussed objects and the speaker used an example such as an object which is for animals and how both a cat and a human are animals and have things in common, so both can be built upon the basic animal object, so they inherit the base class.

OK, in the real world a cat and a human, while having just a few things in common, are so uniquely different, why would anyone want to even build a software data type (object) so they could save time by somehow merging the two together ? The problem here is that OOP is at times taught using poor examples, which really aren’t of much value any way. Not everything in life is an object. Not everything in a software application needs to be defined as an object.

I find it interesting how in recent years the agile method of software development has been promoted (and it has some merits) so software development can be sped up, yet the question of whether OOP really is all that productive or not may not even discussed.

A different perspective.

You may wonder why any programmer would even suggest that procedural coding can be as good, or even better than object oriented. You have to consider when and how a programmer learned his/her trade. In the early days of computers, many programmers were self taught and not trained in the halls of higher education. In my own case, I did have one actual college course in programming back in the 1970’s, which was fortran, but it was a class where I had to write out programs using punch cards and then have them fed to a main frame computer. Beyond that though, my training has been the product of being self taught. I learned what I needed to learn to solve problems. When I wrote custom software for businesses, I would examine the task and if I lacked something to solve the problem, I simply would do a good bit of reading to find solutions which would work. In the process of developing custom software for a number of years, I learned how to build applications faster by reusing code (building my own libraries and tools) and by learning how to code quickly. I was always looking for ways to speed up development and make it more reliable.

The strange thing about being a self taught programmer though, was that never once did I find myself with a difficult task and the idea of building an Object came to mind. Yes, common tasks could be written as reusable libraries and this especially made a difference in user interface code (ie. menus, scrolling screens, etc.), but the idea of objects never came up. It wasn’t until I moved to Visual Basic, that the concept of objects with properties and methods even came into view. But even there, I could deal with the UI stuff as far as properties and methods, but the rest of the code was written purely using procedural code. Each iteration though of Visual Basic became more object oriented than the previous one. True, Visual Basic, is not considered object oriented by some today compared say to C++, but is was object oriented to a degree and for a procedural programmer it had a lot more OOP than one was used to.

Machine language affects ones viewpoint.

In the old days, a programmer had to use every way possible to speed up their software and machine code was critical. The compiler one chose and how well it generated machine code was vital. Experienced programmers likely would venture into assembler to add speed where it would make a difference. That was my experience. Before the days of the IBM PC, I learned 6502 machine language, even writing my own compiler. When I started writing software for the IBM compatible computers using QuickBasic, I also learned some assembler so I could write some very fast routines. My PDS 7.1 (Microsoft Basic) code was so complex, that I couldn’t even compile it from within the IDE, but I had to build batch files to run the compile process, so I could get the optimized features I required.

Looking back over the years, I honestly feel my learning machine language (and assembler) was extremely valuable. It helped me better appreciate what was really going on with the computer. My BASIC code, which was more like human language, was being compiled into low level machine code, so how I coded using a higher level language, directly effected the machine code the compiler generated. This is why the so called “dreaded” GOTO command and its cousin GOSUB , are actually valuable tools for a programmer, despite all that has been taught about it being obsolete and poor programming style. Do programmers really appreciate how many machine language GOTO’s are being generated by the compiler they use, even if you don’t use a higher level language GOTO command ?

Assembler language lends itself more to procedural style coding, than to something like objects, which can effect the mindset of programmers who use it. Maybe this is why I find assembler and a procedural style language like the BASIC I use quite compatible. Many concepts are similiar between the two.

Agile programming and procedural coding.

As a long time procedural programmer myself, I have found that a procedural coding style actually lends itself to faster software development. It is as Agile as one can get. A procedural coder can just write code quickly to solve a task and do this over and over again and in the process some code stands out and the programmer can see that maybe certain code would make a good library routine, so on the fly, a library is built. Not because it was planned out, but it simply made sense and the code was already there and it works, so a programmer just makes a few changes and now we have a routine which is reusable.

I guess I break all the rules for programming that many learn in college. For example, I don’t usually self document my code. Because I use an easy to read language (Basic), the majority of time the code is quite readable. I also use variable names and subroutine names with meaning, which is self documenting. I don’t create flow charts for the code. I just code and do it quickly. Rather than over plan my code, I simply build routines which handle a task. First make the routines work. Once you have that, one can go back and determine whether it needs to be faster or improved somehow. The idea is to build upon working code. The key is to make it work. Then go back and improve it.

Object oriented programming is not agile in my opinion. It requires too much planning. When OOP goes bad, programmers will likely say it was poorly planned. But if OOP requires so much planning, that only experts can master it, then maybe it isn’t as efficient as one may think.

Now where I find planning is critical is in laying out the data that the application will work with. All the software I wrote for local businesses, had a unique database engine written for each application. I would design a database around the task, rather than design the data around a predefined database engine. If a flat file would work, I would use it. If a Btree would work better I would use it. If a custom database was required for optimal speed I would create one.

You would be surprised at how procedural coding lends itself to writing fast and amazingly small applications or DLL’s. For example there is a BTree engine which I wrote back in the mid 1990’s, specifically to solve a problem I had when writing a database for a custom application. In recent years I ported the code to Powerbasic and the resulting DLL is only 17 KB in size. How many database engines do programmers use today, which are only 17 KB in size ? I offer it as freeware for Powerbasic users ( http://cwsof.com/freeware/freetree.zip ).

In writing software I see data, user interfaces, printed data, calculations, tasks. I rarely ever seeing anything as an object or somehow visualize that objects are the purest form every aspect of my software should attain to. Objects, if I were to use them, would only make sense when something really is well suited to being an object. Even then, many times a data structure of some kind defined as an array, makes more sense that an actual object.

Try it, you might like it.

Because many programmers have been trained to think of everything in terms of objects, they may not even be capable of writing an application using a minimal amount of OOP. Yet if you have an opportunity to experiment and try building an application with as little OOP as possible, you may find it a real learning experience. Maybe try it on a small project or even a personal project at home. Try to build an application using purely procedural style coding methods. Make sure though that you build your own libraries of reusable code (as functions and subroutines). Resist the temptation to turn something into an object or a class. You may just find the experience invigorating. Even if this experiment doesn’t change your mind about OOP, you may find yourself using OOP just a little bit less, when procedural code would do the job quicker with less planning.

The benefits of procedural coding.

I really do believe that procedural style coding produces faster and smaller applications than its OOP counterparts will. I won’t spout theory or even try to provide some kind of benchmarks to prove it to you. All I can say is, that I have been a long time procedural style coder and from pondering the results of my own work over the years, I have little doubt that procedural coding has helped me produce amazing results which run fast and with a tiny footprint. If you are looking for edge, when it comes to developing software for the coming generation of mobile computers (aka. tablets), then seriously consider an alternative to OOP, procedural coding.