[Nutmog]

What baffles me about OOP is that massive aspects of how to use it have changed, and that change happened after it gained popularity as a good technique. How could it have become popular when people were doing it wrong? The article mentions inheritance, but there's also heavy vs light classes. When I was taught OOP, an object knew how to do all the things to itself. It could draw itself on the screen, modify itself, save itself to a file, etc. Now that's turned on its head and is bad practice.

So if OOP was great with inheritance and heavy classes, how can it now be bad with inheritance and heavy classes? Were the original OOP evangelists doing it wrong and promoting something they hadn't actually tried enough to discover its problems (ie hype)? Was it just misunderstood and inheritance has always been known to be something to avoid and light (single public method) classes always been a good idea but computer science professors didn't understand it?

[al2o3cr]

"Was it just misunderstood and inheritance has always been known to be something to avoid and light (single public method) classes always been a good idea but computer science professors didn't understand it?"

Could be. Or it could be that it's possible to write working programs with many different methodologies and 90% of what developers argue about is fashion not substance...

[Jtsummers]

Initially there was machine code (well, manual wiring of computers). Then there was assembly, and that worked. Then there were Fortran and Lisp and Algol, and somehow we still needed more languages and methodologies.

GOTO was fine, until it wasn't. Then we had structured programming and things were better.

Every language and methodology has had its pros and cons, and in general the trend has been towards "better" (by some dimension in a large, multi-dimensional space) languages and methods.

Heavy classes were an improvement over what existed before them, not because they were heavy classes, but because what was before them was still (often) unstructured code.

Light classes, moving things up a level so that, for instance, your graphical object doesn't draw itself, but instead knows enough to inform the drawing class how to draw it, is better in one particular regard: same object can be rendered in any system by updating the layer above it. So instead of updating 100 drawn objects, you now update 1 drawing object.

That doesn't make heavy classes "wrong", they were fine at their time (probably more performant, and almost certainly an improvement in some ways over what existed before them). But light classes with some degree of abstraction is often better (too much is still a problem, damn you <person I inherited this project from>). Better, in this case: shorter code, fewer "moving" parts, easier to reason about, easier to manipulate. It is potentially less performant (depending on language and design choices), but that's not a guarantee.

[jdmichal]

There has definitely been continued learning of how to best use OOP, as with any programming paradigm. While they all existed individually before-hand, the SOLID principles as a collection weren't formalized until the 2000's. [0] For instance, "heavy" classes is likely a clear break of Single Responsibility and is probably also a break of Interface Segregation. I also can't recall ever seeing an introduction to inheritance that doesn't break the Liskov substitution principle -- sometimes subtly, but usually quite overtly.

I think the large issue with OOP education is that it is still being taught as a set of capabilities without the appropriate constraints (SOLID) that have been learned by engineers under fire.

[0] https://en.wikipedia.org/wiki/SOLID_%28object-oriented_desig...

[yxhuvud]

Perhaps the question isn't binary, but rather have a whole range of answers. Heavy classes was probably better than the procedural code that came before it, but light classes end up more easy to reason about in the long run. I know for a fact that I have made that progression as I gained experience.

[coldtea]

>What baffles me about OOP is that massive aspects of how to use it have changed, and that change happened after it gained popularity as a good technique. How could it have become popular when people were doing it wrong?

Your arguments boils down to "how come something that had utility X at some point in time, have less than X at a later point", which frankly I don't think is surprising at all, nor logically contradictory (which seems to be the assumption).

How is that surprising? It happens with most emerging programming paradigms/technologies.

They first get popularity for some new benefits they bring, and then, as the dust settles, the community finds out the best ways to do something, shapes their best practices etc.

Two examples:

1) JAVA. Initial lure: runs anywhere, easier to use than C/C++, fast, etc. Java, then went through the crazy J2EE, XML everywhere, etc phases, and after that they found a balance on how you should write code, including adopting more functional styles now.

2) PHP. Initial lure: dead easy to install, comes with every function webdevs needed at the time, runs on all cheap hosts, easy syntax. Community used crappy coding practices, bad idioms etc, but slowly improved their ways, found new ways to structure code, etc.

>So if OOP was great with inheritance and heavy classes, how can it now be bad with inheritance and heavy classes?

That was then, and this is now.

Neither CPUs, nor the available programming languages, nor needs, nor our collective understanding of programming is the same.

The same way "Finding Nemo" might be good when you're 10 (and given your other options at the time), but at 30 you have a lot more movie options...

1) CPUs: are now multicore, and OO is NOT the best way to get advantage of them (push towards pure, functional, etc).

2) Available programming languages: then, at least the mainstream ones where ...assembler, plain Pascal, C, etc, compared to which OO was a novel and handy way to structure programs. Now we have much more options.

3) Needs: back then --80s, 90s-- it was the golden age of Desktop GUI programming, for which OO is a quite good match. For web programming and the kind of work we do now, not so much.

4) Collective understanding of programming: back when a closure was something exotic, and functional concepts totally alien to most programmers, even OO was too foreign for some, but at least they understood it. So it was a good match for the average programmer then. Nowadays programmers come out of universities, or learn on their own with the millions of internet resources, and have a match better understanding of programming idioms, exposure to new ways to code, etc.

[k__]

Maybe inheritance just doesn't scale.

People start using it and it works fine. Then the codebase grows and everything gets unmanageable...