Scott Shipp wrote:My blog post demonstrates applying an enum type in Java to the FizzBuzz problem, in order to make it more extensible. Code is provided and then explained for those who may not have experience with enum types in Java. You can read it at http://code.scottshipp.com/2013/05/29/an-extensible-fizzbuzz/
You can eliminate the switch in your enum and also the toString() implementation by providing state i.e label and divisor to the enum. Please look at the comment I left on your post.
Mohamed Sanaulla wrote:You can eliminate the switch in your enum and also the toString() implementation by providing state i.e label and divisor to the enum. Please look at the comment I left on your post.
Just wanted to note something, though. The .toString() is there to override what is already in the enum with a version that outputs the value in first-letter-capitalized format instead of all caps. If you were okay with "FIZZ" and so on printing out in all caps then you wouldn't even need it, either. Or, if you still made use of it in your version, you could avoid having to pass in "FIzz" to FIZZ and "FUZZ" to FUZZ and so on. The code would become like this:
I might like that implementation the best! Really appreciate the update with the constructor though! Cheers!
The isDivisible name is not well chosen, in my opinion. It reveals the implementation detail - that we test the numbers by division. If we rename it, we can implement the method in a more complicated manner. We can then add an enum that would apply to leap years in Gregorian calendar, for example. And it will also demonstrate overriding enum methods by enum values:
Note: passing 0 as parameter for the constructor of the LEAP value is not very nice; instead we could create a parameterless constructor to accomodate special values that override the appliesTo method. (Additionally, the name of the enum should start in uppercase. I've changed that.)
Hi Martin, I'm not following you. What do you mean by adding leap to the FizzBuzz enum? I am not grasping the relation it has with the FizzBuzz problem. It seems to violate the Single Responsibility Principle.
In my opinion, it depends on how you define responsibility in this case. We might certainly assume that the responsibility of the enum is just to define possible values, and that the testing whether an enum value applies to a number is another responsibility (and should be therefore contained in another class), but this goes against the ease of extensibility of the code - you need a separate class that knows about all enums, which is an unfortunate situation. My experience generally is that in real world (as opposed to the world of code examples carefully crafted for textbooks) striking the right balance between various design concerns is not easy.
The extension I've suggested goes clearly beyond the original FizzBuzz challenge. But it depends on how much are you going to generalize the original problem. Assuming that the tests can be done by some other operation than the plain modulo comes up quite naturally to me. At the same time, the work needed to accommodate such possibility is minimal (just rename one method).