Wo Umrechnungsfunktionen einfügen

[DarkGuardian]

Hallo zusammen

Ich habe mal eine allgemeinere Frage zum Bereich OOD. In der Objektorientierung gibt es ja eigentlich nur Objekt, die über verschiedene Methoden Aktionen auslösen. Damit lassen sich selbst komplexere Abläufe gut kapseln und somit überschaubar umsetzen.

Nun habe ich aber schon öfters das Problem gehabt, dass ich irgendwelche kleineren Umrechnungsfunktionen benötige. Wenn ich z.B. Geschwindigkeiten in andere Einheiten umrechnen soll und das von verschiedensten Klassen genutzt werden muss, bin ich mir unsicher, wie man das am besten entwirft.

Ansich wäre eine globale Funktion eine einfache Lösung, wobei das ja nicht OO entspricht (zumindest wenn man es genau nimmt). Aber eine Klasse zu erstellen, die nur statische Umrechnungsmethoden (oder auch nur eine) umfasst, scheint mir auch etwas seltsam. Zwar passt das in die OO, aber eigentlich sind die Objekte ja das ausschlaggebende bei dieser Art der Softwareentwicklung.

Wie löst ihr dieses Problem bzw. welche Ideen habt ihr dazu?

[knivil]

Geschwindigkeiten in andere Einheiten

Beispiel?

Wie löst ihr dieses Problem bzw. welche Ideen habt ihr dazu?

Benutzung des SI Einheitensystems im ganzen Programm.

[DarkGuardian]

knivil schrieb:

Geschwindigkeiten in andere Einheiten

Beispiel?

Zum Beispiel die Umrechnung von km/h in Knoten oder eine sonstige Einheit. Und falls es etwas komplexer sein soll, Koordinaten in verschiedene Formate umrechnen (Lat/long zu UTM z.B.).

knivil schrieb:

Wie löst ihr dieses Problem bzw. welche Ideen habt ihr dazu?

Benutzung des SI Einheitensystems im ganzen Programm.

Mir ging es jetzt explizit um die Umrechnung von Geschwindigkeitswerten. Ich suche eine schöne Möglichkeit, Umrechnungsfunktionen in der OO verschiedensten Klassen verfügbar zu machen. Es geht also eher um eine allgemeine Entwurfsentscheidung.

[Tyrdal]

Mach doch ne einfache Funktion kmhToFps o.ä.

[DarkGuardian]

Tyrdal schrieb:

Mach doch ne einfache Funktion kmhToFps o.ä.

Nur das Funktionen nicht im Sinne der Objektorientierung sind. Da werden Methoden eingesetzt. Aber dafür müsste ich eine Klasse anlegen, die wiederum nur diese Umrechnungsmethode besitzt, welche sogar statisch sein können. Daher wüsste ich gerne, wie das "Problem" andere Entwickler gelöst haben.

Wie gesagt, das Ganze zu programmieren, ist nicht mein Problem. Ich wüßte nur gerne, wie man das elegant in der OO lösen kann.

[SideWinder]

Das ist doch ähnlich dem "Problem": Wohin mit Mathematik-Funktionen ala sin()? Eine Methode von Double? Eher nicht.

Ich glaube allgemein durchgesetzt haben sich simple Funktonen bzw. Hilfsklassen ala "MathUtils".

Ich könnte mir da sehr gut eine "DimensionUtils" oder "MeasurementUtils" vorstellen.

MfG SideWinder

[DarkGuardian]

Stimmt, bei den mathematischen Funktionen ist das Problem ja bekannt. Ich hoffe nur, dass jemand noch eine elegantere Lösung hat. Aber ich vermute, dass diese ausbleiben wird.

Trotzdem Danke für den Hinweis.

[pumuckl]

DarkGuardian schrieb:

knivil schrieb:

Geschwindigkeiten in andere Einheiten

Beispiel?

Zum Beispiel die Umrechnung von km/h in Knoten oder eine sonstige Einheit. Und falls es etwas komplexer sein soll, Koordinaten in verschiedene Formate umrechnen (Lat/long zu UTM z.B.).

Siehe std::complex, wo es Zugriffsfunktionen für die verschiedenen Darstellungen gibt.

class Velocity
{
private:
  /* ... */
public:
  double GetMPH() const;
  double GetKnots() const;
  double GetKMH() const;
};

Entsprechend Setter. In welcher Einheit die Klasse den Wert intern speichert ist Implementationssache. Der Getter/Setter für die entsprechende Einheit ist einfach, die restlichen müssen eben die Umrechung machen. Ein Performance-Unterschied zu den Umwandlungsfunktionen wird auch nicht erkennbar sein, wenn die "nativen" Getter/Setter inlined werden.

Ob man das bei jeder Größe mit verschiedenen Darstellungen in den verschiedenen Einheitensystemen machen möchte ist dann noch die Frage...

[witte]

Ich würde es davon abhängig machen ob Objekte benötigt werden deren Zustände gespeichert werden müssen. Ich empfinde globale Funktionen, vllt in einem separaten Namensraum nicht als unelegant, Teile der STL arbeiten z.B. so um die Kapselung der Container zu erhalten.

[knivil]

Nur das Funktionen nicht im Sinne der Objektorientierung sind.

Richtig erkannt! Dude, not every problem is an object.

Loesung: OOP nicht als Dogma betrachten.

[DarkGuardian]

knivil schrieb:

Nur das Funktionen nicht im Sinne der Objektorientierung sind.

Richtig erkannt! Dude, not every problem is an object.

Loesung: OOP nicht als Dogma betrachten.

