Currently, there are only 3 possible publishers. I might want to add some more in the future:

interface NewsArticle {
    enum Publisher { NYPost, ChiTribune, LATimes }

    Publisher getPublisher();

I like the rigidity of using enum, but when might I get tripped-up if I treat the publisher as an enum instead of a String?

  • 4
    That shouldn't be an enum. Adding a publisher requires you to recompile the application. – Robert Harvey Feb 11 '16 at 21:14
  • We would need to know your choice of language and build construction for a complete answer. In some environments, recompiling your app is fine, in others, it is not good at all. Still, you should explain why you want to getPublisher() -- this seems like a code smell to me. What might you do with that information?? – Erik Eidt Feb 12 '16 at 1:57
  • @ErikEidt I am writing in Java. I've got a database of news articles from which I create objects with these attributes: (1) title, (2) story, (3) publish date, (4) publisher. To reduce errors, I want to be as restrictive as possible. But, I will add more publishers in the future so I need some flexibility. – konishiki Feb 12 '16 at 3:14
  • There should be a publisher class from which you make different publisher objects. Don't use a datarow in a database as if it were an object with properties. – Pieter B Feb 12 '16 at 12:42
  • @PieterB that model is so awesome. I mean, that is how it works in the real world, right? My design was really starting to head down a dark path... – konishiki Feb 12 '16 at 14:03

There shouldn't generally be a need to rebuild an application when new data is introduced. If there's no need to define and implement any publisher related logic every time a new Publisher is introduced, then enum is a wrong choice.

Where exactly in your application you need to refer to a certain Publisher? Do you have some logic that's bound to the Publisher in your application? Like

if (article.getPublisher().equals(Publisher.NYPost) {

Do you have any such references? If you don't have any, then you shouldn't have a hard coded set of Publishers, as an enum or otherwise.

I like the rigidity of using enum, but when might I get tripped-up if I treat the publisher as an enum instead of a String?

How about a Publisher class that's not an enum?

public class Publisher {
    private final int id;
    private final String name; // perhaps?

That would give you more rigidity than a String without being limited to only some hard coded predefined publishers. First, you would be able to control the creation, the validity and the use of Publishers. Second you would have the type safety: you wouldn't be able to pass or return a random String as a Publisher. Third, you could read a predefined set of Publishers from a database or from a configuration file, whatever is preferred:

public class PublisherRepository {
    public List<Publisher> getAllPublishers() {
         // read publishers from db or config file

Of course you could even have your PublisherRepository return a hard coded list of Publishers at first. Changing a properly structured hard coded solution wouldn't be as difficult as replacing an enum.


A possible hack would be to use a "dynamic enum", which is non-standard. You read possible values from a file a load time. So it's "only" editing a text file, not recompiling. e.g.


I have no experience with these things so caveat emptor. Probably not worth the effort but YMMV.

  • 2
    You've lost compile time safety (one of the points for enums) and this is very language (and runtime) dependent as it involves picking apart the private of the class if it is tweaking the Enum. This particular implementation, however, isn't actually an Enum and thus fails at being useable for EnumSet and EnumMap - two of the very good reasons to use an Enum in Java. – user40980 Feb 11 '16 at 21:49
  • @MichaelT all excellent points, they make this hack even less useful. (I upvoted your comment). Like I said, I would probably not do this myself. – user949300 Feb 11 '16 at 21:52
  • I will also point out the flip side of this (if one doesn't try to pretend that this is an enum) and create some objects based on a property file that are accessible via some method. The creation of the objects would be limited to that method (so the code can't go about and create new instances of this class behind the back of other things. But don't try to pretend that it is an enum. It isn't bad if you're not trying to confuse people about what it is and implementing a too rigid interface. – user40980 Feb 11 '16 at 21:58
  • If you want to do evil and wrong things to your java code: javaspecialists.eu/archive/Issue161.html – user40980 Feb 12 '16 at 15:40

As per the comment from Robert Harvey:

That shouldn't be an enum. Adding a publisher requires you to recompile the application.

that is all I need to know.

  • But how often do you ACTUALLY need to add a publisher? If its not actually frequent, then its perfectly fine to lock it into an enum. – Graham Feb 12 '16 at 16:38
  • @Graham I don't know when / if I'll add a publisher. Now there are 4. Maybe I'll get up to 8. Or, maybe I won't add any. – konishiki Feb 12 '16 at 19:31
  • If you do not have a real requirement on the near horizon to add a new publisher, then I would consider it a (minor) violation of the YAGNI principle to structure the publisher code as if you need to change it frequently/smoothly at the expense of ease of coding. If I had a dime for every time I've heard a teammate say "hey I spent some extra time making this configurable!" for features that were NEVER/RARELY actually changed later on, I'd be a rich man. – Graham Feb 15 '16 at 13:41

There are only two ways:

One is to use external source such as files or databases and the second is recompiling.

It makes no difference if it is a String or Enum if the options reside in the code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.