"The Clean Code Talks -- Inheritance, Polymorphism, & Testing"
Why Hacker News recommends it
HN commenters recommend it as a thorough treatment of replacing conditionals with polymorphism and why flags and deep ifs can be code smells.
What it is
Misko Hevery's Clean Code Talk shows how to use object-oriented techniques such as polymorphism to remove repeated if and switch statements. The result is code that is easier to test, understand and maintain.
Recommended by 3 HN commenters across 3 different months, 2009 to 2023.
What Hacker News said
Recommends derwiki · 2009-09 · on “Using Polymorphism instead of conditionals when programming”
Google posted a tech talk about this a while ago: [this video] which is more comprehensive than the posted article.
Recommends VBprogrammer · 2010-06 · on “Criminal Overengineering”
I completely disagree with the example given in this blog. I don't have time to give a full explaination but I believe the google clean code talks gives a far better arguement than I ever could. On the general principle I agree that overengineering is to be avoided, but I actually think the example shows a clear disregard for Object Orientated principles. [this video]
Recommends Mr_P · 2022-05 · on “Flags Are a Code Smell (2014)”
It's not so much the existence of the flag, itself, but rather using an if-statement at the deepest-level of the call stack to conditionally modify behavior. This talk gives a great overview of why boolean flags (rather, if-statements) can be a code smell: [this video] OP's blogpost advocates for data-oriented design (e.g. Entity Component Systems) as a mechanism for avoiding this, whereas the talk I've linked advocates for OOP. Both mechanisms are equally valid (imho) and are inline with widely-adopted industry practices for software architecture.
Cites wcoenen · 2013-02 · on “How A Pull Request Rocked My World”
This google tech talk is basically about the same thing, eliminating conditionals with polymorphism: [this video]
Cites efraim · 2016-06 · on “Anti-if: The Missing Patterns”
Misko Hevery did a Google Tech Talk about this some years ago, he also use a very similar example with switching on the birds. [this video]
Cites tacitusarc · 2023-11 · on “Push ifs up and fors down”
I think this is actually a great example of why `if` should be "pushed up." The objective of the code is to perform an particular operation on the walrus, given a condition. The is actually ifs being instead of polymorphism and a type system. Why does the walrus have these two functions, which must be called in different scenarios? Why not have a single function, and two types, and the correct type is passed in? Even given the current structure, we could accomplish this: // There are better ways to accomplish this, depending on the language func frobnicate(walrus) { return walrus.frobnicate(); } func transmogrify(walrus) { return walrus.transmogrify(); } // Somewhere high in the code if cond