I am planning an interface consisting of only constance variables, which is used by both client and server classes. Since this constance interface seems centerized and easy to maintain from the point of programming. However, from the point of oo design, is this a good way to do? my concern here is that some constances relevant to, say server, now becomes visible to clients (though they can't modify it). For this assignment, we need a good ood, is this a good or bad design?
Constants interface considered a design antipattern. Don't use it. Just arrange the constants in classes they belong to. Another possibilty is to create utility class. It may consist only variables for start, but you may wish to add some helper methods in it later.
Well, although I have no idea what "static class" means, but creating class as holder for constants is bad idea too. Constant fields (public static final) should be declared in suitable class. Look at Sun Java API docs - MAX_VALUE for Integer is defined in Integer class, not in File or ClassLoader, nor in special class. Static final variable is shared by all instances of class. Do not invent anything else.
I meant by static class, a class that has no public constructor, and all of its methods and variables are static. Sorry, I should not have used this term. There is not such thing called static classes.
SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle
Hey, thanks for all your comments. I really learned a lot:
1. using constants interface is a bad ood. 2. class of static fields (Hanna's static class) may not be a good ood choice, either.
Further deduction: 3. a good ood should overweight maintenability requirement. (a centralized constants is easy to maintain) 4. I personally don't like the idea of utility class (I guess this is like properties file), since the resulting file is eventually in the control of user; this is the least thing a developer wants to do. Furthermore, the constants in issue can be determined before compilation and do not depend on user's input (so that is why they are constants, such as default file location and port, etc in this assignment), therefore I don't see any benefits we gain here while putting ourselves in the danger of ruin of whole program. But, I don't know what you think and how Sun likes.
I don't think using constants interface is a bad ood.
See sun's java API: interface "javax.swing.WindowConstants".
Sun's API is generally considered good ood, isn't it?
What is good ood? I think the key point of OO is that with the OO principle, it is easier to break a job into several reusable, self-contained pieces. This makes programs easy to code and debug, easy to understand and maintain. As long as your code is based on this principle, it should be considered good ood.
any comments? [ June 05, 2004: Message edited by: Peter Yunguang Qiu ]
posted 16 years ago
Good point. It seems that my idea of using interface just follows Sun's ood. Instead of using one centralized constants interface, break it down for several, so that each serves for one package. I did it this way.
Whether this is a good idea or not depends on the nature of the constants - are they relevant to an API/interface or not? - from the sound of it, AZ's constants may be a mix of both. See the C2 wiki for a thorough exploration of the matter.
posted 16 years ago
Sun also see Constansts Interface as an antipattern. This is the primary reason for the "static import" feature, which is now applied in J2SE 1.5.