Grundrechenarten mit eigenen Typen

[fryasdf]

Hallo.

Schon oefter habe ich mich gefragt, ob man Java beibringen kann, wie es Plus, Minus, usw. auf selber definierten Objekten zu rechnen hat. Sagen wir dass wir folgende Klasse haben:

public class RationalNumber
{
   public int numerator, denominator;
   [...]
}

Jetzt moechte ich gerne sagen koennen

RationalNumber x = new RationalNumber();
RationalNumber y = new RationalNumber();
x.numerator = 1;
x.denominator = 2;
y.numerator = 1;
y. denominator = 3;

RationalNumber z = x + y;

Ich habe das bisher immer ueber

public static RationalNumber add(RationalNumber x, RationalNumber y) {
 [...]
}

geloest aber das fuehrt doch zu haeufig zu Fehlern wenn die Rechnungen kompliziert werden... Gibt es da so ein Standard Interface mit dem man das wie oben machen kann?

thx

fryasdf

 

[Marco13]

Leider* nein.


(* "Leider" weil es manchmal praktisch wäre, aber ... man könnte SO viel Mist damit machen, dass man zumindest davon ausgehen kann, dass dadurch einige :autsch:'s vermieden werden...)

 

[I.Haffner]

Wie schon gesagt geht das nicht, da Java ein Überladen der Operatoren nicht zulässt (wie es zB bei C++ möglich ist). Allerdings ist das auch nicht nötig.Du kannst dir deine eigenen Zahlen selber erstellen in dem du mit deiner eigenen Klasse zum einen die abstrakte Klasse Number erweiterst und Comparable<?> implementierst.
Ich hab das schonmal für Brüche gemacht. Bitte sehr:

public interface Fraction{
	
	int numerator();
	int denominator();
	void add(Fraction a);
	Fraction sum(Fraction a);

}

public class MyFraction extends Number implements Comparable<MyFraction>, Fraction {

	/**
	 * 
	 */
	private static final long serialVersionUID = -6360128714276017883L;
	
	private Integer denominator, numerator;
	
	public MyFraction(int n, int d) throws Exception{
		if(d==0) throw new Exception("Divisor is Zero");
		denominator = d;
		numerator = n;
		reduce();
	}
	
	public MyFraction(Integer n, Integer d){
		denominator = d;
		numerator = n;
		reduce();
	}

	@Override
	public int compareTo(MyFraction o) {
		int i = this.numerator * o.denominator - o.numerator * this.denominator;
		if(i>0) return 1;
		if(i<0) return -1;
		return 0;
	}

	public int numerator() {
		return numerator;
	}

	public int denominator() {
		return denominator;
	}
	
	private void reduce(){
		int gcd = MyMath.gcd(numerator, denominator);
		numerator = numerator/gcd;
		denominator = denominator/gcd;
	}

	@Override
	public void add(Fraction a) {
		this.numerator = this.numerator * a.denominator() + a.numerator() * this.denominator;
		this.denominator *= a.denominator();
		reduce();
	}

	@Override
	public MyFraction sum(Fraction a) {
		int n = this.numerator * a.denominator() + a.numerator() * this.denominator;
		int d = this.denominator * a.denominator();
		try {
			return new MyFraction(n, d);
		} catch (Exception e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		return null;
	}

	@Override
	public double doubleValue() {
		return (double) numerator / denominator;
	}

	@Override
	public float floatValue() {
		return (float)numerator / denominator;
	}

	@Override
	public int intValue() {
		return (int)(numerator / denominator + 0.5);
	}

	@Override
	public long longValue() {
		return (long)(numerator / denominator + 0.5);
	}
	
	@Override
	public String toString(){
		return numerator.toString() + "/" + denominator.toString();
	}

}

Das Interface ist eigentlich sehr Überflüssig : )

 

[emailundlos]

Ich hab das schonmal für Brüche gemacht. Bitte sehr:

Was genau hast du denn schon einmal damit gemacht? die Brüchen, also dein Bruch, ist unzureichend beschrieben oder? es wurden einfach die Namen übernommen, die fryasdf eingebracht hatte. Ich bin auch gerade dabei mir das beizubringen. Vielleicht hab ich ja Glück.

 

[I.Haffner]

die von mir erstellte Klasse

MyFraction

ist nun von der art wie

Integer

oder

Double

. Du kannst

MyFraction

mit

Double

oder

Integer

vergleichen, du kannst

MyFraction

mit

Double

und

Integer

verrechnen und durch die Implementierung von

Comparable<T>

steht dir auch eine

int compareTo(Object o)

Methode zur Verfügung mit der du Objekte mit einem Bruch vergleichen kannst. Diese compareTo-Methode sollte so implementiert werden, dass man eine Wohlordnung über seine Objekte bekommt.

PS: Habe meinen Code etwas überarbeitet.

MyFraction

implementiert jetzt

Comparable<Object>

und daraus folgt:

@Override
	public int compareTo(Object o) {
		MyFraction f = (MyFraction) o;
		int i = this.numerator * f.denominator - f.numerator * this.denominator;
		if(i>0) return 1;
		if(i<0) return -1;
		return 0;
	}

Ich denke das ist besser so.

PPS: Ich rate mal davon ab die compareTo-Methode über

Number.doubleValue()

zu implementieren, da

double

eine gewisse Ungenauigkeit hat was zu Problemen bei großen Brüchen werden kann : )

 

[Marco13]

In der compareTo brutal zu casten kann zu viel gravierenderen Problemen führen. Man könnte sich überlegen, sowas wie
MyFraction extends Number implements Comparable<Number>
zu machen...

 

[I.Haffner]

ja der cast ist brutal. allerdings soll

int compareTo(Object o)

ja alle objekte akzeptieren. und außerdem wirft die methode auch eine cast-exception. hatte es vorher anders, aber so ist es besser denke ich. zB lässt sich jetzt das compare auf objecte anwenden die den statischen typ object haben aber dynamisch vom typ MyFraction sind, das ginge anders nicht ; )

 

[Marco13]

Naja... man kann eine Fraction ja nicht mit wirklich beliebigen Typen vergleichen, sondern erstmal nur mit Zahlen - von daher könnte es sich IMHO anbieten, von Number zu erben. Aber das muss man sich halt mal genauer überlegen.

 

[I.Haffner]

mal angenommen du hast einen generator für ein array eines bliebigen statischen typs (der number und comparable implementiert) aber du weißt nicht um was für einen dynamischen typ es sich handelt.
jetzt beschließt du einen sortieralgorithmmus zu implementieren (oder minimum finden oder binary search oder iwas derartiges). dann müsstest du jedes mal prüfen von welchem dynamischen typ dein objekt ist (mit instanceof) und es dann casten. so kannst du jedoch einfach hingehen und compareTo aufrufen.

sagen wir dein generator kann die Interger[], Double[] und MyFraction[] liefern, aber du hast nur ein array vom typ Comparable<?>[] um die rückgabe zu speichern.
ich denke jetzt ist klar warum int compareTo(Object o) ein beliebiges Objekt akzeptiert ; )

PS: du kannst ja zB auch eine wohlordnung auf strings definieren, aber String ist kein Number!

 

[Marco13]

Die Frage, welchen Typ ein Array hat, der von einer hypothetischen Klasse geliefert wird, hat IMHO nichts damit zu tun, dass compareTo(Object) keinen Sinn macht. Aber vielleicht reden wir aneinander vorbei.