> E.g. preferring inheritance over switch is less readable.
Surely this depends on the context? If you have a many different classes it tend to lead to cleaner code if you encapsulate the class-specific logic with the class definition rather than intermingled in multiple giant switch statements. In particular you can add new classes without making the rest of the code more complex.
Of course there are cases where a switch is the right choice.
Switch statements don't have to be giant. Hint: you can still extract each branch to a separate function / module. But what is more readable about them is the control flow: the condition is explicit and all targets are easy to find. A codebase using switches/ifs and function calls can be easily navigated with ctrl-click in most IDEs. A codebase relying heavily on interfaces and inheritance cannot.
If you aren't going to use polymorphism to vary behavior, but depend on conditionals, what do you use classes for? Just for hierarchical data encapsulation?
So, you’ve been arguing for using switch statements, instead of Clean Code’s suggestion of using object-oriented polymorphism, in a context where polymorphism doesn’t exist?
Not at all. Not having classes is not the same as not having polymorphism. Rust supports polymorphism just fine (and one could argue its support for polymorphism is actually much more advanced than that of Java's; but that's not enough reason to use it everywhere).
They don’t only contain data though, you can define methods as you said. Yes, there is no-inheritance, but they contain data, maintain state, and allow for defined methods. 90% of the time people are talking about classes, they are talking about that.
If we talk about readability - it is hard to think of a situation when inheritance would be better - it adds an indirection, it hides what's really going on, and at the end of the day the code is also longer and more complex.
However it has some other uses, e.g. when you really want to support adding new cases without modifying the code, e.g when doing a library, you need some kind of polymorphism.
So basically - it is not that abstractions/indirections are inherently bad, but they come at a cognitive cost. And it depends on the context if this cost is justifiable.
Yes, it depends on the context. In this case the context is the switch statement described in the https://www.computerenhance.com/p/clean-code-horrible-perfor.... Too bad TFA never mentions it explicitly (other than in the title and in the video). Recently it generated a heated discussion around here.
Surely this depends on the context? If you have a many different classes it tend to lead to cleaner code if you encapsulate the class-specific logic with the class definition rather than intermingled in multiple giant switch statements. In particular you can add new classes without making the rest of the code more complex.
Of course there are cases where a switch is the right choice.