For example, I need 2 classes having the same methods but working with different object types. Should I write the same code twice?
interface I{
getValue();
setValue(value);
}
class Aimplements I{
Integer value;
Integer getValue(){return value;}
setValue(Integer value){ this.value = value;}
}
class Bimplements I{
Float value;
Float getValue(){return value;}
setValue(Float value){ this.value = value;}
}
You don't always have to write two different classes. If you are willing to accept a less strict class it can be implemented as below. I can see that both your classes use numerical values, so a choice of type could be the Number class (which is a super-class of both Integer and Float)
class AB {
Number value;
Number getValue() { return value; }
void setValue(Number value) { this.value = value; }
}
Søren
> For example, I need 2 classes having the same methods
> but working with different object types. Should I
> write the same code twice?
No, abstract the parameteric differences away with a common base to both parameter types.
However in your example your parameters are primatives not objects. You could wrap these.
interface I {
getValue();
setValue(abstractType value) ;
}
class intObj implements astractType { ... } ;
class floatObj implements astractType { ... } ;
class A implements I {
Integer value;
Integer getValue() { return value; }
setValue(intObj value) { this.value = value; }
}
class B implements I {
Float value;
Float getValue() { return value; }
setValue(floatObj value) { this.value = value; }
}
Hi,
please don`t use an interface here ! In my opinion setters and getter have to be defined on classes, which actually can have instance variables and an interface can evidently not !
If class 'A' and class 'B' are semantically used in the same context and there is really a possible super type which has a 'is a'-relation to 'A' and 'B' then define an abstract superclass.
If no semantic relation exists between 'A' and 'B' then just implement two independent classes.
Adrian
> There are valid cases for using an interface or
> abstract class with getters/setters.
of course, but the initial reason to have interfaces is not to define setters / getters. it is to define a certain common behaviour. And in this example, I can see no actual common behaviour, except that it seems to be that an instance var has the same name (although it has a different type)
> If you forget
> that they look like properties, they are just methods
> that can be called polymorphically.
you are right. D`accord. But why do I need polymohistic behaviour of a getter for example !
Adrian
>> There are valid cases for using an interface or
>> abstract class with getters/setters.
>of course, but the initial reason to have interfaces is not to define >setters / getters. it is to define a certain common behaviour
Yep, that's what I meant, the common behavior to be the setters/getters.
This is pretty much irrelevant to the OP topic though, as the use of interface there is inappropriate. Code-generation would be a viable solution, but wouldn't worth the effort if it is just for a couple of classes.
