Gleiche Methode in 2 verschiedenen Klassen - Lösung ?

[jhjh]

Hallo,
ich habe 2 Klassen und bei beiden Klassen verwende ich exakt die selbe Methode (Methode gibt einen String zurück). Ich frage mich wie es am "elegantesten" wäre, dass ich die Methode nur einmal definieren muss. Meine Überlegung ist, dass ich eine weitere Klasse erstelle, in der ich nur diese Methode definiere auf die dann die anderen Klassen zugreifen können. Kann man generell eine "Methoden-Klasse" erstellen, in der ich dann alle Methoden reinpacke, die ich mehrmals definieren müsste ? Schlechte Idee ?
Wie ist es eigentlich wenn ich eine Methode mit selben Parametern von verschiedenen Klassen aufrufe und sich der Algorithmus, abhängig davon von welcher Klasse die Methode aufgerufen wird, ein wenig ändert ? Bisher habe ich so gelöst, dass ich einen weiteren Parameter gesetzt habe über disen ich dann erkennen konnte von welcher Klasse die Methode aufgerufen wurde und ich dann mit Fallunterscheidungen entweder den einen oder den anderen Weg einschlagen konnte...

Ich bedanke mich! =)

 

[mihe7]

Kann man generell eine "Methoden-Klasse" erstellen, in der ich dann alle Methoden reinpacke, die ich mehrmals definieren müsste ? Schlechte Idee ?

Ja und ja. Was macht die Methode denn?

Wie ist es eigentlich wenn ich eine Methode mit selben Parametern von verschiedenen Klassen aufrufe und sich der Algorithmus, abhängig davon von welcher Klasse die Methode aufgerufen wird, ein wenig ändert ?

Strategy-Pattern.

 

[Robat]

ich habe 2 Klassen und bei beiden Klassen verwende ich exakt die selbe Methode (Methode gibt einen String zurück).

Eventuell wäre ein Interface mit default-Methode eine Idee. Oder eben Oberklasse - je nach Usecase

 

[jhjh]

So, hatte leider private Schwierigkeiten und kann deswegen erst jetzt antworten...

Was macht die Methode denn?

Ich habe z.B. eine Funktion die mir den letzten Sonntag in einem Monat als Integer zurück gibt.

public Integer LastSunday(int monat, int jahr) {
    int letzterTag;
   int anzahlTageImMonat = getAnzahlTageImMonat(monat, jahr);
    Integer letzterSonntagImMonat;
    Calendar cal = new GregorianCalendar();
    cal.set(Calendar.DATE, 1);
    cal.set(Calendar.MONTH, monat);
    cal.set(Calendar.YEAR, jahr);
    cal.set(Calendar.DAY_OF_MONTH, anzahlTageImMonat);
    letzterTag = cal.get(Calendar.DAY_OF_WEEK);
    if (letzterTag == 1) {
        letzterSonntagImMonat = anzahlTageImMonat;
    } else if (letzterTag == 2) {
        letzterSonntagImMonat = anzahlTageImMonat - 1;
    } else if (letzterTag == 3) {
        letzterSonntagImMonat = anzahlTageImMonat - 2;
    } else if (letzterTag == 4) {
        letzterSonntagImMonat = anzahlTageImMonat - 3;
    } else if (letzterTag == 5) {
        letzterSonntagImMonat = anzahlTageImMonat - 4;
    } else if (letzterTag == 6) {
        letzterSonntagImMonat = anzahlTageImMonat - 5;
    } else {
        letzterSonntagImMonat = anzahlTageImMonat - 6;
    }
    return letzterSonntagImMonat;
}

