OOP this-Referenz als Konstruktor-Übergabe

[skummy]

Hallo,

mehr oder weniger eine Stil-Frage, da es (natürlich) funktioniert:

public class DataModule {

   // [...]

    public String getVersion() throws IOException {
	ModuleVersionHandler h = new ModuleVersionHandler(this);
	return h.getVersionHistory();
    }
}

Die erzeugten Objekte der Klasse DataModule enthalten Methoden, die notwendig sind um die Berechnungen der Methode "getVersionHistory()" der ModuleVersionHandler-Klasse durchzuführen. Also dachte ich mir, dass ich gleich das komplette Objekt der DataModule-Klasse übergebe, anstatt 4 Parameter.
Natürlich könnte ich auch die Berechnungen in der Klasse DataModule durchführen, aber diese Klasse soll eigentlich nur Daten zur Verfügung stellen und keine Berechnungen durchführen.

Kurzum:
Kann man sowas machen oder sollte man aus bestimmten Gründen, solche Konstrukte eher vermeiden?


Grüße

 

[Marcinek]

Ich würde das so machen.

Oder sogar eine Kopie dessen u.u.

 

[maki]

aber diese Klasse soll eigentlich nur Daten zur Verfügung stellen und keine Berechnungen durchführen.

Eine der Grundlagen der OOP ist, dass Daten & Funktionen die auf diesen Daten operieren zusammengehören, als Objekt.

Natürlich gibt es immer wieder Ausnahmen, in denen man diese Trennung eben doch will und damit prozedural programmiert, aber in OO Sprachen ist es nicht die Norm 😉

 

[Landei]

Richtig "sauber" ist das nur, wenn die aufgerufene Klasse ein Interface erwartet, und die aufrufende Klasse dieses implementiert. Ansonsten "weiß" die aufgerufene Klasse zuviel über aufrufende, d.h. du hast eine zu starke Kopplung.

Typisches Beispiel wäre ein Callback-Mechanismus:

public interface Callback {
   public void onSuccess(int result);
   public void onError(Exception ex);
}

public class Foo implements Callback {
   public Foo(int x, int y) {
      new AsynchCalculator(this,x,y).start();
   }

   public void onSuccess(Result result){ ...}
   public void onError(Exception ex){ ...}
   
}

public class AsynchCalculator implements Runnable {
    private final int x; 
    private final int y; 
    private final Callback callback;
 
    public AsynchCalculator(Callback callback, int x, int y) {
       this.x = x;
       this.y = y; 
       this.callback = callback;
    }
  
    public void start() {
       new Thread(this).start();
    }

    public void run() {
        try {
           callback.onSuccess(x/y);
        } catch(Exception ex) {
           callback.onError(ex);
        }
    }
}

 

[skummy]

Hmmm, okay. Ich persönlich halte von Interfaces in kleinen Projekten relativ wenig. Was es nützt mir, wenn ich zu jeder Klasse in Interface (IKlasse) erzeuge, das weiterhin nur angibt, was für Methoden die Klasse implementiert? Es existiert eh immer nur eine konkrete Implementierung zu der Klasse.

Der Mehraufwand und Nutzen, das Interface UND die Klasse zu erweitern, wenn ich eine neue Methode erstelle oder eine vorhandene anpasse, steht für mich in keinen positiven Zusammenhang. Ich muss immer zwei Dateien anpassen...das nervt.

Aber ich denke, dass hat nichts mit dem Thema hier zu tun.

Trotzdem danke für die Hinweise 🙂!

 

[SlaterB]

wenn du schon von Design und Stil und Konstrukt und ähnlich allgemein fragst,
ist es ein wichtiger ergänzender Hinweis, also genau passend hier im Thema,

dass für dich der Aufwand bisher den Nutzen nicht ausreichend schätzen läßt, ist ja legitim,
es gibt viele Ideen/ Details, du wählst die passenden

> Es existiert eh immer nur eine konkrete Implementierung zu der Klasse.

das gilt vielleicht bei dir in einem Fall, aber nicht im angesprochenen allgemeinen Konzept

 

[skummy]

Sehr richtig @SlaterB. Ich wollte nur mit meiner Antwort keine Grundsatzdiskussion über Interfaces auslösen.

 

[Marco13]

Hmmm, okay. Ich persönlich halte von Interfaces in kleinen Projekten relativ wenig.

Das wird sich noch ändern :hihi: (Spätestens, wenn eins dieser kleinen Projekte mal einen Hauch größer wird, und du dir denkst: "Ach Mist, hätte ich diese Klasse nur als Interface geschrieben" (umgekehrt habe ich das noch nie gedacht ... 😉)

Ich muss immer zwei Dateien anpassen...das nervt.

Abgesehen davon, dass man schon auf basis des Interfaces das meiste planen kann (und sollte) schafft eine moderne ID diese Anpassungen beim Refactoring automatisch.

 

[steffomio]

Das wird sich noch ändern :hihi: (Spätestens, wenn eins dieser kleinen Projekte mal einen Hauch größer wird, und du dir denkst: "Ach Mist, hätte ich diese Klasse nur als Interface geschrieben" (umgekehrt habe ich das noch nie gedacht ... 😉)

Das sollte man im voraus wissen, wie groß das Projekt mal werden wird. Ansonsten es kein Projekt mit fest gestecktem Ziel ist, sondern eine unkalkulierte Spielerei, nicht mal ein Experiment.