A good architect would add a linter with a cyclomatic complexity check that fails the build. There's always a way to avoid these hideous nested else ifs. Code review is helpful here to train people who don't understand some of the various abstractions to avoid this such as polymorphism. This is also the code that has high value for unit tests.
Not saying rules encoded in "if-elses" are good, but they can put all the rules in one location. Polymorphism can spread those rules out in somewhat obscure ways. I use both, depending on what I want to do.
Right, I wasn't saying polymorphism was the only solution. I was saying deeply nested if elses are hard to maintain. There's many solutions to avoid them. So I think we agree, use what makes sense given the context.
> multiple if-elses encoding the business rules
A good architect would add a linter with a cyclomatic complexity check that fails the build. There's always a way to avoid these hideous nested else ifs. Code review is helpful here to train people who don't understand some of the various abstractions to avoid this such as polymorphism. This is also the code that has high value for unit tests.