Diesen Wert brauche ich in mehreren Klassen. Habe es jetzt so gelöst, dass ich eine neue Klasse erstellt, welches über diese Methode verfügt. Gibt es von der Konvention her irgendeinen Klassennamen wie man eine "Methoden-Klasse" nennen kann ?
Generell habe ich die bisherigen Methoden dort "reingepackt" wo sie hingehören. So habe ich beispielsweise eine Geo-Klassen, die neben den Klassenvariablen, sämtliche Methoden (Distanzberechnung zwischen 2 Punkten, umwandeln von Adressen in Geo Daten etc..., bereit hält.
ABER habe dann halt noch Methoden, die ich keiner Klasse zuordnen könnte! Die würde ich dann halt in einer neuen Klasse (Sonstige Methoden) packen.

 

[mihe7]

Was Du meinst sind sog. Utility-Klassen, für die es tatsächlich eine Art Namenskonvention gibt und zwar in der Form, dass der Name auf Utils endet. Das ist aber kein besonders gutes Vorgehen, weil es im Endeffekt bedeutet, dass man keine andere Idee hatte (was übrigens teilweise wirklich nicht einfach ist).

Unabhängig davon: verwende die Time API. Das macht einiges einfacher.

Auf die Schnelle wäre mir jetzt eingefallen (ungetestet):

public class MonthYear {
    private YearMonth yearMonth;

    public MonthYear(int month, int year) {
        yearMonth = YearMonth.of(year, month);
    }

    public int lastInMonth(DayOfWeek dow) {
        return yearMonth.atDay(1).
            .with(TemporalAdjusters.lastInMonth(dow))
            .getDayOfMonth();
    }

    public static int lastSunday(int month, int year) {
        return new MonthYear(month, year).lastInMonth(DayOfWeek.SUNDAY);
    }
}

 

[mrBrown]

Was Du meinst sind sog. Utility-Klassen, für die es tatsächlich eine Art Namenskonvention gibt und zwar in der Form, dass der Name auf Utils endet. Das ist aber kein besonders gutes Vorgehen, weil es im Endeffekt bedeutet, dass man keine andere Idee hatte (was übrigens teilweise wirklich nicht einfach ist).

Oder die "Plural-Variante" wie Objects, Collections, Strings, finde ich persönlich schöner

 

[jhjh]

Was Du meinst sind sog. Utility-Klassen, für die es tatsächlich eine Art Namenskonvention gibt und zwar in der Form, dass der Name auf Utils endet. Das ist aber kein besonders gutes Vorgehen, weil es im Endeffekt bedeutet, dass man keine andere Idee hatte (was übrigens teilweise wirklich nicht einfach ist).
[/code]

Alles Klar, dann weiß ich erstmal bescheid. Ja ich sitze gerade vor meinem ersten etwas größerem Projekt, bei dem ich schon ca. ein halbes Jahr dran arbeite und jetzt eigentlich auch schon fast fertig bin. Habe dann im laufe der Entwicklung bemerkt, dass ich an manchen Sachen etwas "umständlich" herangegangen bin. Mit war es dann in dem Moment erstmal wichtig etwas zum laufen zu bringen anstatt schönen Code bzw. schön strukturierten Code zu schreiben Naja wenn ich fertig bin muss ich evtl. paar Sachen nochmal abändern und schöner machen

 

[mrBrown]

Mit war es dann in dem Moment erstmal wichtig etwas zum laufen zu bringen anstatt schönen Code bzw. schön strukturierten Code zu schreiben

Aus Erfahrung führt letzteres nebenbei auch schnell zu erstem, durchaus auch schneller, als sich nur auf ersteres zu konzentrieren.

 

[jhjh]

Aus Erfahrung führt letzteres nebenbei auch schnell zu erstem, durchaus auch schneller, als sich nur auf ersteres zu konzentrieren.

Ja das mag gut sein Aber gerade als Neuling fehlt einem das Wissen, wie man bei bestimmten Problem am besten herangehen kann. Da stellt sich dann auch nicht immer die Frage ob es hier eine bessere Lösung gibt, sondern man geht dann davon aus, dass das SO eine übliche Vorgehensweise ist und man hinterfragt sich das nicht ^^
Aber gut, beim nächsten Projekt werde ich bei manchen Dingen schon wissen, wie man die besser lösen könnte und werde die Fehler die ich aus dem alten Projekt gemacht habe, gleich von beginn vermeiden können. Zumindest bei den "Fehlern" die mir bekannt sind