Composition vs Inheritance. Why not simply stick with Composition?

[rocky oak]

From what I've learned so far, Inheritance is the lesser of the two by a far margin. Composition is flexable, scalable and you can make changes without collapsing an entire tree. I understand you may want to prevent other people from potentially removing vital code, but it also means that if a BETTER way of doing something is found, you're already locked in, and now have a potential monster task of rebuilding the inheritance hierarchy. Better hope there was good documentation or you're in for a lot of debugging. (Depending on the scale of the program.)

TLDR: Before I build a potentially bad habit, is it better to use encapsulation paired with composition over using inheritance? My primary argument is future proofing.

[weary scroll]

Composition is nice but sometimes you have to go for inheritance

[rocky oak]

My whole post got thanos snapped I see. My original argument is that Composition is flexable, scalable, and futureproof. Inheritance has solid logic as to why it exists, but is also a potential pain to change or upgrade if better ways to do a thing are found, and that mountain of inheritance hierarchy is looming before you. With composition, you can change and upgrade far more flexibly.

[weary scroll]

Like if you want to implement a web browser you'll probably end up hating yourself by the time you have the HTML elements implemented

Just because the spec makes HEAVY use of OOP concepts like inheritance

[tacit patio]

They’re two different things. Use inheritance when B is an A, use composition when B has an A.

A dog is an animal

A car has an engine

The issues with inheritance come from over use and poor implementation

[rocky oak]

Would it be safer for me, as a newbie, to lean more towards Composition? I like the idea of "You can change your mind later and make it better."

[tacit patio]

That’s a misnomer that classes make changes harder to implement. Don’t over use inheritance and make sure when you’re inheriting that B is actually a sub type of A. If it’s a forced relationship it will make your life harder.

Inheritance allows you to share behavior (functions) across different objects. It also allows you to change that behavior, which composition does not allow you to do. So you can’t substitute inheritance for composition in all cases

The only time I use inheritance is when I have a bunch of objects that need to share behaviors but change some of those behaviors

[tacit patio]

Many inheritance in that first sentence not classes

[rocky oak]

That makes sense. There are only sometimes cases where I'm unsure if, for example, A is a B, or if B is a A (Which should come first) and then if A is a B, and C is a B but not a A, the ladder kind of falls apart.

I suppose It will come with experience? I will try to find out how to implement the hierarchy trees instead of avoiding them.

[tacit patio]

If you have a C that’s a B but not an A then probably B is overly complicated and should be two classes

[rocky oak]

Note to self: break classes apart when complicated.