Hacker News Reader

Comment by pkolaczk | Hacker News Reader

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.

View on HN

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?

Afaik, data-oriented approach doesn't use classes to encapsulate behavior.

Surprise: I don't use classes. Rust doesn't have them. :P

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).

The greatest trick OOP ever pulled was convincing the world that polymorphism didn't exist outside OOP.

I use multiple languages and I always consider the context of programming advice. I recommend a broadened perspective.

In general I would rather maintain code by someone who have read Clean Code than by someone who considers it beneath them because they are too elite.

How are structs in Rust any different than classes?

Behavior and data is more separated

A struct only contains data, however you e.g. can define methods on it or implement traits for it No inheritance.

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.

So you are saying context doesn't matter, switch is always better?

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.

Reply on news.ycombinator.com