OOP is dead

dfdub

A simple recursive grep is sufficient to describe the horrors I just saw:

PS C:\Users\dfdub\small_project_i_inherited> Get-ChildItem -Recurse | Select-String -Pattern "dynamic_cast" | Measure

Count    : 5821

That's it, folks. OOP is officially dead.

Steve_The_Cynic

@dfdub said in OOP is dead:

A simple recursive grep is sufficient to describe the horrors I just saw:
PS C:\Users\dfdub\small_project_i_inherited> Get-ChildItem -Recurse | Select-String -Pattern "dynamic_cast" | Measure

Count    : 5821
That's it, folks. OOP is officially dead.

What's interesting is not that the project contains dynamic_cast, but that there are so many of them. I would suggest that it's more indicative of a previous developer who didn't understand OOP rather than general moribundity of the concept.

dfdub

@Steve_The_Cynic said in OOP is dead:

What's interesting is not that the project contains dynamic_cast, but that there are so many of them. I would suggest that it's more indicative of a previous developer who didn't understand OOP rather than general moribundity of the concept.

That's the ~~joke~~reason I'm considering getting drunk at 9am.

Edit: The biggest problem in this code base seems to be a fear of ever changing any interfaces. A method returns a pointer to a superclass? Let's just dynamic_cast it to the actual type at the call sites rather than fix the method!

Seems like refactoring is dead, too.

Carnage

@dfdub said in OOP is dead:

@Steve_The_Cynic said in OOP is dead:

What's interesting is not that the project contains dynamic_cast, but that there are so many of them. I would suggest that it's more indicative of a previous developer who didn't understand OOP rather than general moribundity of the concept.

That's the ~~joke~~reason I'm considering getting drunk at 9am.

Edit: The biggest problem in this code base seems to be a fear of ever changing any interfaces. A method returns a pointer to a superclass? Let's just dynamic_cast it to the actual type at the call sites rather than fix the method!

Seems like refactoring is dead, too.

Some music you like on full blast, a beer and solitude with you, code and refactoring tools for a couple of days will be a nice way to deal with that.

strangeways

ohai thar. reporting in from a 30-year-old-ish codebase that has never seen any real refactoring and still contains bits of code from 1991.

> /usr/bin/ag -c --cpp --stats-only -s dynamic_cast
5074 matches
1428 files contained matches
29418 files searched

> /usr/bin/ag -c --cpp --stats-only -s reinterpret_cast
2445 matches
561 files contained matches
29418 files searched

dfdub

@Carnage said in OOP is dead:

Some music you like on full blast, a beer and solitude with you, code and refactoring tools for a couple of days will be a nice way to deal with that.

…at least for the simple cases like the one I mentioned above. This software is now actually used by customers and pretty difficult to test, so major refactorings a will take a while and should be done gradually. I could estimate when I'll be done by finding out my average commit rate and guesstimating the average number of removed casts per commit, but .

@strangeways said in OOP is dead:

reporting in from a 30-year-old-ish codebase that has never seen any real refactoring and still contains bits of code from 1991.

Oh, so it's even from a time when dynamic casts were prohibitively expensive on every compiler? Nice.

Edit: Those are rookie numbers. My average is 25 dynamic casts per header/source file. I wish I was making these number up.

ixvedeusi

@strangeways said in OOP is dead:

/usr/bin/ag -c --cpp --stats-only -s reinterpret_cast
2445 matches
561 files contained matches
29418 files searched

Nope thread is

dcon

@Steve_The_Cynic said in OOP is dead:

I would suggest that it's more indicative of a previous developer who didn't understand OOP rather than general moribundity of the concept.

Where I usually see them is when using things like Windows listctrl's and treectrl's in a framework. Those take some kind of generic pointer - so you need to dynamic cast it back to what it is.

Mason_Wheeler

What exactly does heavy use of a specific feature of a language that does an abysmal job of implementing OOP concepts in the first place have to do with the principle of OOP being "dead"?

Zenith

