From: Joe E. <jo...@em...> - 2005-03-13 05:07:34
|
Hiroo Hayashi wrote: >Why Constants.java is a class not an interface? > >If it is an interface, we don't have to prefix with 'Constants.' for >every reference. If there is not a good reason, I propose to change it >to interface. > > Actually, I've been surprised at how little Constants is used. I'm sure that there are many more constant values being used in JSL that *could* be in Constants, but the class just hasn't been fully embraced. Right now... aren't there less than 10 values in there now? Since it doesn't seem to be being used at *the* central location for all constants, I'd be more in favor of splitting it up into module-level constants... like a set of constants for the the part that interacts with the synthdrivers, and one for the part that saves settings, etc. But that's not really on-topic with your question. I'm not really in favor of turning it into an interface because it would make the code more cryptic. Keep in mind that the programming.html advises new developers to "Spend some time looking through the driver code for other synthesizers and you'll basically pick it up by osmosis". If the source code is expected to substitute for an explanation of how to work with the API, then you need to keep the code in a format that can be read and easily figured out. When I see a class implementing interfaces, I use that as a cue as to how it is being used by the rest of the program. For example, if I see: class MyClass implements PatchEditor, NewPatchCreator, PatchMover, PatchBlender { then I would think that this class is being used to edit and move patches, blend patches with something, and create new patches. On the other hand, if I see class MyClass implements Constants { then I'm going to think that, somewhere, it must be defining methods that help it act like... uhhh... a "constant"... which would just confuse me. So, until there's a well-written "How to write a synthdriver" howto, then I'd vote against making Constants into an interface. - Joe |