Programming Like It’s 1995

Object-oriented programming, where is it now? When I was at college we learnt a little about object methods and techniques and when I left I kept reading about them. I remember in the 90s I was incensed that an employer was NOT using object methods appropriately. I EVEN read books about it. You could say I was an object fan-boy. But even I have to admit that OOP didn’t exactly deliver how I expected it would.

You may say that this is a crazy talk and that OOP was/is hugely succesful. Shark-jumping mumbo jumbo. But I might disagree. In fact, sometimes I think the object-baggage we’ve inherited is perhaps as much a hinderance as it is a help. The wake-up call came a few months ago when I realised that almost every piece of code that I’m in contact with these days makes only limited use of object-techniques.

Before I talk about all the ways that OOP is dead let me be clear in the ways that it is not. Because when I say OOP is mostly-dead, I mean it is mostly dead to me. In some areas OOP has delivered in spades. For example in modern OO programming languages nearly all come complete with large object libraries. This much is true. There’s objects in them-thar binaries for sure. But my code? Not so much.

Here’s all the ways I manage NOT to write truly object-oriented software:

The Task is Too Small

Some systems are just too small to develop a complex object class hierarchy for. It would be a waste of time to do so. I estimate these ‘glue’ applications could take up as much as 5% of the total LOC of a large enterprise system. It doesn’t matter whether these glue applications are written in Java or Python or Bash because really they’re just scripts. Scripts are their own thing. I would argue that the less scripts you have in your system the better you designed it because you’re not just duct-taping over the seams.

The Spreadhseets Rule

I would also estimate that some appreciable percentage of your enterprise is run entirely from spreadsheets. Whether you know about it or not. Be it phone book, accounts, trading system or stock inventory. These little beauties contain little or-no object code and are spread far-and-wide. I’ve ranted about the pervasiveness of spreadsheets before, no need to go over it again. However, as far as I know, no-one has implemented the idea of an OO spreadsheet. For that we can all be thankful.

World Wide Wasteland

Although the web does lend itself beautifully to model-view-controller, on the client side a lot of it is only markup and Javascript. Neither markup nor JS have particularly strong OO characteristics and both are hugely succesful without those OO characteristics. Indeed many WWW apps are really CRUD applications.


The create-update-delete application is everywhere. Be it web-or-desktop. These apps are effectively database front-ends that organise the interactions between user and DB in a more user-centric way. For example in .NET there’s not much need nor desire to map your data into real-objects because the data-binding layer is phenomenally powerful at making data-bound apps quickly. There’s no support to help you map from data to objects to Infragistics. Indeed, nor should there be.

Enterprise Business Objects

JSP And this is the bit that makes me a bit sad inside. This is what OO was really meant for. I used to have arguments with business-analysts about the right object model to use and whether a method should exist in a base-class or a derived-class. But now it doesn’t seem like anyone, including me, really cares. It’s just that somewhere along the line it became a little irrelevant. Don’t get me wrong, I work with objects all the time. But they’re not really objects that were sold to me.

They’re just data-holders or as our fathers used to say: data-records.

No Methods? No Object

The thing is that to me at least, without methods on your objects there’s literally no object. If objects doesn’t respond to messages they’re just data-records transferring data to some other module that can operate on those records. Usually this other module takes the role of a controller. This, to me, sounds very similar to the programming that our fathers used to-do before C++ and Java 1.1. So much so that it’s tempting to break open my book on JSP.

I think there are two fundamental areas where objects failed to deliver.

Finance This

Firstly, whilst OO techniques are very flexible in some business domains they aren’t flexible in exactly the right ways for all business domains. I’m thinking particularly about my own area of expertise, which is financial trading systems.

The objects in trading systems tend to be difficult to compose into a meaningful hierarchy that is both expressive and not too abstract. I think ultimately this failing is because financial instruments are actually themselves models of physical events. This means that it’s straight-forward enough to construct an object-model of financial instruments. However as soon as I start innovating with my financial instruments (i.e. construct new financial models from old ones) the original object models tend to break-down pretty fast.

The Technology Stack Sandwich

The second reason is that there are too many different technologies involved in many enterprise-sized solution stacks to make consistent application of OO methods viable. What does that mean? Well this is perhaps a post in itself but essentially as soon as you are using two or more programming languages that must share objects you’re essentially entering an object-desert.

