Klasse richtig überladen

[usrr]

Hallo,

angenommen ich möchte die Klasse BigInteger überladen, um zusätzlich noch ein paar Methoden zuzufügen:

import java.math.BigInteger;

public class NewBigInteger extends BigInteger {

	public IntegerNumber(String val) {
		super(val);
	}
}

Wenn ich nun die neue Klasse benutze, muss ich immer Typecasten, um die alten Methoden anzuwenden.

[Java]
...
NewBigInteger newBigInteger = new NewBigInteger("1");
newBigInteger = (NewBigInteger)newBigInteger.negate();
...
[/code]

Kann man das besser lösen?

 

[SlaterB]

das wäre dann wohl

public class Test {
    public static void main(String[] args) {
        NewBigInteger a = new NewBigInteger("1");
        a = a.negate();
        System.out.println(a);
    }
}

class NewBigInteger  extends BigInteger {

    public NewBigInteger(String val) {
        super(val);
    }

    public NewBigInteger negate() { // passt in Vererbung
        return new NewBigInteger(super.negate().toString());
    }
}

unnötige Objekterzeugung, aber negate() an sich liefert nunmal BigInteger


wenn du alle wichtigen Methoden überschreibst, kannst du dir die Vererbung irgendwann auch sparen
und intern BigInteger-Attribute verwenden,
dann kommt man langsam zur Frage ob nicht dasselbe Objekt this, mit intern geänderten Wert zurückgegeben wird,
veränderlich vs unverändlich, eine grundlegende Entscheidung

 

[usrr]

Ich hätte aber gerne neue Methoden, beim BigInteger wäre das z.B. die Fakultät.

 

[SlaterB]

das ist von allem anderen unabhängig,
die BigInteger-Methoden, die du brauchst, musst du in jedem Fall überschreiben/ neu definieren, wie dabei intern agiert wird ist variabel,
wenn das fertig ist, was immer für eine Klasse dabei rauskommt, dann kannst du dort auch Fakultät ergänzen

 

[Michael...]

Wenn ich nun die neue Klasse benutze, muss ich immer Typecasten, um die alten Methoden anzuwenden.

[Java]
...
NewBigInteger newBigInteger = new NewBigInteger("1");
newBigInteger = (NewBigInteger)newBigInteger.negate();
...
[/code]

Die "alten" Methoden liefern nun mal einen BigInteger, allerdings würde der Cast fehlschlagen, da ein BigInteger nunmal kein NewBigInteger ist.

Kann man das besser lösen?

Lösen könnte man das, in dem man die relevanten Methoden ebenfalls überschreibt ;-) Besser lösen?? Hängt davon ab was man genau vor hat. Nach den bisherigen Informationen macht es eigentlich keinen Sinn, dass NewBigInteger von BigInteger erbt.

 

[usrr]

Ja, ich bin gerade dabei die relevanten Methoden zu überschrieben. Ob die Lösung elegant ist, kann ich nicht sagen.

Hier ein Auzug.

[Java]
...
@Override
public IntegerNumber negate() {
return (IntegerNumber) super.negate();
}

@Override
public IntegerNumber gcd(BigInteger val) {

return (IntegerNumber) super.gcd(val);
}

public IntegerNumber multiply(IntegerNumber val) {
return (IntegerNumber) multiply((BigInteger)val);
}

public IntegerNumber divide(IntegerNumber val) {

return (IntegerNumber) divide((BigInteger)val);
}
...
[/Java]

Sind die @Override nötig/richtig?

 

[bygones]

wenns einfach um Funktionalitaet geht biete eine Utility Klasse an die die Fakultaet fuer ein BigInteger berechnet - dann hast du diese ganze Problematik nicht - das schreit danach, dass es krachen wird

 

[SlaterB]

Cast wird nicht reichen wie gesagt wurde, aber macht sich eh bald bemerkbar

 

[Michael...]

Ja, ich bin gerade dabei die relevanten Methoden zu überschrieben. Ob die Lösung elegant ist, kann ich nicht sagen.

Elegant ist hier nicht die Frage. Schon mal den Code ausgeführt? Deine Casts werden jedesmal eine Exception werfen, da ein BigInteger nunmal kein IntegerNumber ist.

Sind die @Override nötig/richtig?

nötig sind sie nicht, können aber dem Entwickler helfen. Wenn dieser falsche Methodensignaturen verwendet, wird er vom Kompilier darauf hingewiesen...

 

[usrr]

Das man BigInteger nicht zu IntegerNumber casten kann ist natürlich wahr - und ein Problem.

 

[irgendjemand]

alleine in deinem ersten post passt doch schon was nicht

die klasse heißt "NewBigInteger" ... dem konstruktor gibst du aber den namen "IntegerNumber" ... DAS GEHT NICHT !

auch deine ganzen überschriebenen methoden liefern "IntegerNumber" ... sind aber in der klasse "NewBigInteger" definiert ...

das muss doch auffallen das da was nicht stimmt ...

und um das was du vorhast zu erreichen würde man in der praxis eh keine vererbung einsetzen sondern wie schon jemand sagte eine utility klasse bauen die mit BigInteger objekten die fakultät berechnet *wobei das gerade bei rekursiver lösung schnell zu stack-overflow's führt* ...

 

[usrr]

Ja, sehe ich jetzt auch. Liegt aber daran, dass ich kein CopyAndPaste gemacht habe, sondern das schnell eingetippt habe um ein Beispiel zu haben. Bin mit den Namen durcheinander gekommen.

Habe mit einen Wrapper geschrieben, weil ich später sowieso vor habe die BigInteger-Klasse selbst zu implementieren.

 

[SlaterB]

Fakultät würde ich nicht gerade als stack-overflow-gefährdend ansehen
aber stimmt schon, kann mit BigInteger in der Tat so kommen falls man Zahlen mit Tausenden Stellen haben will für n > 1000,
der Stack gibt vor BigInteger auf (bei mir bei n zwischen 3200 und 3300)

 

[usrr]

Du meinst wenn du es rekursiv machst?

 

[irgendjemand]

also wenn ich rekursiv mit BigInteger die fakultät berechnen will *nach dem pseudo-code von wikipedia* dann knallt es bei mir zwar erst bei n > 6500 ... allerdings muss ich dafür dann schon sowohl heap- als auch stack-size auf 3GB anheben ...

iterativ dürfte das deutlich besser aussehen