@Mason_Wheeler Lack of inheritance would be a bigger sign IMO. It's just amazing how many codebases I've seen that are full of objects but don't have any inheritance beyond where the framework/wizard literally forces it like inheriting from System-Windows-Forms-Form or System-Web-UI-Page.

dkf

@Zenith said in OOP is dead:

Lack of inheritance would be a bigger sign IMO

Given how often inheritance is overused, a codebase that lacks it isn't automatically bad at all.

Zenith

@dkf said in OOP is dead:

@Zenith said in OOP is dead:

Lack of inheritance would be a bigger sign IMO

Given how often inheritance is overused, a codebase that lacks it isn't automatically bad at all.

Not when you have 70 service classes that are all reimplementing the same dozen utility functions every single time.

My personal library doesn't do much inheritance because it's not doing much that would benefit from inheritance.

Carnage

@dkf said in OOP is dead:

@Zenith said in OOP is dead:

Lack of inheritance would be a bigger sign IMO

Given how often inheritance is overused, a codebase that lacks it isn't automatically bad at all.

I pretty much only use it where I want polymorphic behaviour, everywhere else I think it's just needless clutter, pretty much. For the project I'm currently building, that's pretty much for data structures with things like different types of applicants, addresses and stuff.

Mason_Wheeler

@dkf said in OOP is dead:

@Zenith said in OOP is dead:

Lack of inheritance would be a bigger sign IMO

Given how often inheritance is overused, a codebase that lacks it isn't automatically bad at all.

I often see this notion raised as an article of faith, generally by ideologues pushing Yet Another Attempt to legitimize failed dogmatic-FP approaches, but I've never actually seen any evidence for the claim.

Kamil Podlesak

@Mason_Wheeler said in OOP is dead:

@dkf said in OOP is dead:

@Zenith said in OOP is dead:

Lack of inheritance would be a bigger sign IMO

Given how often inheritance is overused, a codebase that lacks it isn't automatically bad at all.

I often see this notion raised as an article of faith, generally by ideologues pushing Yet Another Attempt to legitimize failed dogmatic-FP approaches, but I've never actually seen any evidence for the claim.

Usually it's about using interfaces/protocols instead of inheritance... which is AFAIK still meaningless distinction in C++

Zenith

@Kamil-Podlesak You mean the pattern where every single Object gets an IObject interface that's never used anywhere because reasons?

Mason_Wheeler

@Zenith said in OOP is dead:

@Kamil-Podlesak You mean the anti-pattern where every single Object gets an IObject interface that's never used anywhere because reasons?

Interfaces are ways to categorize some subset of a class's functionality, so that any member of the category can be substituted in at will. A category containing only one member is pointless and wasteful.

dkf

@Mason_Wheeler said in OOP is dead:

I often see this notion raised as an article of faith

Basically, when you see someone using inheritance where composition would be better, you've got a candidate for . Composition works very well and is very appropriate in many cases. Another over-inheritance antipattern is where someone inherits from, say, Button just to add a particular label to it. Inheritance for the purpose of configuration is just horrible. That's not to say that inheritance is always wrong, not at all, but there have been some truly gross overuses in the past by the all-I-have-is-~~a-hammer~~inheritance brigade.

I like interfaces as a concept, but don't like interfaces (or abstract superclasses) when they only have a single implementation.

Kamil Podlesak

@Mason_Wheeler said in OOP is dead:

@Zenith said in OOP is dead:

@Kamil-Podlesak You mean the anti-pattern where every single Object gets an IObject interface that's never used anywhere because reasons?

Interfaces are ways to categorize some subset of a class's functionality, so that any member of the category can be substituted in at will. A category containing only one member is pointless and wasteful.

That's a different topic, but it's only a question of time until someone brings the famous AbstractSingletonProxyFactoryBean anyway, and these are actually the same
These very old hacks are used to work around the lack of meta-programming in Java. It has been largely replaced by bytecode generators (which is, on hand, way more hacky dark magic - but on the other hand, it can be well-hidden), but some people still keep the old ways (either because of or because of cargo cult).

PS: is that there is no cargo cult emoji.

frillunflop

@Mason_Wheeler said in OOP is dead:

@Zenith said in OOP is dead:

