oo design
posted 21 years ago
-
-
Number of slices to send:Optional 'thank-you' note:
-
-
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?
Thanks.
Thanks.
--------<br />Andy Zhu<br />scjp 1.4<br />scjd 1.4<br />SAS Certified Programmer 9.0
posted 21 years ago
-
- Number of slices to send:Optional 'thank-you' note:
-
-
hi Andy:
Interfaces should be created only to define types not constants. You better create a static class for constants.
Interfaces should be created only to define types not constants. You better create a static class for constants.
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
posted 21 years ago
-
- Number of slices to send:Optional 'thank-you' note:
-
-
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.
posted 21 years ago
-
- Number of slices to send:Optional 'thank-you' note:
-
-
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.
Regards<br /> <br />Ph.D.<br />SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJD 2
Hanna Habashy
Ranch Hand
Posts: 532
posted 21 years ago
-
- Number of slices to send:Optional 'thank-you' note:
-
-
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.
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
posted 21 years ago
-
- Number of slices to send:Optional 'thank-you' note:
-
-
Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Denis Spirin
Ranch Hand
Posts: 72
posted 21 years ago
-
- Number of slices to send:Optional 'thank-you' note:
-
-
Michael is right, there really exist static inner classes. Usually it is specified that class is "static nested" then.
Anyway.
Anyway.
Regards<br /> <br />Ph.D.<br />SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJD 2
Andy Zhu
Ranch Hand
Posts: 145
posted 21 years ago
-
- Number of slices to send:Optional 'thank-you' note:
-
-
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.
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.
--------<br />Andy Zhu<br />scjp 1.4<br />scjd 1.4<br />SAS Certified Programmer 9.0
Baruch Sadogursky
Author
Posts: 65
5
posted 21 years ago
-
- Number of slices to send:Optional 'thank-you' note:
-
-
What I ment by utilty class is a helper class with static methods, and maybe some a REALY global constansts either. As much as I know it is a well sread practice with nothing wrong with it.
posted 21 years ago
-
- Number of slices to send:Optional 'thank-you' note:
-
-
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 ]
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 ]
Peter
Andy Zhu
Ranch Hand
Posts: 145
posted 21 years ago
-
- Number of slices to send:Optional 'thank-you' note:
-
-
Hey, Peter:
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.
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.
--------<br />Andy Zhu<br />scjp 1.4<br />scjd 1.4<br />SAS Certified Programmer 9.0
posted 21 years ago
-
- Number of slices to send:Optional 'thank-you' note:
-
-
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.
- Peter
- Peter
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Baruch Sadogursky
Author
Posts: 65
5
posted 21 years ago
-
- Number of slices to send:Optional 'thank-you' note:
-
-
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.
| Getting married means "We're in love, so let's tell the police!" - and invite this tiny ad to the wedding: Paul Wheaton's 16th Kickstarter: Gardening playing cards for gardeners and homesteaders https://coderanch.com/t/889615/Paul-Wheaton-Kickstarter-Gardening-playing |