OOP is Snake Oil - Yes or No?
See last month's Bytegeist column

Sir,

Your writer claims that "Object Orientation ain't all it's cracked up to be", and that "OOP has failed". I disagree with his analysis. Since he discusses both object orientation in general and OO programming, I assume that he is criticising both. To me, it is OO design which is important; OOP is about using a programming language which directly supports the implementation of an OO design - it should simply make the code more readable and avoid some errors.

Your writer states "There is no silver bullet: Object Oriented Programming has failed". I entirely agree with the first half of the sentence. There is no substitute for analysing the problem to be solved: just hoping that any OO (or other) design will be appropriate for the particular problem is almost certain to lead to failure. But that does not mean that object orientation does not have an extremely valuable part to play.

You treat "object oriented" and "class based" as synonymous. However, this is a big mistake.  Just because a programming language supports OOP doesn't mean that all programs written in that language are inherently object oriented.  A language cannot force the user to use it in the way in which it is intended.  I have seen plenty of code written in OO programming languages which could not remotely be described as object oriented.  Here's an example of a global variable in Java:

public class Globals {   public static int x; }

The fact that it is inside a syntactic structure labelled "class" should not be taken to imply that it actually is a class in the OO sense.  All I have done here is to create a global variable which happens to have a dot in its name (Globals.x).

I should also point out that I have written object oriented code in the C programming language.  Also, the 'FILE' type defined in the C standard library is a good example of an implementation of a class in a non-OO programming language.  ZLib's z_streamp is another example.

You deduce from the existence of failures in the IT industry that OOP doesn't work, and yet do not provide any evidence that either (i) there has been a higher prevalence of failures since OO awareness became mainstream, or (ii) OOP (or OO in general) played any part in the failures.

You present two examples of failures when using classes.  I will deal with the Perl example first.  Your argument is that it is hard to find all subclasses of a given class, and so modifying a base class can have unknown effects elsewhere in the system (correct), and therefore OO is bad (non sequitur).  Consider modifying any function or subroutine which is called from more than one place.  You have exactly the same problem. OO doesn't make things worse here, and may even improve matters. Good OO practice is to have a set of invariants for a class, which are maintained as a result of any access from outside the class.  In the Perl case, it seems that either the invariants weren't specified/documented, or the change which you made broke an invariant which a subclass was relying on.

In the banking example, one phrase cuts right through to the real problem behind the failure of the system. "Or if the truth be known, any analysis at all". The analysis was not done, and the system was doomed to failure.  You cannot create a general-purpose banking class library, and hope that it will be useful for all problems involving banking.  The designers of the system did not establish that reconciliation was an important requirement of the system, and therefore failed to support it.  It is hard to imagine that any other type of design methodology would have succeeded if the analysis had failed to discover this essential requirement of the system.

So in summary, I agree that OO is not a silver bullet. I also agree with your implication that it is often falsely presented as such.  But I cannot agree that object orientation has failed. I have seen and worked on enough projects where effective use of object orientation (in conjunction with good analysis, programming, testing, documentation, project management, etc.) has helped (e.g. in reducing development time by making the system more robust against changing requirements, and even producing classes which are reusable in other projects) to concede that.

Chris Rimmer

Sir,

For many years I have not felt comfortable in the OOP world, but would not dare say so for fear of reprisals, and being outcast in the world of programming. At times I have even found doing things the OOP way to be down right awkward, clumsy and having to go all around the houses to arrive at a conclusion. I find even program design to be awkward in OOP. UML is ok but sometimes it is just easier, and clearer to sketch out the program flow, and add some pseudo-code without spending hours or days designing UML diagrams. I am glad it is not just me who thinks that OOP is not the be all and end all of programming.

It is true that certain things can be modelled well in OOP, like shapes, and transport. It is unfortunate that most of these things happen to be inanimate which means they are not likely to change radically: a circle is a circle and will always be a circle, only its size and perhaps colour will change. The same is true of transport and other tried and tested objects. But just try and model a business which will most likely evolve daily!