@Kamil-Podlesak You mean the anti-pattern where every single Object gets an IObject interface that's never used anywhere because reasons?

Interfaces are ways to categorize some subset of a class's functionality, so that any member of the category can be substituted in at will. A category containing only one member is pointless and wasteful.

... Unless you want to create a mock of said object, because you cannot connect to you database/hardware in your testing setup.

Even then, this is still a . A good design does need an IObject for every Object when writing tests. A bad design may be beaten into (barely) becoming testable, though.

Anguirel

@dkf said in OOP is dead:

Basically, when you see someone using inheritance where composition would be better, you've got a candidate for .

It took me a fair bit of effort to break that habit. My Java class in college massively overused inheritance even where basic composition would have been much simpler and cleaner.

Mason_Wheeler

@dkf said in OOP is dead:

@Mason_Wheeler said in OOP is dead:

I often see this notion raised as an article of faith

Basically, when you see someone using inheritance where composition would be better, you've got a candidate for .

Yes, the "favor composition over inheritance" slogan is always brought out to defend the "inheritance is evil" slogan, but again, never with any evidence behind it. To me, a programmer saying "favor composition over inheritance" makes exactly as much sense as a carpenter saying "favor drills over saws." They're very different tools that do different things, and the competence of anyone who seems to think that they can be used interchangeably ought to be called into question.

Another over-inheritance antipattern is where someone inherits from, say, Button just to add a particular label to it. Inheritance for the purpose of configuration is just horrible.

Why? I'm amused by this, because I remember being at a conference where the speaker made exactly the opposite point: being able to create specialized components like an "OKButton" (a standard Button subclass whose text says OK and whose Modal Result action is hard-coded to return the OK enum) or a "CancelButton" (same thing, different details) is an awesome thing because when you create so many of these in your day-to-day work, it adds up to a big time saver. (I'm not completely convinced by his point, but at least he provided a solid rationale for it. All I'm hearing from you is not to do this because it's "just horrible," whatever that means.)

BernieTheBernie

@dfdub said in OOP is dead:

That's it, folks. OOP is officially dead.

But it did not die.
Because it was actually never really alive - it is beyond the grasping capability of almost all porgrammers.

Mason_Wheeler

@frillunflop said in OOP is dead:

@Mason_Wheeler said in OOP is dead:

@Zenith said in OOP is dead:

@Kamil-Podlesak You mean the anti-pattern where every single Object gets an IObject interface that's never used anywhere because reasons?

Interfaces are ways to categorize some subset of a class's functionality, so that any member of the category can be substituted in at will. A category containing only one member is pointless and wasteful.

... Unless you want to create a mock of said object, because you cannot connect to you database/hardware in your testing setup.

Even then, this is still a . A good design does need an IObject for every Object when writing tests. A bad design may be beaten into (barely) becoming testable, though.

Mocks are one of those things that sounds like a cool idea in theory, and in practice generally turn out to be a horrible mess. The vast majority of tests I've seen that use mocks demonstrably do far more to test that the behavior of the mock (which is 100% under the control of the person writing the test) is what was expected than they ever do to test the actual code that the mock is supposed to be there to support. It's gotten to the point where I've basically written the concept off entirely: if your test requires a mock, it's very likely that you're doing your test in some fundamentally wrong way.

Mason_Wheeler

@BernieTheBernie said in OOP is dead:

@dfdub said in OOP is dead:

That's it, folks. OOP is officially dead.

But it did not die.
Because it was actually never really alive - it is beyond the grasping capability of almost all porgrammers.

Ok, please keep the gaslighting in the Garage. OOP has taken over the world and become the default, used by virtually all professional programmers the world over for any and all types of projects, because it works so well and is so easy to grasp. Trying to claim otherwise is simply dishonest.

dkf

@Mason_Wheeler said in OOP is dead:

@dkf said in OOP is dead:

@Mason_Wheeler said in OOP is dead:

I often see this notion raised as an article of faith

Basically, when you see someone using inheritance where composition would be better, you've got a candidate for .

