[solved] Konzept gesucht: Elternklasse erweitern

Im Zusammenhang mit dem Gelaber im vorangegangenen Thread suche ich noch ein weiteres Konzept, mit dessen Hilfe ich mir ein bisschen Arbeit abnehmen kann.

Ich möchte android.location.Location um insgesamt vier Funktionen erweitern.
- Berechnung eines Locationstrings aus einer Location
- Berechnung einer Location aus einem Locationstring
- Berechnung eines Koordinatenstrings aus einer Koordinate
- Berechnung einer Koordinate aus einem Koordinatenstring
(Vielleicht auch noch eine Fünfte: Rückgabe des Locationstrings der aktuellen Location.)

Unter iOS hätte ich da die Möglichkeit der Kategorie. Die habe ich unter Java natürlich nicht.

Spontan fiele mir das Decorator Pattern ein, mit dessen Hilfe ich Location um ein paar Methoden erweitern kann.
Problematisch ist dann nur, dass ich mit einer eigenen Implementierung von Location arbeiten muss – da kann ich ja fast schon subclassen.

Ich möchte aber, dass jede android.location.Location meine Methoden beherrscht.
Wie gehe ich das an?

Zitat von matthias

Hoi,
hab ich dich jetzt richtig verstanden, du willst eine Klasse - die dir nicht gehört - erweitern. Direkt?

Exakt.

Zitat von matthias

Die Vererbung wurde nicht umsonst erfunden ... ich denke nicht, dass du dein Vorhaben ohne Vererbung realisieren kannst.

Die Vererbung ist kein Allheilmittel. Die Vererbung ist oftmals sogar ein Code Smell.
Nicht umsonst gibt es Ansätze wie das Decorator Pattern: wenn ich eine bestimmte Funktionalität nachreichen möchte, dann möchte ich nicht zwingend 700 Unterklassen erstellen müssen.

Nehmen wir als Beispiel 'Balzac Coffee' (Ich mag 'Starbucks' einfach nicht...):
Ich kann mir ja für jede Kaffeesorte eine Subklasse von 'Kaffee' erstellen, die dann auch die Eigenarten des Kaffees hat.
Muss aber der Kaffee an sich wissen in welche Bechergröße er kommt? Muss der Kaffee an sich wissen, ob er ein Sahnetopping bekommt? Muss der Kaffee an sich wissen, ob ein Aromasirup in ihn gekippt wird?
Nein.

Also statt jeder Kaffeesorte diverse Größen mitgeben zu wollen (und dann bei der Einführung des XXXS Bechers für Neugeborene 700 Sourcedateien anfassen zu müssen), erstellt man sich einen Dekorateur, der den Kaffee um die jeweilige Größe erweitert. Oder um das Topping. Oder um das Aroma.

Zitat von matthias

Java ist und bleibt nun mal streng typsicher, was auch seine Vorteile hat.

Das hat ja damit nichts zu tun.

Nur offenbar ist Java so starr, dass es nicht 'mal eben zur Laufzeit' Methoden an ein Objekt anheften kann.
(Objective-C kann. Objective-C kann noch ganz andere Dinge. Objekten zur Laufzeit die Klasse wegreißen, Objekten eine andere Klasse unterjubeln, Objekte einer Klasse durch Objekte einer anderen Klasse ersetzen…)

Ich werde dann mal ein bisschen was mit dem Dekorierer versuchen und meine Ergebnisse hier posten.

Mal für Interessierte zum Lesen, was genau so eine Kategorie eigentlich tut:
http://www.dpunkt.de/leseprobe…ategorien%20(Kap%207).pdf

Niemand 'verunstaltet' Deine Klasse.

Die Kategorie folgt dem Open Closed Principle: Offen für Erweiterungen, geschlossen für Änderungen.

Es kann Dir doch völlig egal sein, ob jemand deinem Additionsobjekt eine Methode zur Addition von echten Brüchen beifügt und nur für sich benutzt oder in seinem Code verteilt.
Es kann Dir hingegen nicht völlig egal sein, ob jemand in deinem Additionsobjekt den Konstruktor auf echte Brüche umbiegt.

Der Decorator tut in Etwa das, was ich haben möchte, wenngleich auf etwas anderem Weg. Inwieweit das jetzt deiner Library schaden kann verstehe ich nicht.