One thing I noticed is that the principle (better demonstrated in the linked matklad article) seems to make sense at the "a bunch of related functions" level, but it also goes against one of the main principles of OOP, which is not to prescribe behaviors to others.
You don't want to go "woof if you're a dog, meow if you're a cat", you want to go "make a sound, whoever you are". If you're a fish, you can no-op or not "accept" the call, depending on the language and convention. Obviously there is a lot of nuance, but the general idea is to push responsibilities and logic (which includes branching) down, to the level/entity/object that's best equipped to handle it.
If you apply this to the "a bunch of functions" example, you get low-level functions with branching, but you also get clean callers.
I feel like this isn't such a huge problem IRL, it's usually quite apparent where a decision should be made, but both of these "schools of thought" seem equally valid to me.
You don't want to go "woof if you're a dog, meow if you're a cat", you want to go "make a sound, whoever you are". If you're a fish, you can no-op or not "accept" the call, depending on the language and convention. Obviously there is a lot of nuance, but the general idea is to push responsibilities and logic (which includes branching) down, to the level/entity/object that's best equipped to handle it.
If you apply this to the "a bunch of functions" example, you get low-level functions with branching, but you also get clean callers.
I feel like this isn't such a huge problem IRL, it's usually quite apparent where a decision should be made, but both of these "schools of thought" seem equally valid to me.