Uh, another test: code indentation (Legacy Design Forum)

Uh, another test: code indentation

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:

Uh, another test: code indentation

Posted by Bill Venners on 17 Apr 1998, 8:02 AM

That was brilliant. I think the pre's work OK, unfortunately
I forgot that even the ones in the description would work.
Trying one more time.

I'm posting this again to see if surrounding code with pre
and /pre will make the indentation of the code show up on
the web page. This is the same post as the one I called
Up and Down Examples but with the pres 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?

Replies:


	Web Artima.com