I feel sure that the SOLID principles belong in the “helps people who already expert at doing SOLID things, harms everyone else” category.
My SOLID principal has been to “avoid OOP”. People sometimes make fun of haskell for requiring too much theory but I find that OOP requires the same level of theory to not create a foot-gun. But at least with haskell, I have something more like algebra than UML.
For the most part, i’m preferring procedural style C++ because it’s easy to design, easy to test, fast to read, and document. Too much abstraction can hurt quite a lot and so many times OOP actually ends up complicating things more than it brings any advantage.
What I’ve been slowly discovering is that OOP also requires too much theory, but internalising that theory lets me avoid all the incidental complexity that built up around OOP during the Software Engineering times. Don’t give me Java. Give me a vtable, a lookup primitive, a delegate primitive, a selector type and an object type, and I can build the OOP system I need without having to contort my design to fit the OOP system you/Sun/AT&T provided.
“Give me a vtable, a lookup primitive, a delegate primitive, a selector type and an object type, and I can build the OOP system I need without having to contort my design to fit the OOP system you/Sun/AT&T provided.”
I like the simplicity of your summary. Everything except a selector type looks familiar. What’s that?
some kind of interned symbol type, like a Ruby/Smalltalk/LISP symbol or an objc selector.
It’s meant to be “one thing” at the current level of abstraction, right? Which is totally subjective, but this is a design principle, so it can’t help but be fuzzy.