Verwendung von Konstruktor

[guguli]

Hallo zusammen,

ich hab folendes Vorhaben:
ich will aus der Kosntruktor einer Klasse die Konstruktor einer anderen Klasse aufrufen, in der Methoden in der klasse aufgerufen werden.
Aber so erstelle ich ja immer ein Objekt das ich eigentlich nicht benutze.
Was ist der schönere Weg um sowas zu erstllen.

Code :

public class A {
    public A(Set<Activity> tSelectedActivitiesSet, Activity activityInNode, Activity activityOutNode) {
            B b= new B(tSelectedActivitiesSet, activityInNode, activityOutNode);
    }
}

public class B {
    public B() {
        methode1();
        methode2();
    }
}

 

[Joose]

Warum stehen diese Methoden überhaupt in Klasse B, wenn du die Methoden aus Klasse A ausgeführt haben willst? Und du du die Klasse B anscheinend nur dafür brauchst?
Natürlich könntest du die Objekte der Klasse "B" cachen und darauf zurückgreifen wenn du eines brauchst

 

[guguli]

Also klasse B ist eine Helper class, sie behält viele Methoden die alle in einer Reihnfolge aufegrufen werden müssen. Ich wollte nicht dass meine Klasse A deswegen zu groß wird.

 

[Saheeda]

@guguli

Von wie vielen Zeilen Code reden wir?

Wie eng ist die Beziehung zwischen Klasse A und den Hilfsmethoden? Gibt es einen logischen/semantischen Zusammenhang? Dann würde ich diese auch nicht in eine Hilfsklasse auslagern. Kannst du vielleicht ein konkreteres Beispiel geben als A und B?

Wenn ich z.B. eine Klasse "Memory" habe, landen Methoden wie "save", "reset", "load" o.ä. alle in dieser Klasse. Wenn sie dadurch etwas größer wird, finde ich das in dem Fall auch nicht so schlimm, da es ja alles logisch zusammen hängt.

Wenn es dann auch noch auf die richtige Reihenfolge ankommt, würde ich eine "start" - Methode machen, welche public ist und die Untermethoden aufruft, die restlichen kleinen Methoden private. So bleibt gesichert, dass alle Methoden immer in der richtigen Reihenfolge ausgeführt werden.

 

[buggy84]

Auch wenn viele Informationen fehlen, Saheeda hat das bereits umrissen, wäre eventuell "static" ein Zauberwort für dich. Das kommt aber auf den Sinn und Zweck deiner Helferklasse an und da wir ja den Kontext zu deinem Programm nicht kennen, könnte "static" auch durchaus nicht in Frage kommen. Aber man prüfe.

edit: Liege ich falsch, ober würde ein nicht (mehr) benutztes Object nicht sowieso dem Garbage Collector zum Opfer fallen!?

 

[stg]

Mal ungeachtet der bisherigen Anmerkungen:

Ein Konstruktor dient dazu ein Objekt zu erstellen und sonst nichts. Instanzmethoden sollten (wenn überhaupt) nur sehr eingeschränkt genutzt werden (Überschreibbare Methoden sollten dort z.B. gar nicht aufgerufen werden usw..).
Auch den Aufruf des zweiten Konstruktors im ersten sehe ich bereits kritisch.

Wenn die Konstruktion deines Objekts so kompliziert ist, dann bediene dich einer Factory zum Erstellen und schränke den Konstruktor-Zugriff ein. (Oder überdenke dein Klassen-Design nochmal. In den meisten Fällen gibt es einfachere Lösungen. Möglicherweise willst du schlicht zu viel "auf einmal" machen)

 

[guguli]

-Ich find die Idee mit einer Start methode anzufangen ist es schön.
-Also die Klasse A erstellt ein Command, das später ausgeführt wird aber erst wenn alle in B vorhandene Methoden abgearbeitet sind.
-Ich weiss nicht in wie weit static dann mir hilfreich sein kann?!?!?

THX

 

[buggy84]

Na wenn Du es nicht weißt, dann wird's Dir sicher auch nicht helfen.

 

[JStein52]

Nach dem bisher gesagten wäre "static" für die Helper-Klasse angebracht. Dann brauchst du keine Instanz von B zu erzeugen. Und dann noch mit der o.g. start(....) - Methode in B kombiniert wäre alles gut. Wenn sich dann z.B. mal die Anzahl oder Reihenfolge der Aufrufe in B ändern sollte ist die Klasse A davon nicht betroffen. (So wie du das mit dem Konstruktor wohl gedacht hattest, was aber wie stg dir erklärt hat etwas "pfui" ist.)