3

So I was looking at Google's I/O App, iosched, and I notice they implement constants through a nested interface. For example in their ScheduleDatabase class they have:

public class ScheduleDatabase extends SQLiteOpenHelper {
    interface Tables {
        String BLOCKS = "blocks"
        String TRACKS = "tracks"
    }
}

But I have been reading online that it is poor java practice to create a interface to just store constants. But as you can see in the ScheduleDatabase class it kind of makes sense why they went with this approach. So I was wondering if this is also poor practice?

Hank
  • 3,367
  • 10
  • 48
  • 86
  • interface is final which makes efficiency in the os – Nicholas Jordan Nov 19 '11 at 06:01
  • Note that this may be a dupe of http://stackoverflow.com/questions/320588/interfaces-with-static-fields-in-java-for-sharing-constants although that discussion seems not to mention nested interfaces in particular. – kabuko Nov 19 '11 at 06:09
  • I read that one first, but like you said, it didn't mention nested interfaces, so I thought it might be different – Hank Nov 19 '11 at 06:56

2 Answers2

1

I think this is a coding style issue which is a matter of debate. On one hand you could argue that interfaces are for defining a contract between classes and these constants aren't really part of that contract (they're data), on the other you could argue that the encapsulation of these constants into a namespace is a good thing and organizes the code better.

I can't really say for sure whether this pattern is good or bad. If you have only a few constants then I'd say definitely don't use it, but if you have a bunch of constants which you can logically organize into groups then you could consider it. Certainly I'm more comfortable with the nested interface version of this pattern over the regular interface version.

kabuko
  • 36,028
  • 10
  • 80
  • 93
-1

you can read about anything on Java with some looking - not all of it is engineering

Nicholas Jordan
  • 638
  • 3
  • 6