Just found this 4-year-old video which can be very instructive : Misko Hevery fights against if/switch statements using object oriented techniques to remove them.
If you have read my previous articles, or know me personally, you must know that the one kind of bad code I hate the most is if-else trees. In the first article of this weblog, I talked about if-else trees in general, exposing some general ideas about how to avoid them, remove them from the code or why they are bad, describing them as a code smell.
Today, as I have just finished writing a series of articles in French about the SOLID principles, I am going to focus on the maintainability aspect of if-else trees, and make them fight against two of the SOLID principles: the Single Responsibility Principle and the Open/Closed Principle. This will allow me to introduce some important rules to know about if-else trees. Continue reading if-else trees vs SOLID principles
On peut constater que la plupart des développeurs qui utilisent quotidiennement la programmation orientée objet connaissent généralement non seulement ses grands principes (interfaces, classes, héritage, polymorphisme, etc.) mais aussi une ribambelle de design patterns qu’ils essaient de placer un peu partout, sans forcément en connaître les subtilités. Continue reading SOLID – Introduction
A code smell is a hint, a clue which indicates that a potential problem is hidden somewhere in the code. Some of them are well-known by every developer, like too long identifiers, too short identifiers, duplicated code, too many parameters, dead code, etc.
Today, I’m going to tell you about a particular code smell that I recently had to fight against. Failing to find an official term, I will simply call it the if-else tree. Continue reading smell of if