Using "abstract" on a class with no abstract method

[markspace]

public void process( final Command command )
{
if( command instanceof clockCommand )
{

This feels like a Observer pattern. At runtime, components get to
decide who they want to talk to via the Observer pattern. To find each
other in the first place, you might need a Mediator pattern. Both
Observer and Observable should register with the Mediator, so that they
have a common place to find each other.

<http://en.wikipedia.org/wiki/Observer_pattern>
<http://en.wikipedia.org/wiki/Mediator_pattern>

I'm not 100% sure those are exactly what you need, but they should at
least get you thinking.

/* This command is intended for me! Let me process it: */

if( command instanceof quitClockCommand )
{ /* Some party wants me to quit */ }

else if( command instanceof adjustClockCommand )
{ /* I should adjust myself now */ }

else { /* There are only these two clock commands,
so this is unexpected. */ }

The part above that I quoted feels like a Visitor pattern.

<http://en.wikipedia.org/wiki/Visitor_pattern>

Each component has one method to call -- "visit()" but could also be
called "command()" or "process()" or "eval()"; whatever makes sense in
your context -- and the Visitor pattern takes care of the dispatch.

else
{ /* This command is just passing-through, I will broadcast
it to my neighbors, maybe it is intended for one of them. */
broadcastToNeighbors( command );
/* Yes: if they do not know the command, and broadcast it,
too, this will give an endless loop of command reposts.
The real code will address this, the code posted here into
Usenet is simplified. */ }}

This bit feels like a Chain Of Responsibility pattern. However, I like
the Mediator pattern better, just because it's more direct.

<http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern>


Just some ideas.

 

[Daniel Pitts]

You can read my mind!

Indeed, I might use »instanceof« with these classes.

Think of a graph of interconnected components
(so that a component might have »neighbor components«),
including - for example's sake - a clock component.

The clock component then might contain code like:

public void process( final Command command )
{
if( command instanceof clockCommand )
{
/* This command is intended for me! Let me process it: */

if( command instanceof quitClockCommand )
{ /* Some party wants me to quit */ }

else if( command instanceof adjustClockCommand )
{ /* I should adjust myself now */ }

else { /* There are only these two clock commands,
so this is unexpected. */ }

else
{ /* This command is just passing-through, I will broadcast
it to my neighbors, maybe it is intended for one of them. */
broadcastToNeighbors( command );
/* Yes: if they do not know the command, and broadcast it,
too, this will give an endless loop of command reposts.
The real code will address this, the code posted here into
Usenet is simplified. */ }}

I have a guilty conscience for the use of »instanceof«.
But how can this be implemented in a better way in this case?

Sounds like you need a different design. You could possibly use a
visitor pattern, eg. command.visit(this),

That way, the command is responsible for known what method to call.

Actually, it is probably even better if the Clock class didn't know
anything about Commands, and instead you had a Controller that handles
all of that (including the broadcast/neighbor logic). The controller
knows all about Commands (or Command know all about the controller,
whichever).

Consider mimicking the Swing/AWT event and listener model for connecting
events to actions, it's design fits your scenario fairly well.

 

[Daniel Pitts]

I don't understand enough about what you're trying to do to address the
"passing through" and "neighbours" idea properly. However, to invert the
logic a bit, you've clearly got the information to decide _whether_ to
call command.process()...otherwise (see above) you never could have
constructed a Command subclass to pass to your "process" method in the
first place. So, wherever _that_ logic is, where you construct a Command
subclass, is perhaps where the logic should be to hand off to another
"neighbour" ("broadcast" as you put it).

The question is not whether avoidance of »instanceof« is
possible technically, but whether the resulting code will
be more readable and maintainable than the code using
»instanceof«.

Here is an SSCCE using »instanceof«.

Maybe someone wants to rewrite it so as to remove »instanceof«?
(In this case, keep in mind, that the type of neighbor
objects (here: »other«) changes at run-time and is not
known at compile time, because components are intended
to be added as run-time plug-ins. At coding time, we only
know that »other« is a »Processor« and thus will accept
a »Command«.)

abstract class Command { public boolean seen = false; }
interface Processor { public void process( final Command command ); }

/*** The clock component ***/

abstract class ClockCommand extends Command {}
class QuitClockCommand extends ClockCommand {}
class AdjustClockCommand extends ClockCommand {}
class Clock implements Processor
{ public Processor other;
public void process( final Command command )
{ if( command instanceof ClockCommand )
{ if( command instanceof QuitClockCommand )
java.lang.System.out.println( "quit clock" );
if( command instanceof AdjustClockCommand )
java.lang.System.out.println( "adjust clock" ); }
else
{ if( !command.seen && other != null )
{ command.seen = true; other.process( command ); }}}}

/*** The counter component ***/

abstract class CounterCommand extends Command {}
class QuitCounterCommand extends CounterCommand {}
class IncrementCounterCommand extends CounterCommand {}
class Counter implements Processor
{ public Processor other;
public void process( final Command command )
{ if( command instanceof CounterCommand )
{ if( command instanceof QuitCounterCommand )
java.lang.System.out.println( "quit counter" );
if( command instanceof IncrementCounterCommand )
java.lang.System.out.println( "increment counter" ); }
else
{ if( !command.seen && other != null )
{ command.seen = true; other.process( command ); }}}}

/*** The controller ***/

public class Main
{ public static void main( final java.lang.String[] args )
{
final Clock clock = new Clock();

{ /* Build a graph of connected components: */
clock.other = new Counter(); }

{ /* Send commands to a component: */
clock.process( new AdjustClockCommand() );
/* You can send a counter command to a clock, too: */
clock.process( new IncrementCounterCommand() ); }}}

/* This will print:

adjust clock
increment counter

*/

how about replacing your command structure with method calls:
clock.adjustClock();
clock.incrementCounter();

 

[Stefan Ram]

how about replacing your command structure with method calls:
clock.adjustClock();
clock.incrementCounter();

I think this idea illustrates the meaning of
»straightforward«.

However, my idea is to have a program that can be changed
at runtime. That is, components can be added or removed
from the program as plug-ins at run-time.

Say, the clock component issues a call to the text console
component. In your notation, this is:

textConsole.println( "clock ready." )

However, the user might not have added any text console
component to his program instance. So this can not work.

Instead, the clock component uses:

container.process( new PrintConsoleCommand( "clock ready." ));

Now, if the container happens to be a text console itself,
it will print the text. Otherwise, the text will be
forewarded in such a manner that it will reach all text
console components, if any is present in the program at
all at this moment, otherwise, the message will eventually
be ignored.

I also do not like to have a single communication manager,
because I want local interaction of components. That is,
each component interacts directly only with its container
and its containees.

 

[Mike Schilling]

I think this idea illustrates the meaning of
»straightforward«.

However, my idea is to have a program that can be changed
at runtime. That is, components can be added or removed
from the program as plug-ins at run-time.

Say, the clock component issues a call to the text console
component. In your notation, this is:

textConsole.println( "clock ready." )

However, the user might not have added any text console
component to his program instance. So this can not work.

Instead, the clock component uses:

container.process( new PrintConsoleCommand( "clock ready." ));

Now, if the container happens to be a text console itself,
it will print the text. Otherwise, the text will be
forewarded in such a manner that it will reach all text
console components, if any is present in the program at
all at this moment, otherwise, the message will eventually
be ignored.

I also do not like to have a single communication manager,
because I want local interaction of components. That is,
each component interacts directly only with its container
and its containees.

Is there a master list of commands, or are they added by optional
components as well?

If the former, you could assign each command a numeric value, and
eliminate instanceof by changing command processing to a switch
statement. Even if the latter, you could assign each compnent a
unique namespace and assign numbers within the component. Command
processing becomes

if (cmd.getNamespace.eq("http:://clock.org")
{
switch(cmd.getCommandNumber())
{
case CLOCK_SET:
...
}
}

 

[Stefan Ram]

Is there a master list of commands, or are they added by optional
components as well?

There is no master list.

In the simple case, the commands are part of the component,
as I have written before:

/*** The clock component ***/

abstract class ClockCommand extends Command {}
class QuitClockCommand extends ClockCommand {}
class AdjustClockCommand extends ClockCommand {}
class Clock implements Processor
{ public Processor other;
...

Here, the command hierarchy is part of the clock component.

This is important so that to add a new component, one
needs to add or change in /one/ place - not in two places
(1st the component, and 2nd the master list).

This means, that there still is some compile-time dependency,
because the component must be available, when a call like

container.process( new AdjustClockCommand() );

is being compiled.

But this will work at run-time, when there is no instance
of the clock component at run-time, or when there is one,
or when there are multiple instances of it.

If ever needed, even this dependency can be removed by
splitting the above code into a »standard clock message
interface« and a »A concrete clock component«.

/*** The standard clock message interface ***/

abstract class ClockCommand extends Command {}
class QuitClockCommand extends ClockCommand {}
class AdjustClockCommand extends ClockCommand {}

/*** A concrete clock component ***/

class Clock implements Processor { ... }

/*** Another concrete clock component ***/

class Clock1 implements Processor { ... }

Now, the compiler only needs to know the standard clock
message interface to compile

container.process( new AdjustClockCommand() );

It does not need to know the clock component at all.

If the former, you could assign each command a numeric value, and
eliminate instanceof by changing command processing to a switch
statement. Even if the latter, you could assign each compnent a
unique namespace and assign numbers within the component. Command
processing becomes
if (cmd.getNamespace.eq("http:://clock.org")
{
switch(cmd.getCommandNumber())
{
case CLOCK_SET:
...
}
}

Yes, but what I like about using the Java class hierarchy
for this is that I get a tree hierachy for free. That is,
my code can use the fact that

QuitClockCommand is a ClockCommand, which is a Comand, and that
AdjustClockCommand is a ClockCommand, which is a Comand,

for example, when nesting tests as in

if( command instanceof CounterCommand )
{ if( command instanceof QuitCounterCommand )...
if( command instanceof IncrementCounterCommand )... }

.

 

[Mike Schilling]

Yes, but what I like about using the Java class hierarchy
for this is that I get a tree hierachy for free. That is,
my code can use the fact that

QuitClockCommand is a ClockCommand, which is a Comand, and
that
AdjustClockCommand is a ClockCommand, which is a Comand,

for example, when nesting tests as in

if( command instanceof CounterCommand )
{ if( command instanceof QuitCounterCommand )...
if( command instanceof IncrementCounterCommand )... }

I see (I guess). Do you never find the need for a command to be both
an A and a B, as you could get from testing for interfaces instead of
classes?

 

[Stefan Ram]

I see (I guess). Do you never find the need for a command to be both
an A and a B, as you could get from testing for interfaces instead of
classes?

Yes (never). (I sometimes overgeneralize and by this make
programming harder for myself than it actually needs to be.
But at least this is one need I do not foresee.)