Design Question
in [Java Programming]
|
Prev: Initializing a Map in an Interface?
Next: Urgent Opening for Senior .Net Engineer position with our direct client in Milpitas, CA
From: markspace on 16 Mar 2010 20:47 Stefan Ram wrote: > markspace <nospam(a)nowhere.com> writes: >> 1. No object state, "utility" methods: consider static methods and a >> private constructor. > > Even without state, one might want to implement interfaces. > Java does not provide interfaces with static methods. > True. The key here (for me anyway) is "utility methods." Short, well understood algorithms that are unlikely to change, other than globally. Example: Math.cos( double ) ... It's pretty unlikely you'd ever change the definition of a cosine. The definition of a cosine is mathematically pretty well understood. If you did change its implementation, you'd likely want those changes to affect all code globally. Many designs by users (rather than writers of the Java API) need the flexibility of an interface because their code is in fact going to change more often, every time the spec changes. So I agree that it's important to point out interfaces in this context. OTOH, the OP's example of "I have some string methods I think will make my life easier" is a pretty good example of some low-level methods that really might be best if implemented as static utility methods. They probably don't appear on the spec, they're just there to make the implementer's task easier.
From: markspace on 16 Mar 2010 20:57 markspace wrote: > constructor, so the method gives you a change to add additional code ^^^^^^ Should have been "chance."
From: Arne Vajhøj on 16 Mar 2010 21:10 On 16-03-2010 13:42, Rhino wrote: > I've read all the replies to this thread and have been trying to post > followup questions since yesterday afternoon; unfortunately, I've had > major problems with the news server and have finally had to resort to > posting via Google groups. Sorry for the delay! > > -- > Am I correct in assuming that a valid example of 'state' is the Locale > used by the class/methods to generate error messages? > > My StringUtils class generates a substantial number of error messages > via the standard ResourceBundle mechanism and delivers them in a > Locale-sensitive fashion. I have two constructors for StringUtils, one > that has no parameters and simply uses the default Locale, and the > other, which has the Locale desired by the user as the single > parameter. > > Now, if I want to continue to deliver Locale-sensitive messages and if > I make the constructors private, I can't tell the methods which Locale > to use in selecting message files via the constructor. I suppose I > could add a Locale parameter to each method's parameter list but that > seems ugly. > > What's the best way to handle Locale-sensitive messages if I want to > keep my methods static and my constructors private? > > Or does this factor change everything and now justify keeping the > StringUtils constructors public and its methods non-static? It does. And it somewhat illustrates the old fact that very few real world classes only contain static members. java.lang.Math is one but it is one of very few. Arne
From: Arne Vajhøj on 16 Mar 2010 21:14 On 16-03-2010 20:47, markspace wrote: > Stefan Ram wrote: >> markspace <nospam(a)nowhere.com> writes: >>> 1. No object state, "utility" methods: consider static methods and a >>> private constructor. >> >> Even without state, one might want to implement interfaces. >> Java does not provide interfaces with static methods. > > True. The key here (for me anyway) is "utility methods." Short, well > understood algorithms that are unlikely to change, other than globally. > Example: > > Math.cos( double ) ... > > It's pretty unlikely you'd ever change the definition of a cosine. The > definition of a cosine is mathematically pretty well understood. If you > did change its implementation, you'd likely want those changes to affect > all code globally. The interface is the definition. A Math interface would never change the definition of cos, but the implementations NativeMath and PortableMath (which is more or less todays Math and StrictMath) could. The reason that they don't is not because it does not make sense from an OO perspective - it is because it would really clutter mathematical code. Arne
From: John B. Matthews on 16 Mar 2010 21:57
In article <hnp6du$b7q$1(a)news.eternal-september.org>, markspace <nospam(a)nowhere.com> wrote: > Rhino wrote: > > > Again, can you clarify this a bit? You don't necessarily need to > > write an example; just pointing to a document or tutorial that > > contains an example would be just fine. I'm not sure where to look > > for such a thing. > > > A lot of what is being discussed here is based on patterns from a > book called "Effective Java" by Joshua Bloch. It's basically "design > patterns for Java" and it's very good. You should pick it up. > Whether you use its ideas or not is up to you, but I think it would > extend your understanding of Java quite a bit. "Item 1: Consider static factory methods instead of constructors" <http://www.drdobbs.com/java/208403883> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews> |