The End?

Oh no. Very definitely not. Objects are the only way to make sense of a deep-and-wide library. If the domain allows it they are the only way to go.

The surprise is that objects just didn’t deliver in the way that I thought that they might for me. Which is kind-of interesting because it suggests to me that perhaps me, and a lot of people like me, might benefit from forgetting about objects sometimes and just Programming Like It’s 1995.

74 thoughts on “Programming Like It’s 1995”

  1. A great post. I submitted it to Hacker News, hopefully it will generate some interesting comments. Here’s my experience:

    I agree that we’re not using objects as our forefathers thought we would. But that’s a good thing. Many worthwhile inventions end up being used in ways their inventors did not foresee.

    We [1] use objects a lot, we just don’t use inheritance.

    It might of started with unit testing, when we had trouble mocking out base classes. ‘Prefer composition over inheritance’.

    Objects _are_ used a lot in Javascript, specifically in the ‘module pattern’, which is really a singleton. It’s not our forefathers OOP, but we’d struggle without their objects. And I for one use regular objects in my Javascript.

    Model objects in MVC web frameworks can, and often do, have rich methods to work on their data. It’s just that we’re working on Internet time, so I put the behavior in a controller at first for expediency. Once I realize several controllers need the same behavior, I push it down into the model where it belongs.

    I find myself using interfaces a lot. Either explicit ones in Java, or implicit (duck typing) ones in Python and Javascript. I almost never find myself creating a class hierarchy.

    Inheritance is dead. Long live OOP.

    [1] Admittedly, this might be the royal We.

  2. Graham: Yeah, I think my comment about JS ruffled a few feathers! My point was really that if you take the sum total of all JS how much is really OO? I know that you can make JS OO if you really want to it’s just that it doesn’t really push the developers in that direction. Which isn’t a bad thing!

    I agree inheritance is totally over. I’m interested by the placing of method code in the controllers and then pushing it down into the model when it’s needed. That’s not a way that I’ve ever worked but I can definitely see the merit in it.

  3. I agree with Graham in the composition over inheritance preference.

    When it comes to objects, I think that we would use them more often and more appropriately if only we knew all their beautiful patterns by heart and knew when to apply them. Then we can see the beauty in OO encapsulation.

  4. I think we’ve forgotten about modular programming which is what we are really doing 90% of the time but everyone calls it OOP.

  5. A very interesting post, and I would agree with the sentiment of OOP failing to deliver on it’s promises.

    As a slightly older (I’m guessing) and less experienced programmer, I never expected great things of OOP, because, despite it’s claims, I never believed it modelled the real world accurately. At least in the cases I saw it applied.

    I recall a common beginners tutorial example, where you would be asked to imagine an invoice object. How would you print that? You would send a message to it, asking it to print itself. That is in no way a model of a real world invoice.

    A better modelling would be objects which have internal state but no methods (as you describe, the data records of our forefathers) and there should be other objects with methods (processes) which act on the data objects.

    To model the invoice example given above, it requires an invoice object, and a printer object which knows how to print things. Also in the real world, the objects may be change flexibly (think of e-Invoices, against a hand-written receipt – two completely different objects performing the same role) but the process would be identical – total the items, add sales tax, delivery, less discounts, add to financial record of customer and so forth. The objects are irrelevant, largely, the process is inflexible.

    The Java programmers I worked with (from blue-chip companies) had an invariable knack for constructing data-driven objects, and completely missed the ball with regard to processes: we often ended up with beautiful data frameworks that couldn’t ‘do’ anything. Suggesting that there needed to be a process of some kind would destroy the beauty, elegance and efficiency of their object model.

    So large enterprise-y applications would fire up and spend months (OK, I’m exaggerating, let’s say seconds) creating objects, arranging them in perfect hierarchies, separating concerns, and putting business logic in the correct stratum – but they didn’t perform any business process efficiently.

    I’ve looked for initiatives in Process-Orientated Programming, but don’t see any satisfactorily popular ones.

    I know nothing of the nearly-forgotten LISP, for example, other than it’s emphasis (it’s right there in it’s name!) on processes. We need a new language, with a concentration on process, and as a capability rather than a fundamental, object capabilities.

    To some extent, application servers are trying to address this with filters and Java jumped in with Aspects (where a program organisation clusters around use, rather than hierarchy), but if processes were built in as the fundamental core, they would have the emphasis the real world needs them to have.

  6. Fred: Great comment, thanks! I think you’ve highlighted something that I hadn’t thought about for a very long time. Functional decomposition works because if you do it right it can’t really fail. With OO things are never as clear. It doesn’t make OO bad, it’s just that (as you say) sometimes it’s not the most appropriate. This is the point I think that I was trying to make in the article. So thanks for clearing it up for me!

  7. the problem OOP fails to recognize is that inheritance is a tree/hierarchy and the complexity of objects from a code inheritance standpoint inevitably becomes broken, when two leafs need the same code but it can’t be placed in a lower-level class.

    It becomes a graph.

    What is needed is a flexible system of importable methods or method sets. Amalgamations of those importable methods and methods sets become the formal interfaces of the classes.

    These are called mixins I believe.

    tl;dr – inheritance is too clunky we need mixins for object composition

  8. > as far as I know, no-one has implemented the idea of an OO spreadsheet

    “At the time, the software system developed by the CIA with XSIS was a breakthrough whose features now exist in modern spreadsheets. A spreadsheet cell could be any object. A cell was not constrained to just hold numbers or text; it could hold anything represented by an active object. The object could be dynamically monitoring new data. The rows-and-columns of the spreadsheet’s graphical layout provided a way to view a collection of objects. This graphical view was itself an object looking at a collection, that is, a spreadsheet was a kind of collection object. A single cell of one spreadsheet could embed another spreadsheet or any aspect of another spreadsheet, thus creating a nested collection of collections with no limit. A CIA analyst could use the spreadsheet tools to literally drill down from a cell into the supporting objects much the way a Smalltalk programmer used inspectors and debuggers to explore the dynamics of a running system.” p23

    Points of View — a tribute to Alan Kay, 2010

  9. > Neither markup nor JS have particularly strong OO characteristics

    “JavaScript: the good parts” Douglas Crockford
    Chapter 3 Objects
    Chapter 5 Inheritance

  10. > However as soon as I start innovating with my financial instruments (i.e. construct new financial models from old ones) the original object models tend to break-down pretty fast.

    Others seem to have succeeded –

    The story begins in the early 1990s, when JPMorgan first developed Kapital using the object-oriented language Smalltalk and a compatible database from GemStone Systems. “While the basics can be picked up in a couple of weeks, the system is rich and multifunctional,” says Verdier. “And users really like its flexibility. The ease with which we can reuse components to model complex instruments ensures a rapid time to market.”

  11. Isaac: Thanks for the links! I’ve never worked at JP but I know some people that do. At the moment they’re working very hard on a Python based enterprise pricing system. The project is absolutely huge. I’m going to be very interested to see how it works out for them.

  12. If the old world was full of spaghetti code; the object oriented world through glue in WITH the spaghetti. Binding, strong coupling on all of it’s ugliness. Deep hierarchies are usually to blame; but really inheritance itself (outside of interface) is simply a recipe for disaster. Only shallow hierarchies could ever work outside of small systems with needs that rarely change on an architectural front.

  13. Steve Riley: Yes, that’s an excellent point. Of the hierarchies that I do see the shallow ones are the only ones that really seem to work.

  14. > Neither markup nor JS have particularly strong OO characteristics…

    True of markup, but not true of JavaScript.

  15. “Neither markup nor JS have particularly strong OO characteristics ”

    Whenever someone says that, I want to punch them in the liver. It shows you have zero understanding of OO beyond that weekend Java seminar that you spent a half of at the buffet.

    JS is a full object-oriented, prototype based language.

    Don’t blog about shit you’re clueless about, asshole.

  16. Thomas: Yes, I agree with you JS has OO capabilities and (as someone else pointed out) absolutely everything in JS is an object. I think the thing about JS is that, unless something changed, it doesn’t necessarily steer you down an OO path. But the point I was trying to make is that if I took all the lines of JS in the world I wouldn’t be surprised to find that there aren’t that many classes defined and objects instantiated from those class definitions.

  17. Great article, Steve. Your thoughts and experiences mirror mine. I was also an OO-fan-boy writing financial trading systems but trawling through other people classes and often trying to understand my old code makes me question my sanity.

    No pun intended but OO class models are too subjective. For example, OO models depend on:
    – the designer’s experience
    – the designer’s ability to understand the problem
    – the end-user’s ability to communicate the entire problem.

    If any of the above changes then the OO model has to be looked again and some hard decisions made.

    This can be difficult when faced with financial traders screaming ‘JFDI!’ at you to get the trading system fixed.

    AFAIK, OO is related/similar to Classification Theory. Works of Plato and Aristotle to create taxonomies. Philosophers have moved on from Classification Theory – it’s just not good enough. They have moved onto new areas like Categorization Theory.

    The Computing equivalent of this is stuff like Object-Based Prototype Languages eg Self.

    I quite like the concept of duck-typing where any object can be used if it meets the caller’s requirements. Arguably, a modern day use of this could be the way an Activity is chosen to handle an Intent in Google’s Android system.

    I got so fed up with OO that I helped design Inq, a new language which we used very successfully to write trading systems which have the notion of “Constant Change” as a priority requirement – see

    And you might like this slightly cheeky article called “The Curse of the Super-spreadsheet”:-

  18. Javascript doesn’t have classes. Its a prototype OO language, you don’t use classes. Classes is not the only way todo OO.

  19. @Steve Knight > Thanks for the links!

    Your welcome, now please explain whether you still think:

    – no one has implemented an OO spreadsheet, given Excel OLE

    – classes should be defined in a prototype based OO language like JavaScript

    – your failure to design flexible OO models for financial instruments tells us anything about OO, given the obvious success of others

  20. Isaac: Yes I do still think all those things and here’s why. Even though we have OO spreadsheets and that you can if you wish develop classes in JS it seems to me that that’s not what the majority of people are doing.

    Regarding my failure to design OO systems perhaps you are right. I feel privileged to have worked with the some extremely smart people in my career and it doesn’t seem like any of them has fared much better at OO than I have. YMMV, since I only have my own experiences to draw upon!

  21. Steve,

    Wow, say something interesting and the assholes really turn out in droves.

    It’s funny, I was thinking about this recently. I just spent a few years obsessing over functional programming (Fred: check out Haskell, you’ll think it’s the cat’s pyjamas) and was recently noticing that my OO design skills had gone to hell. Fortunately I work with someone who has been obsessing over OOP for the last ten years. I’m not living in the promised land, but it couldn’t be much more OOP-y. So it occurs to me to try and improve my OO design skills, but the ship seems to have mostly sailed, or at least, I’m unaware of any new books that are as vital as Design Patterns.

    It seems to be almost impossible to discuss OOP without getting into a semantic debate about what constitutes the fundamental necessities of it. The only thing everyone seems to agree on is that the methods are carried around with the data and different data can define methods with the same names.

    I also think it’s important to differentiate between OOP languages and their libraries. jQuery is a great example. Not really all that object oriented, but it turns out to be perfectly appropriate to actually getting things done on the web, unlike Prototype + Scriptaculous, which really are much better examples of OO design. On a web page, integrating with CSS and the DOM is more useful than being OOP. And what’s CSS? Declarative?

    At any rate, I think the heart of the conundrum (at least, for me) is wondering how it is that all these systems (OOP, FP, relational) can have such different models of reality yet ultimately be doing the same thing on the same machine. How is it that these machines which only know a handful of essentially arithmetic operations be so capable of enslaving us to our philosophies, and yet, how can those philosophies be so unrewarding in the harsh light of day?

  22. Daniel: Ha! Everyone’s entitled to an opinion I suppose.

    You make a very important point which is that the ultimately it’s just shuffling bits in registers and memory. From the early days of machine language we’ve wandered down a few different paths and it seems to me that the OO one has opened out into an enormous field. Where we go from here isn’t entirely obvious.

  23. I think that the reason that OO models dont get used is because programmers fool themselves into thinking that they can predict the future.

    IE that the flexibilites that they have built into their OO models will be the flexibilities that will be required in future.

    Programmers, like everyone else, are not good at predicting the future. The business requirements that arrive, are very rarely those that are foreseen, and all that time spent on the model goes in the bin..

  24. MarkE: Yes that’s definitely true. Anticipation of change is a large part of succesful modelling of any software. The thing that’s interesting about design in the OO context is that designing for change has quite a big effect on the results. Resulting in abstract classes, way too many interfaces and general pain. I think this is an important topic that I want to explore later.

  25. FWIW I think there were two underlying problems with the mid 90s version of OO that got won popular adoption. One, as with any new trend, folk took it as a silver bullet that would solve all problems. Remember the late 90s when CORBA or XML were going to save the world ? And two, the version of OO that got mainstream acceptance encouraged too tight binding between data and behaviour. The orthodox C++/C#/Java programming style (best expressed by the GoF patterns book) used inheritance heavily. Inheritance of data and methods from base classes combined with static type checking causes tight coupling that makes reuse and assembly from components very difficult. Brad Cox was far sighted enough to see this back in 1990: check out Planning the Software Industrial Revolution. The rise of dynamic languages in recent years, especially Python & Ruby, is a reaction to the failure of the orthodox C++/C#/Java style.

  26. oop has never been the solution to all problems and never will.

    It’s horses for courses.

    You’ve got to think about what you’re building, how big it’s going to get and how much time you have. And for different applications different methods are needed. Whether oop, functional or even procedural. Let alone assembly.

    The only thing you’re decrying is that oop isn’t what you thought it was. That it wasn’t what the hype made it out to be.

    Also oop lends itself very well to web development, including in javascript (you just have to know how:

    As for the asp implementation of crud, it may be quick but it soon becomes completely unmanageable with greater and greater page numbers. There are far, far, far better ways. Like oop;)

  27. > The only thing you’re decrying is that oop isn’t what you thought it was.

    That’s definitely true. Whilst I accept that my opinion might not be the same as everyone else’s, I have read quite a lot of OO literature over the years. And I think that there was definitely a core part of OO that really never took off in the way I thought it would. There has to be a reason for that and for all sorts of reasons OO just isn’t the answer in a lot of circumstances. Although our programming languages encourage us to program that way.

    But I stand by my examples and I still don’t how to data-bind proper objects to a commercial grid like Infragistics in a way that isn’t onerous for the developer to maintain and doesn’t really suck!

  28. Steve, really excellent article. Some extra info:

    At least one OO spreadsheet does exists The call the units of computation frames not cells, but what’s in a name. Also an entry on Wikipedia.

    I think that OOP is one member of a continuum of three:

    1. Objects with attributes and no methods = data records.

    2. Objects with attributes and methods = OOP as we know it.

    3. Objects with no attributes and method(s) = functions / processes.

    #3 on the list is often implemented using shell or other scripting languages. For it to be truly effective it should not check for object type/class but simply send it messages and catch any “does not understand” exceptions.

    It takes discipline and coding standards to keep the above three implementation meta-patterns distinct.

  29. @Steve Knight > Yes I do still think all those things and here’s why.

    I wonder how many times we can refute your “facts” without any effect on your opinion 🙂

    @Steve Knight > Even though we have OO spreadsheets and that you can if you wish develop classes in JS it seems to me that that’s not what the majority of people are doing.

    You haven’t shown us any reason at all to think that you have a special insight into what “the majority of people” (or even the majority of people working in finance) (or even the majority of people in your workplace) are doing with spreadsheets or JavaScript.

    When they embed a chart in a spreadsheet cell, what are they doing?

    What’s with “classes in JS”?

    “JavaScript is a prototypal inheritance language. That means that objects can inherit properties directly from other objects. The language is class-free.”
    p29 JavaScript: the good parts

    @Steve Knight > some extremely smart people … it doesn’t seem like any of them has fared much better at OO

    Does that suggest the Kapital team were extremely extremely smart or were they just extremely smart and the people you’ve worked with should be downgraded to smart? 🙂

    @Steve Knight > I only have my own experiences to draw upon

    You can’t learn from other peoples’ experiences?

  30. Isaac: I guess you read a different article from the one I wrote! For that I apologise since that’s most definitely my fault for not making it clear enough. I know that no-one can win this argument because I’ve seen a lot of them on the web over the years but since it’s my blog (and I moderate it) I’m going to give it a shot 🙂

    @Isaac >> You haven’t shown us any reason at all to think that you have a special insight into what “the majority of people” (or even the majority of people working in finance) (or even the majority of people in your workplace) are doing with spreadsheets or JavaScript.

    I think you’re missing the point. This post isn’t really about JavaScript or spreadsheets, at least not directly. It’s about OOP and how there’s not an awful lot of OOP in spreadsheets and JS. Not least in the bits that I’ve seen.

    @Isaac >> When they embed a chart in a spreadsheet cell, what are they doing?

    I think you’re missing the point. They’re just embedding a chart in a worksheet? This, as far as I’m aware, is not programming.

    @Isaac >> Does that suggest the Kapital team were extremely extremely smart or were they just extremely smart and the people you’ve worked with should be downgraded to smart?

    I think you’re missing the point. I’m not sure if you read the article about Kapital but it tells us almost nothing about OOP. Which is what I’m writing about. Just because JP says their system is OO how do we know that? It might be architected exactly how I described in my article but there would be some people that might call it OOP.

    But let’s be clear. None of this is about how smart I am or how smart other people are it’s about OOP and in my experience why there doesn’t seem to be much of it around.

    @Isaac >> You can’t learn from other peoples’ experiences?

    Sure I can, and I’m going to start right now! Stop telling me how stupid I am (I already know just how stupid I am!) and tell me about your experience and how it differs from mine. Tell me how you created magnificent OO hierarchies that model precisely real-world events, are extensible and will live forever. That’s what I really care about.

  31. Most code written recently lies between a RDMS and a web application. Relational databases are not object-oriented — that limits the amount of object-orientation opportunities you can do on the back end business objects.

    On the front end, HTML is not object-oriented, so you cannot use much object-orientation in your front-end JSPs. The same is true when building pages in most other tag-oriented web technologies.

    However, there are a few web technologies which allow a web developer to make massive use of object orientation, e.g. Wicket, Echo2, and GWT. They’re not popular because most people who do web development learned using tools that did not make it productive to create and instantiate abstract web components, and therefore they really don’t have the object orientation skills to benefit from using these tools.

  32. Interesting. I’ve been using modular but not object oriented programming in my own work. I write device drivers for high speed data transfer (video streaming, cell phone base stations) and safety-critical systems (medical equipment, air traffic control software).

    It seems to me that OOP just gets in the way of the work I do, although it might be more useful for databases, GUIs and web sites. In the case of the high speed work, it slows things down. In the case of the safety-critical work, it makes things more complicated than they need to be, and thus less reliable.

  33. Mike: Interesting comment, thanks. I attended some ACCU conference a while back (2000?) where some of the speakers were trying to encourage embedded systems/device-driver writers to switch from C to C++. Which was essentialy a call to those developers to adopt OO techniques.

    I thought then, as I do now, why on earth would anyone sacrifice the predictability gained from modular techniques for OO. I’m glad to see that common sense prevailed!

  34. Above, IMHO, fsilber seems to get the closest to the most proximate cause. There’s darn little object orientation (OO) in a back-end RDBMS and darn little in the front-end HTML/JS/browser. So, sure, in such common contexts, object oriented programming languages/methods are (still) rather inapplicable. They just don’t need to come up much – esp. not for simple web/CRUD apps.

    But as Bharat Bedia mentions above, we surely *do* want tools that recursively abstract away successive layers of complexity. Today, we all make do with what we have – but that doesn’t mean we don’t want/need more. The subtitle of Eric Evans book on Domain Driven Design goes to what we’re really discussing in this post/thread:

    “Tackling the complexity in the heart of software”

    I’d suggest that the software industry needs/wants an arsenal of abstraction mechanisms. This starts with, and in, our programming languages. Granted, giguring out how to best support classification, categorization and/or generalization/specialization (in a programming language) hasn’t been quick – nor easy – nor even all that fruitful to date. Still, the need for abstraction remains. Making various abstraction mechanisms/tools more practical is just as important as it ever was.

    Ultimately, I figure that this post/thread touches on the underlying symbolic systems nature of software. Answers in this realm tend to demand a balance of reasoning (logic/code) and representation (state/data). The best answers might mix reasoning and representation in innovative ways. Long story …

    In the comments above, Daniel Lyons emphasizes out how dreadfully limited our ‘computer’ building blocks are. So, as you say (above), if we’re trying to build up a symbolic system from ‘computer (hardware)’ primitives, then:

    “ultimately it’s just shuffling bits in registers and memory”

    If we start with basic “arithmetic operations”, and some bit twiddling/stores/fetches, then, this leaves a lot of work for the ‘software’ (layers). To start with, software programming languages have to raise this inanely primitive level of abstraction – by *several* orders of magnitude.

    In this light, please reconsider Daniel Lyon’s insightful question (in the comments above):

    “How is it that these machines which only know a handful of essentially arithmetic operations [can] be so capable of enslaving us to our philosophies, and yet, how can those philosophies be so unrewarding in the harsh light of day?”

    On the first part, how not? Cognitive psychologists widely believe that language is intimately and inextricable bound up with both human ‘thinking’ and with human memory. Long story …

    As I see it, inheritance/polymorphism/OOP/etc. isn’t dead as much as it doesn’t apply well to very many existing software implementation contexts. That goes to the second part of Daniel Lyon’s question (above).

    Few software implementation contexts are (yet) up to supporting these OO sorts of (generalization/specialization-oriented) abstraction mechanisms. Today’s most common software tooling is most naturally matched to either a flat data (only/mostly) model (e.g. RDBMS) or a hierarchical data (only/mostly) model (e.g. XML, XHMTL, JSON).

    As a consequence, today’s software world is rife with anemic data models – processed by non-OO (often MVC organized) software logic/code.

    Naturally, and as fsilber points out above, folks strive to do better (with wicket, echo2, GWT, etc.). Yet as Graham King points out, pragmatists must work with what they have. Pragmatists get the job done. For web/CRUD applications, that can mean MVC-organized software. That can mean procedural logic/code going into the controller first. Then, maybe, some of that logic/code might be pushed down (or refeactored) into the model. Even then, this happens only if the the model is ‘rich’ enough to support classes (and their associated methods).

    This recurring tragedy has spurred folks like Martin Fowler to decry this all-to-prevalent, sad state of affairs:

    Speaking of 1995, when will we see OODBMS’s of the sort that might supplant/exceed RDBMS’s? It seems sure to take awhile for browsers/JS-frameworks to get more OO as well. Adobe’s AMF/BlazeDS might be an early step in this general (OO) direction – but there’s a lot more to be don – on so many fronts – by so many folks.

    Until a lot of new, better/faster/cheaper, OO-empowered software tech comes together, we’ll probably all need to just embrace what we have. If your RDBMS/XHMTL/XML doesn’t have any support for inheritance, yet, then one must make do with composition.

    All the same, someday, I would hope to raise your pointer-to-implementation (PIMPL) with a graph of objects (as nodes). Change is the only constant.

  35. This is really the pendulum of insights. Why was OOP invented? Yes, to deal with the drawbacks of the procedural approach. Why go back, yes, to deal with the drawbacks of OOP. The problem with models is that they never match the real world completely, they’re always cheating a bit (even true for photo models!!). So we should never be dogmatic about them. Having been in this profession for over 25 years, I’ve seen many ‘final solutions’ for programming and none of them turned out to be holy scripture at all. Yet I don’t agree with all that’s said in this column.

    The argument that some tasks are too simple might be true, but it’s tricky. Systems are always expanded and the next version is always more complex. Be happy with it, because that’s how we earn our daily bread.

    I wouldn’t bring up spreadsheets as an argument against OOP, but rather use OOP as an argument against spreadsheets. Spreadsheets emerge where enterprise systems fail. They are used to fill the gaps. They are either useless or complex. Many times a lot of macros are needed, because the simple grid model has but limited use. Usually those spreadsheets are made spontaneously by employees, not IT professionals and if the creator is gone, the spreadsheet can’t be maintained anymore and gets useless. I would suggest to limit their use to strict personal tasks.

    I don’t buy the ‘No Methods, no object’ argument either. Who said there should be no data records in an object model? A data record is nothing but a data type, like an integer, or a string, only a record is composed of multiple fields. Without OOP, if we do it right, we would use Abstract Data Types, which means we create functions to operate on such a structure, that define all the operations and state transitions on the data structure. This already get close to OOP. The idea of OOP came up before client/server, or multi tier systems became fashionable. Therefore OOP assumed an object to be complete and self contained. It should hold the data as well as define all operations on the data. In a C/S/M/T system, this can’t work, because the different roles the various tiers have related to the data. So in an OOP model, each tier would need its own set of objects to deal with the data. AFAIK, OOP works great to define ‘engines’ rather that ‘data definers’. They facilitate making a consistent set of methods to operate on data.

    The only real novelty of OOP, compared to abstract data types is inheritance. And that is therefore also its greatest strength. If I reflect on the software I create myself, it is mostly using inheritance to put common functionality in super classes and refine tasks in subclasses. Of course, if a class hierarchy grows too deep, one should start asking questions about its efficiency.

    Having said all this, I like it when people question generally accepted techniques, because it makes us rethink the issue and it keeps us all sharp.

    So thanks, Steven.

  36. the post reminds me one of my ex-bosses. He was an ensusiastic fan of OO, could talk hours on the right design. Than one day I’ve peered into his code. It was one single class with one single method several thousands of line. Full with deeply nested loops and repeating code all over. Brrrr, he was not even using functional programming. Well well, OO is not always the right answer, but not using it for complex problems is also a shame. Read the design patterns, that propose solutions for often recurring problems very useful.

  37. Interesting, because I tend to think again
    that objects delivered in a much more surprising way that I thought that they might, especially in large projects. There are many ways to solve the same kind of problem and OOP has done a surprisingly good job to approach large scale design problems in its own OOPSIE way.

  38. Every document processing application’s menu that I have ever seen has a “Save” option and when I exit said application it will ask me if I want to “Save” it …. which is completely preposterous … of course I want to save it. If we lived in an OO world it should be possible to set an option when we install an OS to turn off this ridiculous behaviour …. dream onnnnnnnnnnn !!!

  39. There are really very few situations where OO makes more sense than not, IMO.

    First off, nearly every single PHP program ever, should not be OO. That’s a whole lot of BS PHP out there. When your programs only ever run for less than a tenth of a second at a time, there’s no freakin point to it.

    Agree with OP re: methods. If you haven’t overridden something’s methods at least once, then why are you even bothering to make your program OO ?

  40. Good concise article, particularly truthful about the enterprise business objects. We spent months on a perfect object model but as soon as we put it into a “business tier” it lost persistence and we had to re-create our objects on every call, which was very frustrating – passing in all those properties on every call to every method. It caused us double the work,

  41. Interesting article, but for the most part, I disagree. It is true that OO doesn’t exist in its cleanest form in many script-like apps. But just because Java, .Net, whatever, is the language of choice for scripting, that only speaks to the success of the language, not to the death of OO.

    I would argue that most apps that actually have an app lifecycle and QA process and are developed in an OO language use OO quite appropriately. The best example is the rising popularity of strict MVC in web apps. Another good example is basically any app in Android. You can get away with crappy OO in iPhone, but Android lends itself to MVC almost as naturally as the web.

    On the desktop side, Microsoft is pushing WPF and Silverlight hard.

    As for JS, I would largely agree with you…before JQuery. Once JQuery arrived on the scene, I’ve really started seeing a lot better JS from everybody. Sure, there’s plenty of non-branching, non-object code out there, but JQuery has opened the doors of JS to many people who previously disliked it (myself included) and large JS code segments are a result. The more code, the more potential for reusability, and the more potential for good OO code.

    Really, all this article shows is that you (and possibly everybody at your company) is rushed and/or sloppy, or the tasks are so small, a script was all that was needed.

    But, you know, way to go to get visits to your site! Say something extreme and CodeProject publishes a link and poof, instant increase in hits.

  42. ParrotLover77 You’re exactly right when you say that perhaps everyone at my company is rushed and/or sloppy. But more than anywhere I’ve ever worked we deliver in spades.

    I’d love to hear how it works in your place and what OO techniques you’re using when you have the time. Thanks for the comment – Steve.

Leave a Reply

Your email address will not be published. Required fields are marked *