Can you elaborate on your shallow dismissal?
- There are many many languages without classes that make good use of enums
- Doing this refactoring is excessively verbose
- Someone making bold claims like this about a language feature that's never been considered error prone and been around since the beginning ought to provide some really good evidence to back things up.
There's cases where enums are good, and there's cases where polymorphic classes are good. Dismissing one of them by default is wrong, since both are useful at different times.
edit: and the citation there to Martin Fowler et al., Refactoring: Improving the Design of Existing Code doesn't even match the claim being made. That book mentions
- "The first part of this problem is that switch statement. It is a bad idea to do a switch based on an attribute of another object. If you must use a switch statement, it should be on your own data, not on someone else's." -- sure, I agree
- "Often you find the same switch statement scattered about a program in different places. If you add a new clause to the switch, you have to find all these switch, statements and change them. The object-oriented notion of polymorphism gives you an elegant way to deal with this problem." -- fair enough
This is a long way from "enums are a code smell," and honestly feels like padding the citation count. Another thing to note is that the second edition of Refactoring: Improving the Design of Existing Code says:
> Even in our more wild-eyed youth, we were never unconditionally opposed to the conditional. Indeed, the first edition of this book had a smell entitled “switch statements.” The smell was there because in the late 90’s we found polymorphism sadly underappreciated, and saw benefit in getting people to switch over.
> These days there is more polymorphism about, and it isn’t the simple red flag that it often was fifteen years ago.
Even that seems like it could easily be way overkill e.g. if you have multiple switches which, say, generate a label from an enum, the first step is probably to add a utility function / method, not to migrate the whole thing over to polymorphism.
Although there is one thing to be said about context:
* OP works in C#, whose enums are literally useless (they’re like C’s)
* apparently even in Java (which at least has type-safe enums even if not sum types), `switch` is unable to check for completeness
So when you have an enum-typed value, odds are good that it’s one of the named ones but there’s no mechanism anywhere preventing it to be any other integer of the underlying type.
Any caller can send any garbage (if you're publishing a package / API), likewise a dependency can return any garbage, etc... C#'s enums are entirely indicative.
Which, in my experience is a huge advantage rather than the supposed disadvantage Fowler is saying it is (although I could see that being the case in many other languages).
originally the meaning of code smell was not that code that had the smell was bad, but there was a chance it was and should be examined. For this reason of course it is useful to get rid of code smells so that people don't feel the need to investigate hey is this smelly code actually bad code.
But all that said not sure if an enum is a code smell.
on edit: this at any rate was the rationale behind the phrase code smell I was first introduced to.
In contrast, an alternative like polymorphism + a visitor is safe, but excruciatingly verbose and hard to follow and modify.
Sometimes these polymorphic classes make sense, but my experience is that it’s a minority, and it’s better to err on the side of some simple enums.
Also note that Uncle Bob in Clean Code pretty much directly opposes in one of the chapters about logic and data separation (can’t find the chapter right now since I don’t have the book anymore)
Enums are essentially categorical variables, and there is nothing wrong with that: they are widely used in statistics and other real-world applications (arguably, even, booleans are a case of such.)
As a junior programmer, I was once assigned to work on an example of what could happen as a result of following this advice: an explosion of subclasses for the sake of avoiding a few conditional clauses. Algorithms had been broken up so that the common parts could be put in base classes, and you had to jump all around the code to see what was going on. Worse, objects could change their categorization during their lifetime, which required the substitution of a new object for the previous one. This complexity was contagious; once this one type was implemented in this manner, a lot of other things had to follow suit.
This was one of the experiences that turned me into a skeptic with regard to the proposition that there's no problem that cannot be simply solved by being more object-oriented.
Either you end up with 'scary' enums, or with dynamic_cast and 'scary' null pointers.