This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

test

Posted by test on August 21, 2000 at 1:46 PM

> I'm posting this again to see if surrounding code with

> and 

s inserted.
> > The use of flags usually turns my member fuctions into less cohesive
> > functions.
> >
> By flags do you mean pieces of data passed down into a method
> that is used for control? I think that is probably what you
> mean.
> > I find it appealing to have control passed downward and 
> > I believe that the loss of control of member fuctions can be avoided
> > if the low cohesive fuction is looked upon as an encapsulated block.  
> >
> I'm not certain what you mean by "loss of control of member
> functions". Could you elaborate on this point?
> > Will Someone Respond to the Statment that control should usually be 
> > passed upward, an example would be nice.
> >
> What I meant by my claim that date used for control should
> normally be passed upward, not downward, is first that in
> general you should avoid passing control downward:
> This kind of design (Design A):
> 

> void show() {
>     // Show it...
> }
> void hide() {
>     // Hide it...
> }
> 

> is "better" than this kind of design (Design B):
> 

> void show(boolean b) {
>     if (b) {
>         // Open it ...
>     }
>     else {
>         // Close it ...
>     }
> }
> 

> All three of these methods were deprecated in JDK1.1 in class
> java.awt.Component in favor of method setVisible(boolean b),
> which also happens to fall in the same category (Design B)
> as show(b).
> In Design B, the boolean flag b is used for control because it
> is used to decide whether to show or hide the component, so my
> first leaning would be towards design A, an approach that
> doesn't pass control down, yields more cohesive methods, but
> which in fact yields more methods.
> The counter balance to this philosophy is that you should also
> strive to keep the number of methods in a class to a manageable
> level. My whole point for trying to maximize cohesion and make
> each method do just one thing is to make methods that are
> easier to understand, use, and change. But in this case, I don't
> find setVisible(boolean) hard to use at all, so I think it's
> a fine choice, especially since all data passed to setVisible()
> are used at all times. But you can imagine that any class could
> potentially be designed with only one big method that takes
> flags that tell it what to do. So you have to draw the line
> somewhere as a designer.
> Now, here's an example that illustrates what I meant by upward
> is usually the direction data used for control should go:
> 

> void doSomething(Component c) {
>     if (c.isVisible()) {
>        // Do one thing with the component
>     }
>     else {
>        // Do something else with the component
>     }
> }
> 

> In this case, the boolean return value of isVisible() is being
> used to determine how to execute the doSomething()
> method, so the boolean return value is "data used for control."
> But in this case, the data used for control is being passed
> in an upwards direction, from isVisible() up to doSomething(),
> so it's OK in my book. Just about any exception is going to
> be an example of data used for control that is passed back up,
> but so can return values or even changed parameters.
> > Also it should be pointed out that most unix commands would then have
> > to be classed as cohesivly minmilistic!	
> >
> I'm not sure what you mean by cohesively minimalistic, but I
> know most UNIX commands pass down a lot of "data used for
> control". But it would be silly to have a different ls command
> for all the different ways you can do an ls. Instead of ls -l,
> ls -a, ls -t, ls -lsa, you'd end up with ll, la, lt, or llsa, and
> so on. That would be a combinatorial explosion nightmare.
> But on the other hand, you don't want just one UNIX command that
> does everything and you have to pass flags to say what you want
> that to mean. Such as glurp -ls means ls, glurp -rm means rm and
> so on. So once again you've got to draw the line somewhere, just
> like with Java methods in a class. You've got to choose a place
> somewhere in the middle between the extremes of low cohesion
> and high Java method (or UNIX command) count.
> I think that saying that you should try to avoid passing down
> control, strive to focus each method on one conceptual task,
> avoid parameters that are only used part of the time, and keep
> the number of methods in the class to a "manageable" level is
> a good way to approach finding that middle between the extremes.
> Does that sound reasonable to you? Where would you do things
> or think about things differently?
> bv










Replies: