One of the worst dev constructs I've ever seen are `final` classes. Both devs who added it to the language and library authors implementing it aren't gonna die well. Why even bother with oop if your shit classes shouldn't be extended for programmatic use? Psalm is the worst. Today, it was Symfony. Just realised I have to hard-couple to their clown mailer interface instead of my adapter cos I can't mock it. Why do you think your code is so flawless that nobody can ever improve or tweak it? Or use it outside the precise way you envisaged? Such hubris

The thing is, OOP was never good for fixing/improving/extending lib code. Yes, it’s been advertised in schools as being great for that. But it’s all theoretical bullshit.
"final" is just one of the many symptoms that hints at this.

Instead, we should embrace composition over inheritance.
Give users of your lib the ability to make own components (not subclasses) and to swap them for the lib's default ones.

It took me some time to learn this and get used to it after decades of OOP indoctrination.

I’m not saying OOP is bad in general. Use it as a tool which is not always the right one for every job.

Classes with internal state and behavior are hard to impossible to extend without leaking internal knowledge (information hiding).

Me as a provider for libraries are quite happy that I can change implementation details of such classes without taking care of backward compatibility etc.

Oh man I share this so much

Which is weird cause I like Rust which is basically this x100 (except for traits which basically act like extension classes -- they are great!)

Sometimes you just want to damn change a little teeny tiny bit of the logic but *no* you're not allowed to because fuck you

Okay guess I'll have to fork the library I guess... sigh

@Lensflare both concepts have their place. Composition is advised when you're using the dependency to achieve a goal. Extension is different. Here, you need to REPLACE a part of their implementation. Composition doesn't give you that. You can want to replace an interface binding. Or mock something. Or replace a specific method implementation while retaining flow. Like building around the base implementation and supplying that to something expecting that type. Composition is disruptive in these cases cause it solves a different problem altogether, usually in userland. Building for devs and not being able to extend makes the library completely worthless

Extension leaves all options open. That's why protected keyword exists. Locking things just clips the wings of the next guy, drawing a hard limit to what's possible. That kind of shortsighted constriction is very wrong