Is if-then-else now considered to be as obsolete as goto?
-
This article purports that if-then-else branching should be done via polymorphism: https://levelup.gitconnected.com/if-else-is-a-poor-mans-polymorphism-ab0b333b7265[^]
Quote:
The traditional approach to branching using if-else and switch is obsolete. It’s not SOLID. It’s not flexible. It’s just horrific.
-
This article purports that if-then-else branching should be done via polymorphism: https://levelup.gitconnected.com/if-else-is-a-poor-mans-polymorphism-ab0b333b7265[^]
Quote:
The traditional approach to branching using if-else and switch is obsolete. It’s not SOLID. It’s not flexible. It’s just horrific.
-
This article purports that if-then-else branching should be done via polymorphism: https://levelup.gitconnected.com/if-else-is-a-poor-mans-polymorphism-ab0b333b7265[^]
Quote:
The traditional approach to branching using if-else and switch is obsolete. It’s not SOLID. It’s not flexible. It’s just horrific.
-
This article purports that if-then-else branching should be done via polymorphism: https://levelup.gitconnected.com/if-else-is-a-poor-mans-polymorphism-ab0b333b7265[^]
Quote:
The traditional approach to branching using if-else and switch is obsolete. It’s not SOLID. It’s not flexible. It’s just horrific.
Poorly considered, but it fits well within the current software engineering zeitgeist, so it makes sense that it would get written. That's the fancy way to say: "it's a fad, don't worry about it". And stop reading Uncle Bob. - "it's not flexible", not if you consider adding an extra case to be a Big Deal, but the alternative is adding an *entire new class*. - Even if you are of the opinion that creating new classes is somehow easier than creating new cases, then spend a little time thinking about what would happen when the function signature of that virtual function is changed, or if something about the API used by the subclasses to implement themselves changes. This has the annoying property that the fix you're about to write is highly non-local, you'd have to "hunt down" all the places that need to change - in the *best case* they correspond to compile errors. - If a requirement is broken into N cases, but the code is spread out non-locally over N classes, your code does not look like the requirement which makes it harder to check whether it matches. - "it's not SOLID", maybe, but SOLID is subjective and overrated. - "horrific", let's not even talk about it. - The presented "better way" presupposes that we have a convenient instance of the "class that represents a particular reason". How did we get that? Chances are that there's a switch hiding in a factory pattern or something. Moving the problem. And if there is some pattern such as `new AddressChanged().Update()`, how about we don't wrap it in a class and just call a method that does that. - Article forgets to point out that in the first place the only domain that was considered is the business logic domain. Even if it makes sense there (which I don't agree with either), it won't make sense anywhere else. There's no way `Math.Min` would have its `if` replaced by polymorphism.
-
This article purports that if-then-else branching should be done via polymorphism: https://levelup.gitconnected.com/if-else-is-a-poor-mans-polymorphism-ab0b333b7265[^]
Quote:
The traditional approach to branching using if-else and switch is obsolete. It’s not SOLID. It’s not flexible. It’s just horrific.
swampwiz wrote:
This article purports
First of course writers have different goals than programmers. Always keep that in mind when reading postings on the web. From the link "New requirements come along. Who would have thought? You were so sure nothing would happen" Wrong, wrong, wrong. Attempting to write code in case something might happen is a sure way to lead to code that is difficult to maintain. If you already have requirements, even if it is just from a whiteboard, then your design and implementation should, of course, take that into account. But if you are claiming that you are writing your code to make it easy to add requirements that are unknown then you are at least ignorant of the challenges of maintaining legacy code. Especially if your claim is for something that might happen far in the future. What actually ends up happening with that hubris is that code must be maintained for years or decades despite the fact that it serves no purpose. The complexity actually makes it harder, not easier, to add new features because it is more complex. The best you can do now for such future possibilities is to write code that is easy to understand. And to make it clear how the code that you wrote now meets the requirements that you have now. Then that programmer 10 years from now who must add a feature that is actually needed then, will at least be able to understand what your code actually is doing and very likely needs to continue to do even with the new feature in place.
-
swampwiz wrote:
This article purports
First of course writers have different goals than programmers. Always keep that in mind when reading postings on the web. From the link "New requirements come along. Who would have thought? You were so sure nothing would happen" Wrong, wrong, wrong. Attempting to write code in case something might happen is a sure way to lead to code that is difficult to maintain. If you already have requirements, even if it is just from a whiteboard, then your design and implementation should, of course, take that into account. But if you are claiming that you are writing your code to make it easy to add requirements that are unknown then you are at least ignorant of the challenges of maintaining legacy code. Especially if your claim is for something that might happen far in the future. What actually ends up happening with that hubris is that code must be maintained for years or decades despite the fact that it serves no purpose. The complexity actually makes it harder, not easier, to add new features because it is more complex. The best you can do now for such future possibilities is to write code that is easy to understand. And to make it clear how the code that you wrote now meets the requirements that you have now. Then that programmer 10 years from now who must add a feature that is actually needed then, will at least be able to understand what your code actually is doing and very likely needs to continue to do even with the new feature in place.
A keyword won't replace another. Because of amount of 'features' available as new langages arrive. Think from the core : Assembly ( or C ), you can renew an adress , or the value, or call an adress, or a value, so goto: leads to another 'adress' , It's go there/ do that .... If statements are 'condition tests' area , you want to upgrade your style with a relevant idea, throwing out the 'overload of logical' and the point is here : renew the keywords you use. Like you'll have already your idea about the 'How To' : one essential thing to get clues for relevance : measure / benchmarck / tests / and finally Compare your tries. There are lots of 'equality' , if ( Evt 1 ){ ........... }{ .... } so it's like : while( Evt 1 ){ .............. } while( ! Evt 1 ){ .............. } will succeed same .. and commit the following . It's about 'How many laps in loop' 'How many conditions to evaluate', ( or maybe a " loop/if handler " is required ) A code could use if() .. or other manner.. But in a very short and relevant time and process consumming ? or for one hour over required work time ? ////////// It's really 'one case' won't solve this questions', benchmark will do ! benchmark will prove your choice as the best one. There will never have deprecated keywords.
-
A keyword won't replace another. Because of amount of 'features' available as new langages arrive. Think from the core : Assembly ( or C ), you can renew an adress , or the value, or call an adress, or a value, so goto: leads to another 'adress' , It's go there/ do that .... If statements are 'condition tests' area , you want to upgrade your style with a relevant idea, throwing out the 'overload of logical' and the point is here : renew the keywords you use. Like you'll have already your idea about the 'How To' : one essential thing to get clues for relevance : measure / benchmarck / tests / and finally Compare your tries. There are lots of 'equality' , if ( Evt 1 ){ ........... }{ .... } so it's like : while( Evt 1 ){ .............. } while( ! Evt 1 ){ .............. } will succeed same .. and commit the following . It's about 'How many laps in loop' 'How many conditions to evaluate', ( or maybe a " loop/if handler " is required ) A code could use if() .. or other manner.. But in a very short and relevant time and process consumming ? or for one hour over required work time ? ////////// It's really 'one case' won't solve this questions', benchmark will do ! benchmark will prove your choice as the best one. There will never have deprecated keywords.
-
This article purports that if-then-else branching should be done via polymorphism: https://levelup.gitconnected.com/if-else-is-a-poor-mans-polymorphism-ab0b333b7265[^]
Quote:
The traditional approach to branching using if-else and switch is obsolete. It’s not SOLID. It’s not flexible. It’s just horrific.
I wouldn't label if statement as obsolete but I found dynamic polymorphism (hidden by the facade of SOLID mnemonic) pretty convenient thing in order for all OOD keywords to find their place. And indeed before entering the thread my guess was that author will make the case that if.. else.. violates the open-closed principle. And my guess was right. Although if I were the author I'd avoid such words as terrible, horrific etc