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”
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.