✔ Klasse nur mit Konstruktor

[mojitoweb]

Moin.

Ich habe weniger ein Problem als vielmehr eine Frage, ob es sich bei dem Folgendem um "sauberen" Programmierstil handelt.

Ich habe eine Klasse geschrieben, die nur eine Konstruktor, also keine weiteren Methoden beinhaltet. (Diese Klasse nutze ich sozusagen zur Initialisierung meines Programms)

Lege ich nun mit new eine Instanz dieser Klasse auf, wird ja natürlich die gleichnamige Methode (der Konstruktor) ausgeführt. Danach wird das Objekt nicht weiter genutzt. Da ich mit Eclipse arbeite spuckt dieses dann eine Warnung aus, da das Objekt nie benutzt wird. ("The local variable ... is never read")

Ich könnte dies natürlich umgehen, wenn ich den Konstruktor in eine 'normale' Methode umwandle und 'new' aufrufe.

Was würdet ihr als 'sauberen' Programmierstil verstehen? Oder hat jemand eine essere lösung?

mfg mo

 

[Matze]

Ich hab gelernt, dass bei einem sauberen Programmierstiel der Konstruktor zur Wertezuweisung dient.

 

[Adrian_Broher]

Danach wird das Objekt nicht weiter genutzt.

Wieso erstellst du überhaupt eine Objektinstanz, die dann sowieso nicht benutzt wird?

Edit:
Oh, ok. Die Frage ist eher was der Konstruktor macht? Welche logischen Funktionen setzt er denn um? Enthält er die Initialisierung des Objekts und die Ausführung einer andern Aufgabe? Falls das der Fall ist es nach meinem persönlichen Empfinden definitiv besser, wenn du pro Methode wirklich nur eine logische Funktion erfüllst. Kannst du den relevanten Codeteil posten? Also den Konstruktor und die Stelle an der das Objekt initialisiert wird?

 

[mojitoweb]

Ich benutze sie doch: beim Anlegen einer Instanz wird der Konstruktor ausgeführt, der dann zB ein Fenster aufruft und weitere Instanzen von anderen Objekten anlegt.

Edit:
Der Konstruktor kümmert sich um die Ein- und Ausgaben also Fenstererstelleng also inkl JFrame, JPanel, GLJPanel mit der einbindung der MouseMotion und MouseEvent

 

[shutdown]

Wieso erstellst du überhaupt eine Objektinstanz, die dann sowieso nicht benutzt wird?

Ich wette, du tust das auch

public class ProjectStarter {
    public ProjectStarter() {
        Model.init();
        View.init();
        Controller.init();
    }

    public static void main(String[] args) {
        new ProjectStart();
    }
}

 

[Adrian_Broher]

Ich wette, du tust das auch

public class ProjectStarter {
    public ProjectStarter() {
        Model.init();
        View.init();
        Controller.init();
    }

    public static void main(String[] args) {
        new ProjectStart();
    }
}

Da wette ich aber dagegen.

public class Application {
    private Application(String[] args) {
        this.parseArguments(args);
        this.model = new Model();
        this.view = new View(this.model);
        this.controller = new Controller(this.model, this.view);
    }

    private parseArguments(String[] args) {
        // ...
    }

    private void run() {
        this.view.run();
    }

    public static void main(String[] args) {
        Application application = new Application(args);

        Application.run();
    }
}

 

[waldjunge]

Ich weiß nicht genau, was deine Klasse macht, oder wozu du sie genau brauchst, aber hier mal ein Vorschlag von mir:

Erstell deine Klasse, pack deinen momentanen Inhalt des Konstruktors in eine Methode init() und ruf diese dann im Konstruktor auf.

So mach ich das oft, wenn ich mit swing arbeite und z.B. einer Klasse einige Buttons usw. "zuweiße".
Das macht meiner Meinung nach die ganze Sache etwas übersichtlicher.

 

[shutdown]

Da wette ich aber dagegen.

Na schön, hast gewonnen. Man kann natürlich immer alles anders machen. M,V,C sind aber im Normalfall alle Singleton, somit kannst du dir das Abspeichern in Variablen im Grunde schenken.

 

[Adrian_Broher]

M,V,C sind aber im Normalfall alle Singleton, somit kannst du dir das Abspeichern in Variablen im Grunde schenken.

Singletons sollten wenn möglich weitesgehend vermieden werden, da man an eine konkrete Klasse gebunden ist und man keine Interfaces benutzen kann. (Sowas sorgt fuer schlechte Testbarkeit, Erweiterbarkeit etcpp.)

Beispiel Testen: Wenn du eine Klasse testen möchtest, welche ein Singleton einer Datenbankverbindung benutzt musst du jederzeit zum testen die Datenbank mit den passenden Datensätzen bereithalten. Der Test muss Code enthalten, welcher Fehler, die durch das Datenbankverbindungs-Singleton abfangen und kein Bestandteil der ursprünglich zu testenden Klasse sind. (Verbindungsfehler, Timeouts usw). Bei einer Umsetzung als Interface kannst du für den Test diese einfach durch einen Mock ersetzen um nur die Klasse unter Test zu testen.

Ein interessanter Link um Thema Singleton:

http://blogs.msdn.com/scottdensmore/archive/2004/05/25/140827.aspx

 

[Oliver Gierke]

Wobei die Variante von Adrian sauberer ist, meiner Meinung nach. Ich vermute hinter Model, View und Controller stecken recht komplizierte Objekte. Daher ermöglicht diese "Dependency Injection zu Fuß" zumindest mal eine Testbarkeit, die bei statischen Methoden und ner Defaultsingletonimplementierung komplett ausfällt.

Du kannst ja trotzdem von den Objekten nur eine Instanz haben, auch wenn du sie mit new erzeugst. Nur liegt in Adrians Fall die Kontrolle der Anzahl der Instanzen bei der klasse Application, was eher dem Separation of Concerns entspricht.

Zusätzlich wäre es sinnvoll für Model View und Controller Interfaces einzuziehen um die testbarkeit weiter zu vereinfachen.

Gruß
Ollie