I would controversially add,

- don't use interfaces until you absolutely have to, and then try and find another way.

YMMV, but in my corporate experience with OO code, I find a lot of interfaces that have one implementation. It's a waste to plan for a future that doesn't come.

I feel we're lacking something like software mindfulness. Where you stay in the moment and just solve the problem.

It depends what language you’re in. As long as you can use fakes, it doesn’t matter if you use interfaces or not. In C#, implementations are sealed by default so faking them is not feasible unless you make the function virtual.

I find myself making object abstractions more in languages that do not have solid support for functional programming. In OCaml, I can build dozens of useful abstractions off of a handful of small functions by using currying and partial application. Equaling that expressivity in languages that don't support those features requires making objects more often than I would like to, because the alternative is hundreds of overspecialized utility functions that do not compose well and push you towards imperative, stateful styles (I have seen this happen!).

I still stick to two levels of inheritance max though, and most of the time I only use interface inheritance. Rarely do I want behavior inherited.

As Jon Skeet put it best, "be pragmatic, not dogmatic".

I also love YAGNI - You Ain't Gonna Need It!

Purely functional style can be quite difficult to read. Especially when you end up composing functions be partially filling arguments, sending functions as arguments of other functions and so on.

Once you get at that level, objects are life savers. Because then state is explicit on code rather then hidden in deep call stack and spread over various levels of it.

The problem with "when all you need is a function don't use an object" is that's it's a recursive definition.

There are people who think they need a singleton all the time, imagine where similar definition would have brought them.

How a function is defined varies from language to language, but if we're talking about a globally accessible named function, this is in effect a singleton.

It means you can't configure this function (through construction parameters), or replace it, or mock it, etc. it's in effect a "singleton function".

BTW, abstraction != inheritance.

+1 for more compositions, just need to manage cyclomatic complexity. Have seen some mind bendingly overcomplicated code where A is in B and B is in A etc.