Das tue ich ja auch nicht. Aber ich wollte mal wissen, ob jemand eine OOD-entsprechende Lösung hat, auf die ich nur noch nicht gekommen bin. Aber, wie ich schon vermutet habe, gibt es für das Problem keine direkte OOD-Lösung. Ich sehe das aber auch nicht als Problem, aber man ist ja doch neugierig, wie andere Entwickler darüber denken.

[;fricky]

DarkGuardian schrieb:

Das tue ich ja auch nicht. Aber ich wollte mal wissen, ob jemand eine OOD-entsprechende Lösung hat, auf die ich nur noch nicht gekommen bin.

schon mal an 'funktionsobjekte' gedacht? dabei sind funktionen auch objekte, die man wie andere objekte behandeln kann (z.b. als parameter an funktionen übergeben, usw).

[DEvent]

public interface Umrechnung extends Callable<Double> {
}

public class Km2Mile implements Umrechnung {

    private final double km;

    public Km2Mile(double km) {
        this.km = km;
    }

    public Double call() {
        return km * 0.621371192;
    }
}

public class Mile2Km implements Umrechnung {

    private final double mile;

    public Mile2Km(double mile) {
        this.mile = mile;
    }

    public Double call() {
        return mile / 0.621371192;
    }
}

main() {
    double km = 50;
    double mile = new Km2Mile(km).call();

    List<Umrechnung> liste = new ArrayList<Umrechnung>();
    liste.add(new Km2Mile(20));
    liste.add(new Mile2Km(20));

    for (Umrechnung u : liste) {
        sysout(u.call());
    }
}

Die Klassen sind "funktionsobjekte", halt ohne Operatorüberladung. Man kann später z.B. Km2Mile#call überschreiben, wenn sich die Umrechnung ändert (oder mit einem mehr präzisieren Wert).

[DarkGuardian]

Es gibt also doch noch einen Ansatz, auf den ich bisher nicht gekommen bin. Mal sehen, ob ich das so nutzen werde. Der einzige Nachteil dabei ist ja, dass man pro Umrechnung eine Klasse anlegt. Aber das kann verschmerzbar sein. Hängt halt von der Gesamtsituation ab.

Vielen Dank für den Hinweis.

[marmor kuchen]

da C++ sowieso nur stellenweise objektorientiert ist, sind globale Umrechnungsfunktionen auch kein Stilbruch, daher braucht man auch keine Verrenkungen zu machen und für eine einzelne Multiplikation bzw Division den ganzen OOP-Apparat hochfahren.

#define mile(km) (km * 0.621)
#define km(mile) (mile / 0.621)

anders wäre die Situation in einer reinen OO-Sprache, wo es nichts Anderes als Objekte gäbe, aber das steht ja nicht zur Debatte.

[Cox]

Igitt! Lasst doch bitte die Makros stecken...

[Icematix]

;fricky schrieb:

DarkGuardian schrieb:

Das tue ich ja auch nicht. Aber ich wollte mal wissen, ob jemand eine OOD-entsprechende Lösung hat, auf die ich nur noch nicht gekommen bin.

schon mal an 'funktionsobjekte' gedacht? dabei sind funktionen auch objekte, die man wie andere objekte behandeln kann (z.b. als parameter an funktionen übergeben, usw).

Du entäuscht mich.
Da bastelt jemand ein Objektorientiertes System um eine simple Multiplikation und von _dir_ kommt kein Flame

[rüdiger]

DarkGuardian schrieb:

Es gibt also doch noch einen Ansatz, auf den ich bisher nicht gekommen bin. Mal sehen, ob ich das so nutzen werde. Der einzige Nachteil dabei ist ja, dass man pro Umrechnung eine Klasse anlegt. Aber das kann verschmerzbar sein. Hängt halt von der Gesamtsituation ab.

Vielen Dank für den Hinweis.

Ich denke DEvent wollte nur zeigen, dass man nicht alles in einen OOP-Ansatz stopfen sollte. Der Code ist ja so ziemlich nutzlos und überladen und der Einsatz von Objekten macht ja gar keinen Sinn. Im OOP-Sinne ist er sogar fehlerhaft. Das umwandeln ist ja eine Aktion. Auch bei der OOP nutzt man freie Funktionen. Die Java-Leute haben zwar keine expliziten freien Funktionen eingeführt, weil man in den 90ern n bisschen verwirrt war was OOP betrifft. Aber die nutzen ja über statische Methoden an jeder Ecke im Endeffekt auch freie Funktionen. Ein Code wie der von DEvent ist ja eher ein DailyWTF. Wenn du schon Objekte einsetzen willst, dann nutze das lieber um die Werte mit Einheiten zu versehen.

@marmor kuchen
Nein, keine Macros. Dafür nimmt man doch sowohl in C als auch in C++ inline-Funktionen.

[;fricky]

Icematix schrieb:

;fricky schrieb:

DarkGuardian schrieb:

Das tue ich ja auch nicht. Aber ich wollte mal wissen, ob jemand eine OOD-entsprechende Lösung hat, auf die ich nur noch nicht gekommen bin.

schon mal an 'funktionsobjekte' gedacht? dabei sind funktionen auch objekte, die man wie andere objekte behandeln kann (z.b. als parameter an funktionen übergeben, usw).

Du entäuscht mich.
Da bastelt jemand ein Objektorientiertes System um eine simple Multiplikation und von _dir_ kommt kein Flame

er will doch unbedingt was oo-mässiges haben, warum sollte ich's ihm ausreden? ich persönlich würde auch einfach zwei makros nehmen (inline-funktionen für nur eine operation sind ziemlich sinnlos. der compiler wird sie immer auflösen, ob er nun für speed oder geringe codegrösse optimieren soll).

[Gast]

Funktionen. Dann kann man ggf. Überladungen anbieten. Makros haben ja, wie fricky schon erwähnt hat, hier keine Vorteile.