James Taylor <[EMAIL PROTECTED]> writes: > On Thu, 2002-04-11 at 04:26, Daniel Rall wrote: >> I've seen it mentioned numerous times as a good pattern (just do a >> Google search on), and have repeatedly used it effectively myself. > > Lots of people definitely like it and use it. It is a very effective > pattern, but:
Thanks for the citation, James, I was wondering where all the "anti constants-in-interface" sentiment was coming from. :) > "The constant interface pattern is a poor use of interfaces. That a > class uses some constants internally is an implementation detail. > Implementing a constant interface causes this implementation detail to > leak into the class's exported API. This is a load of shit. (It doesn't consider all the use cases and ignores some fundamental concepts.) Constants denoting state are an intrinsic part of an interface. In UML, you'd represent them using methods which return a constant value -- effectively, the same thing. On the flip side, the argument that _implementation_ constants do not belong in an interface is more a matter of style and common sense than any hard and fast rule. The following comments about API pollution ring true if the public nature of constants in an interface is ignored by the author, but I can only respond with the following age-old adage: [patient] "Doctor, it hurts when I do that..." [doctor] "So don't do that." If a constant shouldn't be public, don't put it in an interface. If a constant is public and implementation-centric, ther are larger coupling problems with the software than the resulting API pollution. "Effective Java" blurs cause and effect to provide an easy to follow guideline which is no doubt very effective in many shops. > It is of no consequence to the users of a class that the class > implements a constant interface. Worse, it represents a commitment: > if in a future release the class is modified so that in no longer > needs the constants, it still must implement the interface to ensure > binary compatibility. If a nonfinal class implements a constant > interface, all of its subclasses will have their namespaces polluted > by the constants of the interface" (Effective Java, p.89). I like constants in interfaces because said interfaces cannot be directly instantiated (also doable via an abstract class or private constructor), and provide the facility of implementation as a convenience for accessing the constants. The latter is especially useful when the constants are not implementation-centric (such as state constants), making them a first-class citizen of the interface for such a use case, and not at all the pollutant suggested by the above citation. Though "Effective Java"'s anit-interface propaganda contains FUD slanted to support its argument, its recommended style is useful in practice. An (obviously much used) example can be found in the final class org.apache.catalina.Globals. >> Anyhow, like I said I don't care -- so long as JCS keeps improving the >> way it has been. > > Rockin! I'm going to continue focusing on the engine, access, and the > disk auxiliaries. Thus if anyone wants to take a swing at the lateral / > remote auxiliaries and see what needs to be cleaned up there, that would > be a big help. :) Eventually I will integrate JCS into SourceCast, and start participating more heavily in its development. That day is likely dependent upon the completion of integration of Scarab into SourceCast (as Scarab is already using JCS). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
