
The Rise and Fall of Object Oriented Programming - azemda
https://medium.com/machine-words/the-rise-and-fall-of-object-oriented-programming-d67078f970e2
======
MockObject
> However, as the years went by, people started to realize that the strict
> approach to object orientation created a number of problems. These problems
> tended to be of the kind that makes code complex, hard to understand, and
> hard to test.

No, ease of testing is one of the reasons for OO adoption, and probably the
primary reason software is much more stable than it was in the mid 90s.

> Many of those higher-level classes are “polluted” with methods and
> properties that are only relevant to a small number of subclasses.

Well, then it's broken and needs to be refactored.

> During my last couple years working at Google, I created a new user
> interface toolkit called “Quantum Wiz”

Of course, in true Google style, you wrote something from scratch instead of
refactoring the old.

> composition > inheritance

Not a new finding. I learned this in 2000, at the peak of OO craze.

> Because object oriented inheritance is about organizing things into classes,
> it doesn’t model the real world very well; what it does model well is the
> way humans think about the real world.

That's the idea. Good software is written for the simplicity of those poor
slobs charged with maintaining it -- often ourselves a year later.

> A physical object has many uses other than the specific purpose for which it
> was built. I can use a coffee cup as a paperweight or a doorstop;

The whole idea of modeling is to remove certain details! Otherwise the model
would be identical to the genuine article, and would provide no benefit.

~~~
tabtab
Re: _Well, then it 's broken and needs to be refactored._

Refactoring means the original design didn't handle change well. Refactoring
is badge of disgrace, and should not be considered a standard practice any
more than putting out kitchen fires should be considered a standard practice
of cooking. One of the key points of abstraction is to make the code change-
friendly. If you have to refactor, the code failed that job. Minor rework is
expected upon new requirements, but complete structural overhauls should be
avoided, in part because it can create cascading side-effects.

Re: _The whole idea of modeling is to remove certain details! Otherwise the
model would be identical to the genuine article, and would provide no
benefit._

But in some cases OO-based modelling becomes awkward or forced. Does the
action of "gluing" belong with the glue or with the object being glued
(fixed)? We can _force_ it to be with one or the other to satisfy "OO rules",
but that doesn't necessarily mean it's a good model. It's a forced model.

Re: _[article] it doesn’t model the real world very well; what it does model
well is the way humans think about the real world._

It doesn't model all thinking well. For smaller sub-systems it's fine. But OOP
seems to get messy and tangled on a larger scale.

~~~
MockObject
> Refactoring is badge of disgrace, and should not be considered a standard
> practice any more than putting out kitchen fires should be considered a
> standard practice of cooking.

I can only grant you the benefit of the doubt and assume you aren't quite
using the word the way the rest of the industry does.

Replacing two similar code fragments with two calls to a single method is an
example of refactoring. In no universe would that ever be considered any sort
of kitchen fire.

~~~
tabtab
"Refactoring" is also often used when for example somebody uses the wrong OOP
pattern (doesn't fit changes) and has to convert it to a different OOP
pattern.

------
royjacobs
Isn't the argument that there is nothing inherently wrong with OOP but like
all things, it shouldn't be used exclusively?

For instance, working with language like Kotlin or C# it's fairly
straightforward to get the best of both worlds: Use inheritance where
appropriate, favor composition in all other cases.

IMO being dogmatic about not wanting inheritance altogether will result in
friction as well: The fact that Rust eschews inheritance altogether will
increase boilerplate whenever you want to do something that is 'inheritance-
like'. Sure, people will argue that in 90% of the cases this is bad design,
but for the cases where it IS the best approach it's a shame it's not part of
your toolbox.

~~~
ashleyn
Inheritance is so natural to a GUI data structure. UI in Rust is incredibly
painful. Probably a reason behind the CPU-wasteful "immediate mode" fad.

~~~
0815test
_Implementation_ inheritance _may_ have its uses, but it's not for the faint
of heart. Its defining feature is _open recursion_; that is, defining an
object's external interface (its bundle of public and protected methods) _in
terms of itself_ (in that any method may be defined as calling any other
method of the same external interface) and then leaving the whole thing open
for _arbitrary_ overriding in "derived" classes, via a "tying the knot" trick.
Most treatments of OOP brush over this feature, but it creates a _huge_ amount
of complexity. It is even proper to say that something like this should be
avoided at all costs, IMHO.

------
jkoudys
I've always felt so alone in my distaste for ORMs. They often lead to at worst
taking way more data than you need and manipulating it all in a language
that's not very good at it, or at best running some kind of query-builder
which takes a far more complex configuration to get the same data that a
simple query could. Objects make much more sense as something to build from a
query, not something to be queried themselves.

If the tide is turning against ORMs, it probably has a lot to do with the
rising love for fp that this author covers. Languages like SQL are
declarative, as is fp, so that approach feels more natural to people these
days.

~~~
tabtab
ORM is one of those "dark grey boxes" we often have to deal with. When they
work as intended, they can indeed save time, but when they don't, you have to
fiddle in an organic fashion to solve or work around the problem, because
otherwise they are thousands of line of code if you wish to dig in code-wise.

As an alternative, use stored procedures with Dapper, or use smaller sub-
helpers that prepare most of the SQL statements or sub-statements for you but
don't outright hide it. They assist in creating SQL (and prepared statement
parameter mapping), but only assist, and are kept to less than a few hundreds
of lines of code.

