Design question - methods calling methods
in [Java Programming]
|
From: Rhino on 21 May 2010 16:20 Is it bad design for any reason for methods in one class to call other methods in the same class to do some of their work for them? I'm pretty sure the answer is no but this is just a sanity check to make sure I'm not forgetting an important factor. The situation that inspired the question is getLocales() method I've been discussing in another thread. In addition to the getLocales() method, I have a displayLocales() method. The displayLocales() method has no input parameters and returns nothing, it simply writes to the console. It begins by executing getLocales(), which returns a TreeMap, and then displays the contents of the TreeMap on the console. It seems absolutely reasonable to me that the getLocales() method gets called to obtain the actual Locales, rather than repeating the code from getLocales() again in displayLocales. If there is a problem with getLocales (), it obviously affects BOTH methods but it only needs to be fixed in one place to solve the problem for both methods which seems sensible to me. I'm not nearly as familiar with source code of the Java API as some of you seem to be but it seems to me that I've seen methods calling other methods in some of my debugging in Eclipse too. So this is not a problem, right? -- Rhino
From: Arne Vajhøj on 21 May 2010 16:33 On 21-05-2010 16:20, Rhino wrote: > Is it bad design for any reason for methods in one class to call other > methods in the same class to do some of their work for them? I'm pretty > sure the answer is no but this is just a sanity check to make sure I'm not > forgetting an important factor. It is very bad design never to do it. Calling other methods is the standard way to keep the size of methods down (and thereby improving readability). Arne
From: Eric Sosman on 21 May 2010 17:41 On 5/21/2010 4:20 PM, Rhino wrote: > Is it bad design for any reason for methods in one class to call other > methods in the same class to do some of their work for them? I'm pretty > sure the answer is no but this is just a sanity check to make sure I'm not > forgetting an important factor. It's perfectly normal for one method to "re-use" another method's code by calling that other method. There is, however, one thing to watch out for. If the called method can be overridden in a subclass, then the calling method might not execute the code it wanted, but the subclass' code instead. This may be all right (if a superclass calls hashCode() on an instance of a subclass, it usually *wants* the subclass' hashCode() and not its own), but can be surprising and perhaps troublesome if you weren't expecting it. It's *especially* bad in a constructor, where the superclass' constructor may wind up calling subclass code before the subclass' constructor has finished! Get a copy of "Effective Java" by Joshua Bloch, and read what he says about designing for inheritance. Read the rest of the book, too: It's good for the soul. > The situation that inspired the question is getLocales() method I've been > discussing in another thread. In addition to the getLocales() method, I > have a displayLocales() method. The displayLocales() method has no input > parameters and returns nothing, it simply writes to the console. It begins > by executing getLocales(), which returns a TreeMap, and then displays the > contents of the TreeMap on the console. This seems reasonable. A subclass that overrides getLocales() presumably does so because it wants to do something special, like filter out Locales for which you don't have fonts installed. If so, you'd presumably want to get the restricted Locale list rather than the one the superclass would provide, so you'd want to use the subclass' version of getLocales(). All seems well here -- but other circumstances might be less benign. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Rhino on 21 May 2010 19:22 Eric Sosman <esosman(a)ieee-dot-org.invalid> wrote in news:ht6uo6$flf$1(a)news.eternal-september.org: > On 5/21/2010 4:20 PM, Rhino wrote: >> Is it bad design for any reason for methods in one class to call >> other methods in the same class to do some of their work for them? >> I'm pretty sure the answer is no but this is just a sanity check to >> make sure I'm not forgetting an important factor. > > It's perfectly normal for one method to "re-use" another method's > code by calling that other method. > Good. At least I don't have to feel guilty for doing that :-) > There is, however, one thing to watch out for. If the called > method can be overridden in a subclass, then the calling method > might not execute the code it wanted, but the subclass' code instead. > This may be all right (if a superclass calls hashCode() on an > instance of a subclass, it usually *wants* the subclass' hashCode() > and not its own), but can be surprising and perhaps troublesome if > you weren't expecting it. It's *especially* bad in a constructor, > where the superclass' constructor may wind up calling subclass code > before the subclass' constructor has finished! > Darn, always a gotcha lurking somewhere in the forest ;-) > Get a copy of "Effective Java" by Joshua Bloch, and read what > he says about designing for inheritance. Read the rest of the book, > too: It's good for the soul. > I've heard a lot of good things about that book. Unfortunately, money is tight right now so it's going to have to wait a bit. But I will try to get it - and read it - when circumstances permit..... >> The situation that inspired the question is getLocales() method I've >> been discussing in another thread. In addition to the getLocales() >> method, I have a displayLocales() method. The displayLocales() method >> has no input parameters and returns nothing, it simply writes to the >> console. It begins by executing getLocales(), which returns a >> TreeMap, and then displays the contents of the TreeMap on the >> console. > > This seems reasonable. A subclass that overrides getLocales() > presumably does so because it wants to do something special, like > filter out Locales for which you don't have fonts installed. If so, > you'd presumably want to get the restricted Locale list rather than > the one the superclass would provide, so you'd want to use the > subclass' version of getLocales(). All seems well here -- but other > circumstances might be less benign. > Okay, fair enough. Even the most reasonable of actions can have unexpected consequences at times. I suppose that's a big part of the reason we test as thoroughly as we can, to catch that kind of thing. You can't anticipate EVERYTHING. -- Rhino
From: Rhino on 21 May 2010 19:23
Arne Vajh�j <arne(a)vajhoej.dk> wrote in news:4bf6ee28$0$285$14726298(a)news.sunsite.dk: > On 21-05-2010 16:20, Rhino wrote: >> Is it bad design for any reason for methods in one class to call >> other methods in the same class to do some of their work for them? >> I'm pretty sure the answer is no but this is just a sanity check to >> make sure I'm not forgetting an important factor. > > It is very bad design never to do it. > > Calling other methods is the standard way to keep the size of methods > down (and thereby improving readability). > Good! I will do so whenever I can, in good conscience! -- Rhino |