c.scherr wrote :

Make a class which holds these primitives, and use that as the
parameter. The sub-class can then use whatever it wants to use.

Or you can make a series of sub-classes which are also abstract each of
which have the specific parameter type.

Umm, doesn't that break the interface?  Say some user has
 ParentClass myObj = new SubClass();
 myObj.update(12);
What should happen?

If update is a method that all subclasses must have, it must have the same
signature as it could be called by someone who doesn't know at compile-time
what the specific subclass is.

I suspect you're misusing inheritance to try to do this.  But you can get
close by:

class AbstractFoo {
   public abstract void update(Object... args);
}

class ConcreteFoo extends AbstractFoo {
   public void update(Object... args) {
       if (args == null || args.length != 1 || (!args[0] instanceof Integer))
           throw new IllegalArgumentException("screw you!");
       int mySpecificArg = ((Integer)args[0]).intValue();
       ...
   }
}

But to do so, you're saying that any user of AbstractFoo must know the actual
subclass they're using in order to pass reasonable arguments.  That sucks, and
indicates your type hierarchy is broken.  

A little better might be to define an interface like FooUpdateData, and have
 public abstract void update(FooUpdateData data);
in the superclass, and provide factory methods for getting the update data so
that callers can remain agnostic to the type of Foo they're using.  But even
so, I'd worry that I'm getting a bit esoteric for a simple requirement.  

A bit more data about what you're trying to accomplish would help to give
better answers.
--
Mark Rafn    dagon@dagon.net    <http://www.dagon.net/>

As well as the other suggestions, you could use:

 public void update(String params);

Each individual update method would have to parse its own parameter
string.

This does not solve the many problems, but it does allow you to use a
single parameter type.

rossum

Others have already offered suggestions on how to do this, so I'm going
to poke at the why a bit.

From a caller-via-the-superclass's point of view, all subclasses are
equivalent.  For example,

public void doSomethingWithScherrUpdatable (Updatable up) {
 up.update (12);
}

is valid for calls such as

 doSomethingWithScherrUpdatable (new TakesOneStringUpdatable ());
and
 doSomethingWithScherrUpdatable (new NoArgsUpdatable ());

The superclass's interface describes how client code calls the
subclass's methods.

Under these constraints it makes no sense to have a superclass method
whose signature is different for each subclass: code trying to call the
update method via the superclass interface would have to have knowledge
of which subclass it's calling, at which point it might as well call it
through the subclass interface and make that knowledge explicit.

Is there a reason you need the "update" method to be available via the
superclass?  If not, have you thought about giving each subclass an
update method but *not* giving one to the superclass?

A concrete example of what you're building would help us come up with
more concrete suggestions for how to build it.

-o

Just to pop up here also...

I'd require the method to take no parameters.  Then use setters on the
object in question to configure it so it "just knows" what to do, then
call update();

Example:

 Circle c = new Circle();
 c.setRadius(10);
 c.setPosition(0,0);
 c.update();
 Square s = new Square();
 s.setSize( 10, 5 );
 s.setPosition( 0, 0);
 s.update();

Here's two related objects are configured then "updated()", doing
whatever that does for the object.  Maybe the object is drawn on the
screen, or maybe it's serialized to a file.

On Sun, 9 Dec 2007 13:14:30 -0800 (PST), "c.scherr"
<constantinscherr@gmail.com> wrote, quoted or indirectly quoted
someone who said :

The best you could do is make an abstract class with all the variants
or a base class with dummy implementations of the variants.

I suppose you could also enforce your restriction with reflection.
see http://mindprod.com/jgloss/reflection.html