Laden...

Sinn von nicht instanziierbaren Klassen

Erstellt von Steinheimer vor 15 Jahren Letzter Beitrag vor 15 Jahren 4.487 Views
S
Steinheimer Themenstarter:in
2 Beiträge seit 2008
vor 15 Jahren
Sinn von nicht instanziierbaren Klassen

Hallo,

da ich mich leider noch nicht ganz so lange mit C# beschäftige, folgt von mir nun eine kleine Verständnis-Frage:

In einem Lehrbuch zu C# habe ich gelesen, dass man die Instanziierung von Klassen unterbinden kann, wenn man den parameterlosen Konstruktor mit einem private-Zugriffsmodifizierer überschreibt.

Meine Frage dazu: Was für einen Sinn hat es, wenn man eine Klasse entwickelt, diese aber nicht instanziieren bzw. kein konkretes Objekt daraus erstellen kann?

Danke schonmal für die Antworten.

4.221 Beiträge seit 2005
vor 15 Jahren

Das kann z.B: Sinn machen für:

  • Singleton-Pattern
  • Klassen welche nur statische Methoden enthalten.

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

2.082 Beiträge seit 2005
vor 15 Jahren

Hallo Steinheimer,

ich mache sowas auch ab und zu. Bsp in einer Klasse, die nur aus anderen (in der DLL enthaltenen Klassen) instanziieren will. Ich markiere dann den Constructor mit internal. So kann ich verhindern, dass Fremdanwendungen meine Klasse instanziieren.

Es ist toll jemand zu sein, der nichts von der persönlichen Meinung Anderer hält. - frisch-live.de

S
902 Beiträge seit 2007
vor 15 Jahren

häugif werden solche klassen auch als DataLayers benutzt! Da diese möglichst "zustandslos" sein sollten.

mfg
serial

C
401 Beiträge seit 2007
vor 15 Jahren

Es gibt auch Klassen, die nur per Klassenname.Create, oder ähnlichem instanziiert werden können.

edit: Wozu das allerdings genau gut ist weiss ich auch nicht.

4.506 Beiträge seit 2004
vor 15 Jahren

Hallo zusammen,

ein gutes Beispiel hierzu ist z.B. die System.Math Klasse. Diese ist nicht zu instanziieren und bietet nur statische Methoden, weil hier der Fokus auf Methoden gelegt wird.

Es macht keinen Sinn, um z.B. "Math.Round" aufzurufen erst eine Instanz erzeugen zu müssen.

Anderer Grund ist daas so genannte Singleton Pattern, hierzu fällt mir z.B. ein Anwendungsbeispiel ein: Applikationseinstellungen. Hier soll nur einmal eine Applikationseinstellungsklasse erzeugt werden und auch angesprochen werden. Weil es schlecht nachzuvollziehen ist, von wo aus die Einstellungen benötigt werden, und ob eine andere Stelle nicht schon die Einstellungen hat auslesen lassen, implementiert man diese Klasse als Singleton und sie verwaltet sich selbst, so dass sie nur einmal instanziiert wird.

Grüße
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

S
902 Beiträge seit 2007
vor 15 Jahren

Es gibt auch Klassen, die nur per Klassenname.Create, oder ähnlichem instanziiert werden können.

ber da haste dann schon eine instanz 😉

630 Beiträge seit 2007
vor 15 Jahren

Hallo Corpsgrinder,

Es gibt auch Klassen, die nur per Klassenname.Create, oder ähnlichem instanziiert werden können.
edit: Wozu das allerdings genau gut ist weiss ich auch nicht.

Dieses muster verwende ich zum beispiel oft wenn ich eine Klasse hab die eine Datei oder Daten zur instanzierung benötigt.


Customer.CreateFromXml("müller.xml"); 
Customer.CreateFromBinary("müller.bin");
Customer.CreateFromRaw(byte[] data);

In einem Konstruktor wäre das ziemlich unpraktisch da man nicht wüsste welcher Konstruktor welchen Zweck hat.

