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.

will make the indentation of the code show up onthe web page. This is the same post as the one I calledUp and Down Examples but with the

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 methodthat is used for control? I think that is probably what youmean.

> 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 memberfunctions". 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 shouldnormally be passed upward, not downward, is first that ingeneral 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 classjava.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 itis used to decide whether to show or hide the component, so myfirst leaning would be towards design A, an approach thatdoesn't pass control down, yields more cohesive methods, butwhich in fact yields more methods.

The counter balance to this philosophy is that you should alsostrive to keep the number of methods in a class to a manageablelevel. My whole point for trying to maximize cohesion and makeeach method do just one thing is to make methods that areeasier to understand, use, and change. But in this case, I don'tfind setVisible(boolean) hard to use at all, so I think it'sa fine choice, especially since all data passed to setVisible()are used at all times. But you can imagine that any class couldpotentially be designed with only one big method that takesflags that tell it what to do. So you have to draw the linesomewhere as a designer.

Now, here's an example that illustrates what I meant by upwardis 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 beingused 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 passedin an upwards direction, from isVisible() up to doSomething(),so it's OK in my book. Just about any exception is going tobe 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 Iknow most UNIX commands pass down a lot of "data used forcontrol". But it would be silly to have a different ls commandfor 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, andso on. That would be a combinatorial explosion nightmare.

But on the other hand, you don't want just one UNIX command thatdoes everything and you have to pass flags to say what you wantthat to mean. Such as glurp -ls means ls, glurp -rm means rm andso on. So once again you've got to draw the line somewhere, justlike with Java methods in a class. You've got to choose a placesomewhere in the middle between the extremes of low cohesionand high Java method (or UNIX command) count.

I think that saying that you should try to avoid passing downcontrol, strive to focus each method on one conceptual task,avoid parameters that are only used part of the time, and keepthe number of methods in the class to a "manageable" level isa good way to approach finding that middle between the extremes.

Does that sound reasonable to you? Where would you do thingsor think about things differently?