aspose file tools*
The moose likes Blog around the Campfire and the fly likes My blog post: An Extensible FizzBuzz Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Other » Blog around the Campfire
Bookmark "My blog post: An Extensible FizzBuzz" Watch "My blog post: An Extensible FizzBuzz" New topic
Author

My blog post: An Extensible FizzBuzz

Scott Shipp
Ranch Hand

Joined: Mar 31, 2013
Posts: 133
    
    7

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/
Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3071
    
  33

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 | My Blog
Scott Shipp
Ranch Hand

Joined: Mar 31, 2013
Posts: 133
    
    7

That's elegant! Thanks Mohamed!
Scott Shipp
Ranch Hand

Joined: Mar 31, 2013
Posts: 133
    
    7

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!
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3611
    
  60

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.)
Ninad Kulkarni
Ranch Hand

Joined: Aug 31, 2007
Posts: 802

Hi All,
Nice discussion about Enum


SCJP 5.0 - JavaRanch FAQ - Java Beginners FAQ - SCJP FAQ - SCJP Mock Tests - Tutorial - JavaSE7 - JavaEE6 -Generics FAQ - JLS - JVM Spec - Java FAQs - Smart Questions
Scott Shipp
Ranch Hand

Joined: Mar 31, 2013
Posts: 133
    
    7

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.
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3611
    
  60

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).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: My blog post: An Extensible FizzBuzz