Yes, the "favor composition over inheritance" slogan is always brought out to defend the "inheritance is evil" slogan, but again, never with any evidence behind it. To me, a programmer saying "favor composition over inheritance" makes exactly as much sense as a carpenter saying "favor drills over saws." They're very different tools that do different things, and the competence of anyone who seems to think that they can be used interchangeably ought to be called into question.

Another over-inheritance antipattern is where someone inherits from, say, Button just to add a particular label to it. Inheritance for the purpose of configuration is just horrible.

Why? I'm amused by this, because I remember being at a conference where the speaker made exactly the opposite point: being able to create specialized components like an "OKButton" (a standard Button subclass whose text says OK and whose Modal Result action is hard-coded to return the OK enum) or a "CancelButton" (same thing, different details) is an awesome thing because when you create so many of these in your day-to-day work, it adds up to a big time saver. (I'm not completely convinced by his point, but at least he provided a solid rationale for it. All I'm hearing from you is not to do this because it's "just horrible," whatever that means.)

For the timesaving argument to be true, either configuring those buttons is a complicated thing () or the speaker finds configuring things to be difficult (). But ease of configuration does depend on having some way to plug in code to do the reacting to the button being activated (clicked, etc.) and when doing that is difficult I can see the point. And also a place where the containing language is making programming harder than it should.

dkf

@Mason_Wheeler said in OOP is dead:

Mocks are one of those things that sounds like a cool idea in theory, and in practice generally turn out to be a horrible mess.

To summarize: Mocks:

dcon

@Mason_Wheeler said in OOP is dead:

Why? I'm amused by this, because I remember being at a conference where the speaker made exactly the opposite point: being able to create specialized components like an "OKButton" (a standard Button subclass whose text says OK and whose Modal Result action is hard-coded to return the OK enum) or a "CancelButton" (same thing, different details) is an awesome thing because when you create so many of these in your day-to-day work, it adds up to a big time saver. (I'm not completely convinced by his point, but at least he provided a solid rationale for it. All I'm hearing from you is not to do this because it's "just horrible," whatever that means.)

I do this a bunch. But in my defense, it's more than just a name! It's also applying styles (Qt) so I can have a RoundButton (with modified up/down/checked/disabled states). Basically, if I need to use it in more than 1 (or 2) places, I'm going to create a derived class. Or at the very least, a helper function. The way I decide between the 2 is usage - derived class if it is used in more than one place, helper function is there are multiple instances in the one class.

Kamil Podlesak

@frillunflop said in OOP is dead:

@Mason_Wheeler said in OOP is dead:

@Zenith said in OOP is dead:

@Kamil-Podlesak You mean the anti-pattern where every single Object gets an IObject interface that's never used anywhere because reasons?

Interfaces are ways to categorize some subset of a class's functionality, so that any member of the category can be substituted in at will. A category containing only one member is pointless and wasteful.

... Unless you want to create a mock of said object, because you cannot connect to you database/hardware in your testing setup.

Hey, 2010 called and... I suppose you should warn them about 2020.

        ArrayList<String> mock = mock(ArrayList.class);
        when(mock.size()).thenReturn(5);

        assertEquals(5, mock.size());
        assertEquals(5, mock.size());

Even then, this is still a . A good design does need an IObject for every Object when writing tests. A bad design may be beaten into (barely) becoming testable, though.

More importantly: if you need to mock everything, then something is clearly wrong. There are very, very few things that needs to be mocked, usually remote systems (which, to be fair, you explicitly said).

Mason_Wheeler

@dkf said in OOP is dead:

For the timesaving argument to be true, either configuring those buttons is a complicated thing () or the speaker finds configuring things to be difficult ().

Or they just do it a lot because they're extremely common. As per XKCD:

If it only takes 2 minutes to set up the OKButton class, and you end up using it every day...

frillunflop

@Kamil-Podlesak said in OOP is dead:

        ArrayList<String> mock = mock(ArrayList.class);
        when(mock.size()).thenReturn(5);

        assertEquals(5, mock.size());
        assertEquals(5, mock.size());

This... is just evil. Just think of how many invariants of ArrayList get broken here!

What a magnificent bad example!

