Timeline for Is "static interface" a good practice?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 8, 2017 at 2:41 | comment | added | JimmyJames | @StijndeWitt This wouldn't be the worst thing but you can use an enum or nested class on the interface for this purpose. The real issue is using this to bring statics into the scope of many classes through inheritance. That approach is plainly inferior to using static imports. | |
| Jan 7, 2017 at 22:45 | comment | added | Stijn de Witt | I can see value in constants on interfaces. Interfaces tend to define methods and methods sometimes accept constants as parameters. E.g: interface ColorFilter {Image applyGradient(int colorSpace, int width, byte[] pixels); }. I can imagine there being some different constants RGB, RGBA, CMYK, GREYSCALE, INDEXED etc. | |
| Dec 17, 2016 at 1:53 | comment | added | JimmyJames | @Vlasec Right but there's no need to do this on an interface. The only difference between doing this with a class and an interface is that you can inherit from more than one interface. The standard practice for a utility class like this is to make the constructor private to prevent instantiation or extension. There's no benefit to doing this in an interface over a class. It simply opens the door for misuse. | |
| Dec 17, 2016 at 0:54 | comment | added | Vlasec | Yes, static imports sound like a better idea than inheritance of constants and it works that works with static members of both classes and interfaces. And it is visible inside the class/interface only. | |
| Dec 16, 2016 at 18:56 | history | answered | JimmyJames | CC BY-SA 3.0 |