Hi,
Was meinst du damit? (Dir gefällt nicht, daß die Konstanten im Interface
alle public sind?)
Ja, und zwar dann, wenn die Konstanten offensichtlich ein Teil der Implementierung des Interfaces sind - und dadurch eben die eigentlich beabsichtigte Trennung zwischen Abstraktion und Implementierung wieder aufgehoben wird.
Ich verwende daher meistens abstrakte Klassen für "shared" Konstanten.
Wie sieht das dann genau aus?
Bei:
public interface IBLZs {
static final int BLZ_MUSTER_SPARKASSE_X = 111111111;
static final int BLZ_MUSTER_SPARKASSE_Y = 222222222;
static final int BLZ_MUSTER_BANK_X = 111111111;
static final int BLZ_MUSTER_BANK_Y = 222222222;
}
public interface Konto extends IBLZs {
void setBLZ(int neueBLZ);
int getBLZ();
}
public class KontoSparkassen implements Konto {
public void setBLZ(int neueBLZ) {
if (BLZ_SPARKASSE_X == neueBLZ) {
// tue was
}
}
// code...
}
...sehe ich Folgendes als geeignetere Lösung:
public interface Konto {
// Methoden wie oben
}
public abstract class BLZSparkassen {
public static final int BLZ_SPARKASSE_X = 111111111;
public static final int BLZ_SPARKASSE_Y = 222222222;
}
public abstract class BLZBanken {
public static final int BLZ_MUSTER_BANK_X = 111111111;
public static final int BLZ_MUSTER_BANK_Y = 222222222;
}
public class KontoSparkassen implements Konto {
public void setBLZ(int neueBLZ) {
if (BLZSparkassen.BLZ_SPARKASSE_X == neueBLZ) {
// tue was
}
}
// code...
}
Manche halten das für eine "rein formale" (also in der Praxis nicht hilfreiche) Diskussion. Das kann man so sehen. Ich denke aber, dass man dadurch in der Praxis Code ohne relevanten Mehraufwand besser strukturieren kann (der von dir bereits angesprochene Verbrauch an Speicherresourcen würde dadurch potentiell auch - zumindest theoretisch - profitieren..).
Natürlich macht es auch einen Unterschied, wieviele Entwickler an der Implementierung teilhaben. Wenn ich weiß, meine Sourcen werden sowieso niemals der Öffentlichkeit zugänglich gemacht, dann.... ;-)
Viele Grüße,
Martin Jung