Even then, this is still a . A good design does need an IObject for every Object when writing tests. A bad design may be beaten into (barely) becoming testable, though.

More importantly: if you need to mock everything, then something is clearly wrong. There are very, very few things that needs to be mocked, usually remote systems (which, to be fair, you explicitly said).

Amen.

dkf

On the grounds that it is slightly, very slightly relevant to OOP and related concepts, I found this when looking for “duck typing”:

BernieTheBernie

@Mason_Wheeler said in OOP is dead:

OOP has taken over the world and become the default, used by virtually all professional programmers the world over for any and all types of projects, because it works so well and is so easy to grasp.

Ha ha ha ha...
Let me correct that:
Some odd porgramming style often dubbed "OOP" has taken over the world and become the default, used by virtually all professional porgrammers the world over for any and all types of projects, who believe they are doing object-oriented porgramming but always failed to understand elementary basics of object-orientation.

Grunnen

@Mason_Wheeler One situation I encountered recently, was our "Enterprise Communication System". It's expensive proprietary software, so our company only has one or a few servers. However, the automated tests should be able to run from anyone's personal system. So it was quite logical to put the client-side part into a class, define an interface for it and create a mock which can be used to check that the correct JSON data is written to the correct communication channel.

Another one are the custom drawing routines. To check it using automated tests, there is no way around creating a mock window/canvas that can be compared against a PNG to check if the rendering was correct.

But apart from the final input/output endpoints of a program, I haven't seen a situation so far where a mock seems worth it.

Mason_Wheeler

@BernieTheBernie said in OOP is dead:

@Mason_Wheeler said in OOP is dead:

OOP has taken over the world and become the default, used by virtually all professional programmers the world over for any and all types of projects, because it works so well and is so easy to grasp.

Ha ha ha ha...
Let me correct that:
Some odd porgramming style often dubbed "OOP" has taken over the world and become the default, used by virtually all professional porgrammers the world over for any and all types of projects, who believe they are doing object-oriented porgramming but always failed to understand elementary basics of object-orientation.

Nonsense! No true Scotsman would write code like that!

DogsB

@Zenith said in OOP is dead:

@Mason_Wheeler Lack of inheritance would be a bigger sign IMO. It's just amazing how many codebases I've seen that are full of objects but don't have any inheritance beyond where the framework/wizard literally forces it like inheriting from System-Windows-Forms-Form or System-Web-UI-Page.

Inheritance is scary. That's why everything is a micro service now. No need for a utilities. We're not sharing any code.

*edit
Something I'm coming across in spring development is the return of static utilities everywhere ànd a fear of creating new services that can be injected and mocked easily. Unit testing appears to have died a death too. Its àll about integration tests that take two minutes to run and don't cover edge conditions.

foo > 2
foo < 2

what about foo == 2? Fucking junior devs.

dkf

@Grunnen said in OOP is dead:

But apart from the final input/output endpoints of a program, I haven't seen a situation so far where a mock seems worth it.

Mocking those and services contacted along the way, that's reasonable. Except that it's insanely easy to end up having practically everything tested except the critical code that does the communications with the service, or for that service to suddenly change after a long time and that mock to now be less than worthless…

Grunnen

@dkf said in OOP is dead:

Except that it's insanely easy to end up having practically everything tested except the critical code that does the communications with the service

Oh, yeah, absolutely. But that's still much better than that nothing is tested before putting it onto the staging environment.

slapout1

@dfdub Has Netcraft confirmed it?

Zenith

@DogsB When you stay "static utilities," do you mean DLLs with static functions or static analysis of code?

Because I tire of having "tested" mean "CA² and fxCop didn't find any brackets in the wrong place."

Gąska

@Mason_Wheeler said in OOP is dead:

OOP has taken over the world and become the default, used by virtually all professional programmers the world over for any and all types of projects, because it works so well and is so easy to grasp.

Now explain JavaScript.

Carnage

@Mason_Wheeler said in OOP is dead:

@dkf said in OOP is dead:

@Zenith said in OOP is dead:

Lack of inheritance would be a bigger sign IMO

