| 

.NET C# Java Javascript Exception

1
Hallo Allerseits,
kurze Frage: Variablen im Konstruktor instanziieren oder direkt bei der definition? Was bevorzugt ihr und warum?

Public Class ModuleController
Inherits WorkItemController

Private ReadOnly _defaultListViewConfiguration As new DefaultListViewConfiguration

oder

Public Sub New()
_defaultListViewConfiguration = New DefaultListViewConfiguration
End Sub


Ich habe bisher die erste Variante bevorzugt. Ein Kollege erzählte mir gerade das er in der Ausbildung gelernt hat derartige Variablen immmer im Konstruktor zu initialisieren.
11.07.2013
Thomas Sczyrba 1,4k 1 2 9
3 Antworten
2
Wie die meisten solcher allgemeinen Fragen ist auch diese schon bei stackoverflow diskutiert worden (und nicht nur einmal - siehe rechts den related-Abschnitt).

Mit der akzeptierten Antwort in der verlinkten Frage kann ich gut leben und mache es in der Regel auch so. Vor allem aber stellt sich die Frage für mich relativ selten, denn wenn ich schon mal ein Feld auf etwas anderes als den Default-Wert des Typs initialisieren muss, so gibt es oft auch einen Konstruktor, der es erlaubt, dieses Feld mit einem Parameter zu initialieren. Und ein "new ..." für das Erzeugen einer Abhängigkeit versuche ich meist durch Dependency Injection zu vermeiden. Bleibt oft nur das Initialisieren interner Container (Listen etc.), für das ich new brauche. Und das hängt gern mal von einem Parameter ab (z.B. Größe) - in Summe hab ich also die Initalisierungen doch eher im Konstruktor (ohne damit Regel 2 aus der verlinkten Antwort widersprechen zu wollen).

Ein Punkt, der manchmal wichtig ist: wenn ich den Init-Wert aus einem Methodenaufruf beziehen muss, der eine Exception werfen kann, die ich behandeln will - dann bleibt nur die Konstruktor-Variante. (Dazu gehört als Spezialfall auch die "new ..."-Variante, auch wenn Konstruktoren normalerweise keine Exceptions werfen sollten.)
11.07.2013
Matthias Hlawatsch 13,2k 4 9
1
Ich persönlich bevorzuge die Initialisierung im Konstruktor. Typischerweise lege ich in einen solchen Fall das Objekt meist mit speziellen Attributen bereits an.
Ebenso typisch verwenden wir häufig für den parameterlosen Konstruktor die Einschränkung Private und stellen Konstruktoren mit Parametern als Public zur Verfügung. Wir programmieren unter ASP.NET mit einem Framework und hier muss ich meist sowieso die Sitzungsinformationen als Objekt übergeben.

FAZIT: Ich halte es für sauberer, Initialisierungen im Konstruktor durchzuführen, denn dafür ist der Konstruktor (nach meinem Verständnis) ja da.
11.07.2013
edvservice 1,4k 1 6
1. Wofür verwendet ihr für den parameterlosen Konstruktor die Einschränkung Private?

2. Kannst Du ein Beispiel für deine "speziellen Attribute" in diesem Zusammenhang geben?
Thomas Sczyrba 11.07.2013
Der private parameterlose Konstruktor wird von uns dann eingesetzt, wenn das Objekt einen Parameter für seine korrekte Funktion benötigt.
Entsprechend wenige Klassen gibt es bei uns, die einen parameterlosen Konstruktor haben und wir haben uns deshalb angewöhnt, diese Objekte immer im Konstruktor bereitzustellen. Syntaktisch wäre natürlich eine Initialisierung bei den Attributen möglich - aber wir machen das eben nicht ;-)
edvservice 11.07.2013
1
Es gibt ein entscheidendes Problem wenn wenn statische Variablen bei Definition instanziert.
Und zwar stürzt das Programm sofort nach Programmstart ab wenn bei der Instanzierung ein Fehler auftritt. Man hat keine Möglichkeit die Exception zu fangen, zu loggen oder informationen zu der Exception zu erhalten.

Beispiel:

public static class Demo{
public static int c = int.Parse("a"); //good by programm
}
11.07.2013
Floyd 14,6k 3 9
Das ist richtig, aber gefragt war ja nach der Alternative "Konstruktor" und damit (implizit) nach Member-Variablen. Das Initialisieren einer statischen Variable in einem Konstruktor ist schließlich ein no no no no.....
Matthias Hlawatsch 11.07.2013

Stelle deine .net-Frage jetzt!