This is the second part in a series I’m writing about lessons that can be learned from functional programming. Find the first part here.
Object Oriented Programming (OOP) as an idea has been oversold. The most commonly used languages in use today are designed around the idea of OOP. Extremist languages like Java force you to think of everything in terms of objects. But is Object Orientation (OO) a good idea? Does it have problems? Is it the right tool for everything? Let’s explore some of these questions in a slightly tongue in cheek and cathartic rant.
Imperative vs Declarative
The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code. — Paul Graham
Procedural programming languages are designed around the idea of enumerating the steps required to complete a task. OOP languages are the same in that they are imperative – they are still essentially about giving the computer a sequence of commands to execute. What OOP introduces are abstractions that attempt to improve code sharing and security. In many ways it is still essentially procedural code.
Declarative languages on the other hand are about describing computation. While a a declarative language necessarily maps down to imperative code, the resulting code often reveals less incidental complexity and can sometimes be much more easily parallelized.
State
The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. — Joe Armstrong
State is not your friend, state is your enemy. Changes to state make programs harder to reason about, harder to test and harder to debug. Stateful programs are harder to parallelize, and this is important in a world moving towards more units, more cores and more work. OOP languages encourage mutability, non determinism and complexity.
As someone who was initially hostile to the idea that state is the root of all problems, I initially greeted this idea with skepticism. Mutating state is so easy and fundamental in OOP that you often overlook how often it happens. If you’re invoking a method on an object that’s not a getter, you’re probably mutating state.
Nouns and Verbs
Java is the most distressing thing to happen to computing since MS-DOS. — Alan Kay
The typical college introduction to OOP starts with a gentle introduction to objects as metaphors for real world concepts. Very few real world OOP programs even consist entirely of nouns, they’re filled with verbs masquerading as nouns: strategies, factories and commands. Software as a mechanism for directing a computer to do work is primarily concerned with verbs.
OOP programs that exhibit low coupling, cohesion and good reusability sometimes feel like nebulous constellations, with hundreds of tiny objects all interacting with each other. Sacrificing readability for changeability. Many of OOP best practices are in fact encouraged by functional programming languages.
Inheritance vs composition
Object-oriented programming is an exceptionally bad idea which could only have originated in California — Edsger W. Dijkstra
Inheritance is one of the primary mechanisms for sharing code in an an OO language. But this idea is so problematic that even the keenest advocates of OO discourage this pattern. Inheritance forces you to define the taxonomy and structure of your application in advance, with all it’s connections and intricacies. This structure is resistant to change which is one of the primary problems software developers face every day. It also fails to model some pretty fundamental concepts.
Further reading
This is far from an exhaustive list of the criticisms leveled at OOP. While I believe the problems with OOP are extensive, I do think it is a valuable mechanism for developing software. But is certainly not the only one. The biggest problem in my mind is thus:
When people overcome the significant hurdle of fully appreciating OOP, they tend to apply it to every problem. OOP becomes the solution, and every problem looks like a nail.
There’s got to be a better way…
For the lulz:
You want to make your way in the CS field? Simple. Calculate rough time of amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the dusty archives, dig out something fun, and go for it. It’s worked for many people, and it can work for you. — Ron Minnich
February 21, 2013 at 6:40 pm
all evidence points to this article being bullshit.
even if you don’t agree, you still need to respect it as a concept. while I would never shit on functional programming, you shitting on OOP is just makes you look like a looney cowboy coder.
February 25, 2013 at 11:04 am
If you read the article, besides declaring upfront that it was meant to be read ‘tongue-in-cheek’ I state that OOP is still a valuable concept in the conclusion.
February 25, 2013 at 11:20 am
You don’t have to respect it as a concept. The entirety of OOP design can be approximated as a list of functions scoped in a closure bound to a publicly mutable context.
Classes aren’t a fundamental particle of programming. Objects are (sort of), but only because they’re lists in OOP clothing. Mutable (shared) state is the main enemy.
March 12, 2013 at 3:14 am
A powerful idea for how to reconcile these ideas is the “functional core” (which may include immutable instances) wrapped in a thin “imperative shell.”
Destroy All Software has a short screencast with more detail (but costs cash to watch.)
March 13, 2013 at 3:06 am
There’s an argument to be made that OO designs done right scale better (along the axis of program size & complexity) than procedural ones, and I wonder whether OO might scale better than functional designs too.
I’m not talking about the superficial sense in which OO allows one to reason about the problem by forming classes with close association to entities in the problem domain.
Instead I’m talking about the way that OO done right allows one to make designs such that, when one wants to add to the program, it’s possible to do so by adding new classes in new files, without modifying any of your existing code.
However, most code written in ostensibly OO languages doesn’t get this right, so there’s a disconnect between the theoretical capabilities of OO, and how it’s commonly practised.
The writings of Carlo Pescio are the best summary of these ideas I’ve found, especially his example of an industrial pump, and follow up posts discussing the shortfalls of suggestions made in the comments.
http://www.carlopescio.com
March 13, 2013 at 3:23 am
TLDR; “Screwdrivers suck, everyone should use hammers”.
March 14, 2013 at 2:01 pm
When Alan Kay said “Java is the most distressing thing to happen to computing since MS-DOS” I doubt if he thought it was too object oriented. At least Java has the ‘final’ keyword. Not really a useful quote in this context, IMHO.
March 14, 2013 at 9:17 pm