Given how often inheritance is overused, a codebase that lacks it isn't automatically bad at all.

I often see this notion raised as an article of faith, generally by ideologues pushing Yet Another Attempt to legitimize failed dogmatic-FP approaches, but I've never actually seen any evidence for the claim.

I have seen codebases where everything inherited from an interface, usually it is a single implementation of every interface, and single method classes were abundant. And I've even spotted actual managermanagerfactoryfactory classes in the wild. OOP has mellowed significantly since it's mad heyday.

Mason_Wheeler

@Gąska said in OOP is dead:

@Mason_Wheeler said in OOP is dead:

OOP has taken over the world and become the default, used by virtually all professional programmers the world over for any and all types of projects, because it works so well and is so easy to grasp.

Now explain JavaScript.

Natural monopoly that rode HTML's coattails to prominence. And ever since it got too big to be ignored, three major trends have developed: 1) the addition of more and better OOP features to JavaScript in order to make it better-suited to handling the complexities of modern programming, 2) the development of systems to transpile proper OO languages down to JS, and 3) the development of alternative systems to replace JS because it's got so many fundamental problems that it's difficult to actually fix. (The latest and (currently) most promising being WASM.)

Gąska

@Mason_Wheeler said in OOP is dead:

@Gąska said in OOP is dead:

@Mason_Wheeler said in OOP is dead:

OOP has taken over the world and become the default, used by virtually all professional programmers the world over for any and all types of projects, because it works so well and is so easy to grasp.

Now explain JavaScript.

Natural monopoly that rode HTML's coattails to prominence.

OK and now explain Node. By now JS has become the leading programming language for all kinds of server-side programs, as well as native desktop and mobile apps, and none of that has anything to do with HTML.

dfdub

@Zenith said in OOP is dead:

Not when you have 70 service classes that are all reimplementing the same dozen utility functions every single time.

But code re-use is exactly the wrong reason to use inheritance and the easiest way to break the LSP. What you need are separate utility classes.

dfdub

@slapout1 said in OOP is dead:

Has Netcraft confirmed it?

Mason_Wheeler

@Gąska said in OOP is dead:

By now JS has become the leading programming language for all kinds of server-side programs, as well as native desktop and mobile apps

[citation needed]

Gąska

@Mason_Wheeler okay maybe not leading. But certainly in top 3. But if you find even that questionable (it's incredibly hard to find any source of numbers for any server side technology), let's go back a few years and remember the times where PHP was the unchallenged king of everything web. Despite being incredibly crap and hated by pretty much everyone. Despite not even having any OOP concepts.

Basically - my point is that popularity and quality are uncorrelated. Inheritance-style OOP isn't popular because it's good; it's popular because of Java.

Mason_Wheeler

@Gąska said in OOP is dead:

@Mason_Wheeler okay maybe not leading. But certainly in top 3. But if you find even that questionable (it's incredibly hard to find any source of numbers for any server side technology), let's go back a few years and remember the times where PHP was the unchallenged king of everything web. Despite being incredibly crap and hated by pretty much everyone. Despite not even having any OOP concepts.

Which version of PHP are you referring to? Because just like JavaScript, once PHP became too big to ignore, users demanded -- and got -- OOP added to it.

Basically - my point is that popularity and quality are uncorrelated. Inheritance-style OOP isn't popular because it's good; it's popular because of Java.

And how did Java get popular?

Carnage

@Mason_Wheeler said in OOP is dead:

@Gąska said in OOP is dead:

@Mason_Wheeler okay maybe not leading. But certainly in top 3. But if you find even that questionable (it's incredibly hard to find any source of numbers for any server side technology), let's go back a few years and remember the times where PHP was the unchallenged king of everything web. Despite being incredibly crap and hated by pretty much everyone. Despite not even having any OOP concepts.

Which version of PHP are you referring to? Because just like JavaScript, once PHP became too big to ignore, users demanded -- and got -- OOP added to it.

Basically - my point is that popularity and quality are uncorrelated. Inheritance-style OOP isn't popular because it's good; it's popular because of Java.

And how did Java get popular?

By the lie "write once, run everywhere"