OOP is too vague, let's talk about related features which are clear. (To me the 2 most important are inheritance and mutability, I won't mention that "protected

OOP is too vague, let's talk about related features which are clear. (To me the 2 most important are inheritance and mutability, I won't mention that "protected" magic at all.) Inheritance has too easy syntax to avoid "accidental duplication" (pieces of code seem similar on short term but eventually differ on the long run) without creating a new common abstraction to depend on: even before realizing the introduced dependencies are unnecessary but now even deeply entangled. Because in its core what might just happened is "raw" code(text) reuse instead abstraction reuse. "Code duplication is better than wrong abstraction." Or "Write code what is easy to delete." You might keep adding and adding until you won't be able to substract, because you have to check every dependency back and forth, and there are no layers of abstractions but a constant change of [meaning] with the hope of usefulness in future infinite far away. Additionally intermediate level classes also need names (and meaning...) which makes the naming problem constant and might even blur the clear lines between the originally clear abstractions. The language of our system/domain consists of the relation of individual abstractions, we can't just overload every word and/or litter with unnecessary ones. It's also a question to decide when to write a class and instantiate instead of just using an adhoc "anonymous" object and use a necessary pattern like factory function or some delegation (like parent class) later if needed. (Ofc. classes might be created later as well, but weird enough it goes the other way around in my xp, maybe its just me, ruined by noob Java 1.6/C# habits gained at the first years of university). It's too easy to find wrong abstractions with inheritance, too easy to blur good ones, and too hard/exhausting to delete them. Reflection on the thread: I think I'll focus more on the proper naming of functions "DO"s instead of "WHAT"s, because DOs must have clear intent to drive the design/architecture.