T copy()

[Aaron Fude]

Hi,

This seems contrary to Java's design, but I will ask the question
anyway.

Suppose I want to have

public interface Element {

public Element copy();

}

and

public class MyClass implements Element {


public MyClass copy() {
return new MyClass();
}

}

This is invalid Java but can something like this be accomplished with
Java 5 features?


Here is another question of the same kind. Suppose I am implementing
some kind of mathematical operator theory package. I have to concepts:
LinearOperator and Sum with the property that LO(a+b) = LO(a) + LO(b)

I believe this logic belongs at the LinearOperator level, rather than
at the level of a derived class, such as (TimeDerivative extends
LinearOperator).

So here's the type of method I'd like to write in LinearOperator (fake
code):

public class LinearOperator {
Element argument;

public Sum distribute() {
if (argument.isASum()) {
Sum sum = (Sum) argument;
return new Sum(new LinearOperator(sum.a), new LinearOperator
(sum.b));
}

throw new RuntimeException();
}
}

However, rather than creating an instance of LinearOperator, I need to
create an instance of the derived class, such as TimeDerivative.

So is there a good way to keep this logic at the LinearOperator level?

 

[Arne Vajhøj]

This seems contrary to Java's design, but I will ask the question
anyway.

Suppose I want to have

public interface Element {

public Element copy();

}

and

public class MyClass implements Element {


public MyClass copy() {
return new MyClass();
}

}

This is invalid Java but can something like this be accomplished with
Java 5 features?

It is valid Java since version something.

Arne

 

[Daniel Pitts]

Hi,

This seems contrary to Java's design, but I will ask the question
anyway.

Suppose I want to have

public interface Element {

public Element copy();

}

and

public class MyClass implements Element {


public MyClass copy() {
return new MyClass();
}

}

This is invalid Java but can something like this be accomplished with
Java 5 features?

Actually, that is perfectly valid in Java 1.5 and above. I believe its
called covariant return types.

Here is another question of the same kind. Suppose I am implementing
some kind of mathematical operator theory package. I have to concepts:
LinearOperator and Sum with the property that LO(a+b) = LO(a) + LO(b)

I believe this logic belongs at the LinearOperator level, rather than
at the level of a derived class, such as (TimeDerivative extends
LinearOperator).

So here's the type of method I'd like to write in LinearOperator (fake
code):

public class LinearOperator {
Element argument;

public Sum distribute() {
if (argument.isASum()) {
Sum sum = (Sum) argument;
return new Sum(new LinearOperator(sum.a), new LinearOperator
(sum.b));
}

throw new RuntimeException();
}
}

However, rather than creating an instance of LinearOperator, I need to
create an instance of the derived class, such as TimeDerivative.

So is there a good way to keep this logic at the LinearOperator level?

This might be a better approach:
public abstract class LinearOperator {
Element argument;

/**
* Derived classes will return new Self(newArgument);
* Replacing Self appropriately
*/
public abstract LinearOperator sameOperator(Element newArgument);

public Element distribute() {
return argument.distribute(this);
}
}

public class Element {
public Element distribute(LinearOperator lo) {
throw new UnsupportedOperation(
"Can not distribute an element of type " + getClass());
}
}

public class Sum extends Element {
// assuming a,b defined.
@Override
public Sum distribute(LinearOperator lo) {
return new Sum(lo.sameOperator(a), lo.sameOperator(b));
}
}

This is one of many ways you can do that.

 

[Aaron Fude]

Many times it'd be better to have this 'Element' type as an interface.




The main point is that instead of making LinearOperator or Element be aware of
their subtypes, you're using polymorphism to resolve the exact action to take.
  This is good programming.

Yes, I like it. What are other good ways that Daniel was referring to?

 

[Roedy Green]

This is invalid Java but can something like this be accomplished with
Java 5 features?

see http://mindprod.com/jgloss/covariance.html

Did you try compiling?