Im .NET Framework wird das z.B. in der Color-Klasse auch so gemacht (FromArgb, FromKnownColor, FromName,...)

Gruss
tscherno

To understand recursion you must first understand recursion

http://www.ilja-neumann.com
C# Gruppe bei last.fm

C
401 Beiträge seit 2007
vor 15 Jahren

@tscherno: Oh.. da hatte ich garnet dran gedacht. Danke dir!

3.971 Beiträge seit 2006
vor 15 Jahren

Wie das Corpsegrinder schon angesprochen hat, gibt es das Factory-Pattern. Als spezielles Beispiel wäre da XmlWriter genannt.

Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo Steinheimer,

um das nochmal klar zu sagen, auch wenn es aus den Beiträgen der anderen schon implizit hervorgeht:

In einem Lehrbuch zu C# habe ich gelesen, dass man die Instanziierung von Klassen unterbinden kann, wenn man den parameterlosen Konstruktor mit einem private-Zugriffsmodifizierer überschreibt.

Damit wird keineswegs das Instantiieren verhindert, sondern nur das Instantiieren auf die Klasse selbst beschränkt ... eben genau das private immer macht. Wenn die Klasse dann z.B. eine Create-Methode anbietet, können trotz des privaten Konstruktor auch Benutzer der Klasse neue Objekte erzeugen.

Wenn man will, dass eine Klasse nicht instantiiert werden kann, muss man das static-Schlüsselwort verwenden.

herbivore

J
1.114 Beiträge seit 2007
vor 15 Jahren

Es gibt auch Klassen, die nur per Klassenname.Create, oder ähnlichem instanziiert werden können.

ber da haste dann schon eine instanz 😉

Nein, nicht unbedingt. Die Create Methode kann statisch sein, und somit ohne Instanz aufgerufen werden. Diese statische Methode kann aber durchaus selbst eine Instanz der Klasse zurückliefern, indem sie z.B. einen als private deklarierten Konstruktor aufruft.

Diese statische Methodik sollte aber nicht zuweit getrieben werden, weil man sich dann schnell wieder in der alten globalen Programmierung zurückfindet, bei der man ganz ohne Klassen und Vererbung auskommen musste. Das ist leider eine von vielen Leuten, die noch aus der alten Welt kommen (Pascal, C usw.), in der es lediglich globale Prozeduren und Funktionen und Variablen gab. Weil die Umgewöhnung oftmals ein Hindernis darstellt (man muss ja schliesslich was neues sich aneignen), werden dann oft statische Klassen dazu missbraucht, wieder eine Art globale Prozeduren, funktioned und Variablen zu halten. Böse böse sowas, aber leider Alltag.

Ausserdem können statische Methoden nicht als virtuell deklariert werden und somit in abgeleiteten Klassen überschrieben werden. Der ganz OO Ansatz ist futsch und man schiesst sich selbst ins Knie, wenn man mal eine Klasse erweitern muss.

1.665 Beiträge seit 2006
vor 15 Jahren

Wenn man will, dass eine Klasse nicht instantiiert werden kann, muss man das static-Schlüsselwort verwenden.

Muss nicht unbedingt, :::

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo JunkyXL,

ich hatte noch überlegt, ob ich das schreibe. 🙂 Denn abstract ist sogar die eigentliche Ursache, die die Instantiierung verhindert. Denn static wird in nichts anders umgesetzt als abstract sealed. Trotzdem würde ich für eine Klasse, von der es keine Instanzen geben soll und die auch nicht als Oberklasse von Klassen dienen soll, von denen es Instanzen geben kann - und darum ging es hier ja wohl - ab .NET 2.0 immer static verwenden.

herbivore

S
Steinheimer Themenstarter:in
2 Beiträge seit 2008
vor 15 Jahren

Vielen Dank für die vielen Antworten und sehr guten Erklärungen! Hat mir sehr geholfen. 👍