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.
CRUD
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
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:
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 replies on “Programming Like It’s 1995”
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.
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.
[…] This post was mentioned on Twitter by Web Startup Group and kicauan, Hacker News. Hacker News said: Are we still doing OOP?: http://bit.ly/9myixZ Comments: http://bit.ly/cDJ2Sm […]
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.
I think we’ve forgotten about modular programming which is what we are really doing 90% of the time but everyone calls it OOP.
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.
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!
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
cowardlydragon: That’s a very interesting idea.
> 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
http://piumarta.com/pov/points-of-view.pdf
> Neither markup nor JS have particularly strong OO characteristics
“JavaScript: the good parts” Douglas Crockford
Chapter 3 Objects
Chapter 5 Inheritance
> 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.”
http://www.waterstechnology.com/waters/news/1610885/-free-pc-power
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.
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.
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.
> Neither markup nor JS have particularly strong OO characteristics…
True of markup, but not true of JavaScript.
“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.
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.
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 http://www.inqwell.com/faq.html
And you might like this slightly cheeky article called “The Curse of the Super-spreadsheet”:-
http://www.xylinq.com/04_article_01.htm
Javascript doesn’t have classes. Its a prototype OO language, you don’t use classes. Classes is not the only way todo OO.
@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
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!
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?
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.
@cowardlydragon
So this mixins that you called could they be done using delegates for example in c#??
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..
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, 2010 by Jared Just as Steve Knight, I don’t find much use for object oriented programming in my own code. But there is a name […]
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.
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: http://video.yahoo.com/watch/111593/1710507).
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;)
> 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!
Steve, really excellent article. Some extra info:
At least one OO spreadsheet does exists framework.com. 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.
@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?
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.
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.
[…] Like It’s 1995 http://www.hackinghat.com/index.php/programming/programming-like-its-1995 Comments […]
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.
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!
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: http://martinfowler.com/bliki/AnemicDomainModel.html.
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.
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.
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. http://www.oodesign.com/
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.
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 !!!
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 ?
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,
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.
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.
I recommend Bob Martin’s book “Agile Software Development” for a good, solid tutorial on true OOP thinking.
Yeah! And don’t even get me started on the design patterns! Well said.
You made me feel that perhaps not all things are objects, unlike the OOP gurus teach.
I’ve been a developer back from 1989 and started at 16yo doing ‘serious’ programming, on my circle back then the people liked to create monolithic programs dividing functionality using GOTOs. Later on, people started to use subroutines/functions. At the beginning of this century I met OOP, I read some books about it and I also discovered the beauty of Design Patterns for OOP. Lot of enthusiastic people used it around me, it was the best technique, everyone was excited about creating a system using object modeling that could reflect the real life.
As I started to see the mess with inheritance, overloading, polymorphism, information hiddig, yada, yada, yada something told me that were moving far away from the KISS principle. Our brand new and shiny application was released, the code was ‘elegant’ following the best OOP design patterns and best practices. Couple of years later we had to enhance that application, we ourselves fell in a hole where the application design was so restricted by the OOP design patterns that it was costly to enhance that application as well as others that we created.
We hired new people, most new developers don’t quite understand real OOP so they can create a mess that is difficult to fix over the time.
Don’t get me wrong, I like OOP, but not to be applied in any sort of application, OOP is better for frameworks, but when it is time to create the final abstraction of the object is better to just create classes with simple methods, that is better to understand for the average programmer, it is easier to create and maintain.
In the other hand, using classes and methods without inheritance at all seems to me like we creating scripts with functions, that is how most of the people use objects, that is why I call real OOP when design patters are involved using abstraction, polymorphism, overloading, information hidding, etc, etc.
Excellent article. I think it reflects the sentiment of many developers, but it’s generally been taboo to question the OO religion. OO has its place as the author points out, but in most apps designed for end users (as opposed to frameworks or libraries designed for developers), OO has been a MASSIVE failure. OO systems often “work”, but they are failures because they cost a lot of money and time to write, they rarely meet the promise of code reuse, they are hard to maintain (perhaps OO’s biggest failure), they are usually difficult to extend (despite planning to the contrary), and they usually don’t work well modelling things in the real world. At some point, OO systems collapse under their own weight (this usually happens after developers start shortcutting the OO paradigm for performance reasons, etc.). All in all, I think it’s very important that developers speak honestly about where OO has failed. “Religion” has no place in our industry.
Steve Knight: ‘I agree inheritance is totally over’.
This statement is laughable. It shows how much most folks understand about O-O. First: inheritance was always meant to be used sparingly, not all over the place. Second, over the years I’ve worked on some major designs for some major software houses, and inheritance is most definitely NOT over. It is easy to look at what YOU do and think the world conforms. Please wake up from that dream.
The big issue with OO, and with Structured Programming before it, is that most folks are either in too much of a hurry or too lazy to spend the time on design. I’ve seen lots of instances of required rework because of this. The number or programmers I interact with is great, the number of true engineers I meet is almost non-existent. THAT is the real issue all design methods face.. they won’t be taken up by those that need them most.. and then excuses are made as to why they weren’t adopted. After 30 years, I’ve given up hope of ever seeing real common sense in most projects. I just do what I can to inject as much sense as possible.
This article explains why financial industry has probably the worst design and artchitectural approaches… it’s typical mindset of majority in there.
OO when understood on college level without real-world problem domain solving experience is definitely dead road.
What a 15mins waste of my life… shame for Code Project.
ngm
Nice work, an enjoyable read – as are the comments. I have been programming since the late 90’s but almost always on small projects. My use of OOP is minimal simply because it doesn’t seem to be worth the added effort. Sometimes I do lament this because all that learning and theory is not being implemented…but such is life! It’s still rewarding to design something that goes beyond client expectations – no matter the approach.
I’ve been using PHP for years without once touching it’s OOP functionality.
I once decided to convert a function into a class and the associated methods. I found it odd that I seemed to have to add more and more code to get the class to work the same way that the simple little method worked. After a bit of what appeared to be excessive coding, I ditched it and went back to the regular function.
That experience may have been due to my lack of experience with classes and OOP. I am currently taking my second Java course at the local community college.
I guess I’ll need to write a few more apps with Java before I can see the real benefit of OOP.
Take care.
This article makes interesting points, which in my experience are correct.
First, if you are Microsoft or Sun designing programming libraries for everyone, object-oriented modeling make sense.
Now, if you are a smaller company, do you want to spend your time making class models, figuring out how to factor your business domain into orthogonal concerns, optimize all that, or you want to solve your problem into the first place.
The author observes that many problems are perfectly solvable by scripts, spreadsheets and standard libraries: no place for OOP.
One area where OOP makes sense, but is not mentioned is designing domain specific languages, or otherwise known as API’s. Using the API (or domain specific language) as building blocks one will build a large system. At this stage one will probably do fine with interfaces and interface implementation (no hierarchies). So, yes, a lot of the tools of OOP are probably overrated.
Great blog post! I’ve been having similar thoughts for some time. Two points:
1. Modern languages incorporate dictionaries, lists, sets, etc that reduce the need to hand-roll classes. This is for the better.
2. Inheritance was a big part of 90s OOP. In my experience inheritance doesn’t work well in real life as it introduces hard-to-manage dependencies. I see a lot of “simple OOP”, that is OOP without inheritance. I think this is for the better. One can argue if it’s still OOP.
It took ngm 15 minutes to read this article? OOP is great theoretically but difficult to successfully accomplish especially for ever-evolving businesses. Programmers need to be savvy business analyst for efficient & successful OOP projects to get launched. Otherwise, bring out the duct tape and have someone point you to the seams.
you are so wrong dude. ARE YOU EVEN A SOFTWARE DEVELOPER OR WHAT? for enterprise apps these days if you are using .net you are using wcf wpf and …. ENTITY FRAMEWORK. entity framework is a microsoft orm implementation and it’s a collection of class hierarchies. it uses the most modern oop techniques.
of course we have evolved from oop (’95) by using a component paradigm and since a few years now a SOA paradigm. it is true that SOA is better and it does not care about OOP but the logic on the server side is always OOP. that logic is not spreadsheets nor is it structural or whatever.
i still think you’re not a software developer and that youre major has nothing to do with computer science. maybe i’m wrong and if i am it’s sad. good for me that i stopped reading after a few lines and after seeing youre ways of not writing OOP code. it’s a shame i wasted my time.
Great overview of the frustrations I think most people have with OO; except all the “for me” junk. Get some courage dude.
Stephen Thanks for that. No really! I’m pleased (and disappointed) that you noticed the ‘caveats’. They’re in the piece because I speak from experience not from the position of knowing everything. I’ve tried it the other way and people just dismiss what you say (quite loudly) as ill considered. By placing qualifying remarks I can hopefully keep the focus on what I’m trying to say rather than my lack of experience of the industry as a whole.
But you’re absolutely right it’s lame, lame, lame to have to write that way. It sounds weak.
I completely agree with you. The theory I have studied and learned hard has never been the reality in any application I’ve worked.
Steve, It may seem fine not using OO design patterns at first, because the project may seem small and not worth the effort, etc..
In my experience however, these small duct-tape projects tend to grow out of necessity. And usually over time, these projects are asked to perform more and more. The developer is asked to keep adding features. Over time, the project snow balls into a big heaping mess of spaghetti code, making it very difficult to maintain.
Touching one part of the code would break something somewhere else which may not be immediately obvious at first, because of the confusing spaghetti code and accidentally duplicated logic all over the app.
Now if the project would have been engineered with good OO design patterns and best practices in mind from the beginning, evolving that code into something bigger, better, the transition would be much smoother.
Extending a well designed base is much better and cleaner way to do things.
Not to mention the added benefit of having new employees being able to understand the code better.
So for all aspiring software engineers, I have to respectfully disagree to “Program like it’s 1995” even though it sounds like a catchy phrase, I think it is bad advice.
Roberto Thanks for your comment! However, I am talking about large projects. Circa 1 million LoC. The way these projects were designed it’s easy enough to transition through the code it’s relatively straight-forward to follow.
But this is another issue. I have a hard time making sense of code developed using the GoF patterns because they’re often so poorly applied or understood, both by me and others. So actually I find OO ‘design’ of that sense harder to follow. I will be posting on this topic soon.
I can guarantee you that no explicit OO methods were used & design patterns were only liberally applied. Sure there’s objects in there but they’re really just records because there are no actual methods attached.
It all works fine and everyone’s happy with it. Who needs objects?
I’ve done both.
At my previous job, we specialized in providing electronic payment solutions for our clients (think credit cards or electronic checks). We had an object library which mimic’ed our database. While there was quite a bit of CRUD going on, these objects could validate themselves and other useful things. Yes, *mostly* data records, but some added functionality as well. For me, a primary reason for object classes is to separate data layer code from UI code. Having this allows additional re-use of the library and functions, we had many different applications that we could “spin up” quickly simply because we had this underlying object framework.
My newest job? I’m not seeing a lot of OO stuff going on, but it is still well designed .NET code. You can do it both ways.
I’d like to point out that “pre-OO” does NOT equate to “spaghetti code”. Believe it or not, there are many very clean and well-functioning systems that were created without OO. I’d also like to point out that OO systems can also quite easily end up as Spaghetti-OOs.
OO is not for programming, but for maintaining, I think. When someone use OO methods to develop a new application, it’s more difficult than other methods. Because OO theory is not easier to understand than others. I think invariant is the most difficult concept.
And I have programed for 12 years and never do a single program/model more than 2 years. So I don’t care about maintaining and always develop new app again and again.
Are there some to develop a single app for ten years?
An Amazon Senior SDE talking here – good article, nice point, one size does not fit all. Can’t be generalized into bashing OOP (and shouldn’t), but we all mustn’t forget that OOP itself is just an abstraction to deal with complexity. When little complexity exists, it’s often more efficient to skip it.
As for comments like that of @florin – software engineering != using acronyms. Such lists of successive trends boasted as proof of adequacy to the problem domain usually demonstrates an utter lack of understanding of software requirements.
Surely you mean like it is 198x. OO techniques have been around for a lot longer than you suggest. We were using them on Intel RMX in 1984.
It makes me happy to see so much people not using OOP. Ahh, let them fail! In the mean time I rush past them with my nice…err I mean useless … business objects.
I don’t understand what problem most of the posters in the comments have with the author’s viewpoint when he clearly states his reasoning, indicates that he wanted to use OOP very much, and even admits that it may have been subjective.
I personally would take this argument much further. I don’t even think OOP is even a very good way to structure software, and that most of the reason why people give it so much credit is that they haven’t used functional languages like Standard ML / OCaml. Not only that, but many (most?) people have only been exposed to a few C-like languages, and nothing else, outside of maybe one or two scripting languages.
The ML languages have many characteristics suited for very large-scale projects, (very strong static typing, parametric polymorphism, genericism, very expressive type system, dynamic expressivity, encourages safer usages of side-effects, modular, compositional, better ways of dealing with collections via higher-order functions or recursion) without being OOP. A lot of things that people conflate with objects often are available in types, (most mainstream languages have very unexpressive type systems) interfaces, or modules, or some combination of all three, and many times already were available in such systems long before OOP became popular.
A question to ask is, is it that Object Oriented languages allow us to build large systems, or that Object Oriented languages make systems large? I think, honestly, the latter is more true than the former.
There are a number of fairly large and well reputed enterprise level programs written in Erlang, which although it is not statically typed, is only object oriented in the sense of message passing concurrency. (which I personally find to be one of the few interesting aspects related to OOP) I’ve had nothing but good experiences with Erlang, which I found very easy to learn and leverage the benefits in practice. Of course, functional programs in my experience tend to be much shorter, and I believe that shorter programs are almost always better, (at least assuming that they are well written) because there is less code to fix, and requires less manpower to maintain.
I really do think that if more people actually learned or even knew about functional programming languages, (in the rare case where someone does it inevitably seems to be based on a bad experience in a one-semester university course where the student had too much exposure to java) then we would see more really large applciations written in them, and I’d wager based on my own programs written in that style, that they will be shorter and easier to maintain, and easier to maintain invariants (so less buggy).
I’ve programmed for 20 years in both OO and functional. OO is such a waste of time, it’s funny. It’s a fad,and a fad that has brainwashed a whole generation of programmers.
I routinely blow young OO programmers out of the water with solid Functional/Proecural programming.
My Functional/Procedural programs are easier to maintain, easier to support, easier to extend. Every single time.
Note that Python is THE most popular language among new programmers — “because it’s so easy to use and so productive” — HAHA. Python is just an old-fashioned NON-object oriented language, more or less identical in syntax to languages from 20 years ago! Now everybody is suddenly a convert.
Oh my god, how funny.
Hey Steve, great post. I’ve been thinking about this recently and mostly I’m a fan of OOP. Interfaces and generics are great for polymorphism. Methods and private sections are great for encapsulation. I agree there are places where OO isn’t the right paradigm, as you mention. I have noticed that the most horrendous code I see tends to be related to inheritance or reflection.
Mostly inheritance for the reasons covered in Effective Java + the multiple inheritance problem. The problems with inheritance of classes (not interfaces) are so bad, so little known, and it’s so overused, that I think we’d be better off without it.
The problem with reflection is that it breaks the excellent refactoring/navigation tooling we have these days. However it’s extremely useful in some circumstances, so it’s probably a good thing on balanace.