A pile of if statements is a direct model of business deal making, which is literally a pile of if statements.

Sales contracts with weird conditions and odd packaging and contingencies? Pile of if statements.

The other great model for business logic is a spreadsheet, which is well modeled by SQL which is a superset of spreadsheet functionality.

So piles of if’s and SQL. Yeah.

Elegant functional or OOP models are usually too rigid unless they are scaffolding to make piles of conditions and relational queries easier to run.

> So piles of if’s and SQL.

One would imagine by now we would have some incredibly readable logical language to use with the SQL on that context...

But instead we have people complaining that SQL is too foreign and insisting we beat it down until it becomes OOP.

To be fair, creating that language is really hard. But then, everybody seems to be focusing on destroying things more, not on constructing a good ecosystem.

But even with OOP... Virtual functions take over the pile of ifs, and so the ifs move to where you instantiate the class that has the virtual functions. (There is some improvement, though - one class can have many virtual functions, so you can replace all the ifs that ask the same question with one if that creates a class with all the right virtual functions. It gets messier if your class has to be virtual against more than one question.)

You usually don't want your code logic to stray from the mental or domain model of business stakeholders. Usually when my code makes assumptions to unify things or make elegant hierarchies, I find myself in a very bad place when stakeholders later make decisions that flip everything and make all my assumptions in the code base structure fall apart.