The sad truth is that about 98% of software created in an OOP way is not reusable again out of the box. Most things that could be modelled well as an object already have been. They are most likely already included with your compiler as a library. Everything else can be modelled as a class, but will most likely cannot be reused without modification either through inheritance, by creating another copy of the source code and renaming it to something else or by adding more functionality to the existing code.

I wonder how many companies or developers would dare admit how much of their so called 'reusable' OOP code is actually reusable off the shelf, without modification or deriving yet another class to cope with change? And how much is just modified and renamed source code with the addition of new and old hard-to-find bugs, just waiting to jump out and bite them when they least expect it to?

So what is the answer to our software crisis? Is it OOP? As long as companies and developers refuse to admit that it is not working but is, in fact, causing more work, I think, sadly, that OOP will stay.

It is a bit like the story of the King who believed he had an invisible outfit, until one day one person who supposedly didn't know better pointed this out to the king, and then everyone else suddenly realised this person was indeed right.

One day a magic solution to software development will be found, but in the meantime as long as everyone chooses to believe OOP is the way forward, then every programming language past and present will aspire to be OOP like, just to stay in with the 'in crowd' and we are stuck with it.

Name withheld by request

Delphi For Visual Basic Programmers?
See our interview with Borland's David Intersimone

Sir,

Congratulations on your new, online magazine! I hope you know what you're getting into! New magazines are like new romances. At the very beginning, it's allllll gooood! Here's hoping I can write another congratulation on your golden anniversary too!

I think of developers as a community. Especially those of us like Bitwise and About Visual Basic who are mainly concerned with figuring out how to use the technology rather than trying to sell you something. So I posted my congratulations at my own site, 'About Visual Basic', as a service to my own readers to let them know that something worthwhile has popped up. In the spirit of community: Welcome Bitwise.

I was disappointed that Bitwise only had one article about Visual Basic in this first issue - and that one was VB 6 based! Hopefully, Bitwise will do better than this in the future, That one article about programming serial communications is an excellent choice since it will answer one of the most frequent questions I receive at 'About Visual Basic'. The only problem is that I'll have to wait for the next issue of your magazine to read Dermot's explanation of the code he provided in this series introduction and see how he uses the Win32 API calls for serial communications.

Speaking of Win32 and VB 6, the multimedia interview with David Intersimone, Borland Software's Vice President of Developer Relations was also very cool, especially for Issue Number 1! But I wonder if David is throwing rocks at Microsoft that aren't quite deserved. Not that there's anything wrong with throwing rocks at Microsoft. I've thrown a few myself at 'About Visual Basic'. But I do think the rocks should target real problems, not just spread disinformation.

Here's what David says about Microsoft and Visual Basic:

To begin with, it seems to me that it's not quite accurate to say that Win32 is more "native" than the .NET Framework. Both are simply architectures. But .NET is already supporting new features of the Windows environment that Win32 can't touch and that gap will only get bigger.

The most serious problem I have with David's statement is the suggestion that you have to choose VB 6 or VB.NET. If you switch to VB.NET, you can STILL use VB 6 and Win32 COM components - no problem. I run both VB 6 and VB.NET on the same machine and the "managed code" features of .NET ensure that no conflicts ever occur. VB.NET also has a well worked out system to "wrap" Win32 COM components so they can be used in VB.NET. Again, no problem.

The only thing Microsoft hasn't done is integrate the two technologies so you can develop (as David says) "at the same time." If you want to develop in Win32, you really do have to go back to VB 6 and then use the result through a managed code interface. In the Microsoft world at least, Win32 and COM have security and maintenance problems that just can't be fixed unless you do a clean break. I'm informed that Delphi (which I admit I know very little about) has always used an architecture similar to the way .NET now does it that doesn't require registration of DLL's. (There is an old saying, "Good programmers write good code, great programmers steal." The way Microsoft has used some of the best ideas from Java, Delphi, and other architectures in .NET means that they must have some really great programmers.)

Good luck to you and Bitwise. The world can never have too many great computer websites!

Dan Mabbutt
visualbasic.about.com