Other dark-grey-boxes include URL route mappers, seen in MVC stacks, and HTML
formatters, such as Razor. When they don't work right you'll waste many many
hour fudging with them. I'd often rather replace the URL router with
Case/switch statements: it would be easier to debug; so what if it's a bit
more typing. It's a white box.

~~~
steverb
"As an alternative, use stored procedures with Dapper"

I understand using Dapper. It is exactly what I want in an ORM. But I've yet
to see anyone make a convincing argument for using stored procedures over
using parameterized SQL.

------
caseymarquis
People will write terrible code in every language. Some languages make it
easier than others, but mostly the problem is between the chair and the
keyboard.

------
kryptonomist
One use case where I found OO particularly unsuitable is applications that
rely heavily on events. Trying to understand what's happening is hard, when
any call to your object structure can trigger changes at any level of your
hierarchy, triggering other changes again, and so on.

Luckily, the rising popularity of Swift, Kotlin, and Go, will push for a more
reasonable use of OO in combination with FP.

~~~
tabtab
Re: _One use case where I found OO particularly unsuitable is applications
that rely heavily on events._

I agree. Events typically have to "belong" to something in OOP, but how they
are best grouped or managed may not fit a single-item belonging-ness.

I'd like to see languages which are flexible in how events are organized in
file systems. Their file grouping wouldn't have to reflect some object
hierarchy or odd code structure, it would be organized how a team wants.
Conway's law. A "header" would define the criteria for triggering. You could
have wild-card based triggering and expression based triggering. wild-card
triggering would be more efficient and orderly, but one needs expression-based
triggering for certain circumstances.

Perhaps manage all those event handlers in an RDBMS. But our existing tools
and IDE's are file-centric when they should be looking to be RDBMS-friendly.
When you are dealing with thousands of fairly-similar things, such as event
handlers, it's time to think about databases, not files and folders. OOP and
files/folders don't scale very well.

~~~
professorTuring
I can't agree. Do you know which application who rely heavily on events is
anywhere and it is programmed in OOP all around the world?

Windows management systems. Everywhere. OOP works like a charm.

Also, all that stuff you are saying about "expression-based" triggering, it
exists and working fine...

Also you are mixing OOP with files and folders and I can't understand why...

~~~
tabtab
Re: _Windows management systems. Everywhere. OOP works like a charm._

Good enough, perhaps. Charm, no.

Re: _Also, all that stuff you are saying about "expression-based" triggering,
it exists and working fine..._

Perhaps, but expression-based dispatching is not OOP. It's more comparable to
relational or functional.

Re" _Also you are mixing OOP with files and folders and I can 't understand
why..._

I don't necessarily proposing mixing. If we can do it without OOP, that would
be fine by me. I prefer the source code be organize by how a shop wants to
work, not how the framework forces you to. Conway's Law.

Better yet, manage it in a database so one can sort, search, group, and filter
by specific need at a given time. Why hard-wire a grouping when we have
relational? If I want to see all button-handling events together, query, boom,
done! If I want to see events for widgets with labels having the text "cup" in
them, query, boom, done! Etc. Bill Gates won't determine my grouping/view, you
don't determine my grouping/view, but _I_ do. Me, myself, and I. I like that,
it makes me productive.

------
professorTuring
This article only says one truth: OOP is not as famous as it used to be.

The rest of it it's completely mistaken. The writer has no clue about OOP.

Let me tell you the problem with OOP. Everybody said "use objects" you will
re-use them over and over, not only for this project but projects in the
future as well.

But we already have libraries and I still yet to find someone (or enterprise)
reusing its own code.

Every respectable programmer knows he must refactor his old code again because
it's not so good anymore.

~~~
tabtab
There have been many claims about OOP that turned out to be mostly hype:
reuse, intuitiveness, change-friendly, etc. What's remaining is more subtle
and nuanced.

------
AzzieElbab
I look at oop as a DSL. A robot that has a method to raise hand is infinitely
better mental model than a function from robot to new robot whose hand is
raised.

~~~
CyberFonic
Sergey Dmitriev of JetBrains once said at a conference or interview (I forgot
which) that any well designed class library is in effect an embedded DSL.

When you consider that UML tends towards object-oriented modelling of systems,
it is practical to consider the methods as the action semantics of the model.

------
daveslash
To those who enjoyed reading this article, I'd also recommend this one.
[https://steve-yegge.blogspot.com/2006/03/execution-in-
kingdo...](https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-
nouns.html)

~~~
hinkley
My main beef with this genre of article is that code is for humans, and if you
don't think humans like nouns, bring an object to work that nobody there has
every seen, and count how many people ask what it is before they ask what it
does.

For many people, that kingdom of nouns lives in their brains. I'm not saying I
agree with this entirely. I don't even think I'm saying we shouldn't fight it
- I certainly have felt the pain of people wanting to pigeonhole me at work by
noun instead of looking at what verbs I'm capable of.

But it's out there, and you don't have to look very hard to find it.

