Objekt weiterreichen oder statische Klasse anlegen?

hi spezialies,

mal wieder ne konzeptionelle frage:

ich habe eine klasse gebaut namens Messenger, die so Sachen übernimmt, wie alle möglichen nachrichten an alle möglichen Ziele zu verteilen, z.b. logfiles schreiben, gravierende anwendungsfehler an leute vermailen, windows event log schreiben usw. usw.
natürlich dient der messenger damit an vielen punkten meiner anwendung auch als protokollant (z.b. in der logdatei), ob irgendwas geklappt hat oder nicht, so eine art debugger im produktivbetrieb...

aus diesem grund muss natürlich so ziemlich jede selbst geschriebene klasse meiner anwendungen den messenger kennen.

dies wiederum führt dazu, dass

1. jede klasse die klasse messenger einbinden und auf sie verweisen muss
2. jede klasse der anwendung im konstruktor oder später den messenger übergeben bekommen muss.

punkt zwei könnte man sich meiner meinung nach sparen, wenn der messenger statisch ist.

ist der messenger damit ein idealer kandidat für eine statische klasse oder bleibt man aus gründen der objektorientierten philosophie lieber bei der aktuellen vorgehensweise ?

danke für eure meinung

ron

also um mir die arbeit zu erleichtern würde ich ihn als singelton deklarieren aber eigendlich ist deine bisherige vorgehensweiße die Objekt orientiertere

Also ich würde das Teil static machen..... Hier macht dies durchaus Sinn..... Allenfalls ein Singleton würde auch noch Sinn machen ....

static geht ja erst ab 2.0 kommt also auch darauf an

Original von S.H.-Teichhof
static geht ja erst ab 2.0 kommt also auch darauf an

Ich meinte auch die Methodensignaturen.... also lauter statische Helper-Funktionen

hi leute,

da sieht man´s mal wieder, hätte mich dochmal mit design patterns beschäftigen sollen.

hab mir beispielcode dazu mal angeguckt und glaube, dass der singleton eine gute idee ist, danke.

wenn ich´s richtig verstanden habe, würde jede klasse dann zwar seinen "eigenen" messenger instantieren müssen, aber weil´s ein singleton ist, kommt immer das gleiche objekt zurück, oder?

Hallo citizen.ron,

weil jeden Klasse immer dasselbe (nicht nur das gleiche) Messenger-Objekt zurückbekommt, wird eben gerade kein neues Messenger-Objekt instanziiert (nur das eine einmal zu Beginn).

Aber ich würde kein Singelton verwenden, sondern statische Methoden verwenden, d.h. ich würde nicht nur, sondern habe das bei meiner Messenger-Klasse (heißt übrigens bei mir genau so) so gemacht.

herbivore

Hallo citizen.ron,

ich benutze in so einem Fall meistens eine Singleton Klasse bzw. Klassen. Vor allem bei dem Beispiel einer Logdatei.

Das letzte Mal, als ich eine Logging-Klasse (xml) implementiert habe, habe ich das auch als Singleton gemacht. Die Klasse habe ich dann direkt bei Programmstart instanziiert, so dass das Objekt vorhanden ist und dann kann man problemlos und schnell in jedem Winkel des Programms drauf zugreifen.

Gruß,
Fabian

Hallo zusammen,

kann mir einer der Singelton-Anhänger mal den Vorteil gegenüber static erklären?

herbivore

Singleton ist ideal für Leute die sich nicht bewusst sind, dass man auch einen statischen Constructor schreiben kann 😜 😉

hey herbivore,

kann mir einer der Singelton-Anhänger mal den Vorteil gegenüber static erklären?

genau die gleiche frage hätte ich jetzt als nächstes auch gestellt.

schließlich spart man sich bei static zusätzlich noch den aufruf der Konstruktoren in allen klassen und programmierer sind schließlich code ökonomen... 😁

Original von citizen.ron

schließlich spart man sich bei static zusätzlich noch den aufruf der Konstruktoren in allen klassen und programmierer sind schließlich code ökonomen... 😄

Beim Singleton gibt es auch keinen public Constructor... nur einen private Constructor und eine public GetInstance-Methode

Nimm doch einfach einen fertigen Logger. Z.B. die log4j-Portierung Apache log4net.

Benutzt wird log4net so:

public class MyClass {

   // Statische Logger-Instanzen.
   private static ILog log = LogManager.GetLogger(typeof(MyClass));
   private static ILog mailer = LogManager.GetLogger("mailer");

   // Methode, die die Loggers benutzt.
   public void DoSomething() {

      try {
         log.Debug("Debug");

      } catch(Exception ex) {
         log.Error(ex);
      }

      if(seriousError) {
         mailer.Fatal("Serious Error");
      }
   }
}

Die Konfiguration der Logger erfolgt entweder irgendwo bei Programmstart oder wird in einer Xml-Config-Datei hinterlegt. Statt der zwei Logger log und mailer könnte man die Konfiguration auch so anpassen, dass z.B. alles standardmässig in eine Datei geloggt wird, aber ab Stufe fatal auch Mails versendet werden.

Geloggt wird in die sogenannten Appenders - Log-Ziele. Das kann alles mögliche sein, z.B. Mail, Datenbank, Datei, Console, Application Event Log usw. (siehe: log4net-Features). Was genau geloggt wird - Datum, Uhrzeit, Quelle, Meldung usw. - wird in der Appender-Konfiguration per Format-String festgelegt.

@herbivore: am Code-Beispiel sieht man auch den Vorteil von Singletons, gegenüber Klassen, deren Methoden komplett statisch sind. Mit Singletons kann es mehrere Logger-Implementierungen geben und die Anwendung muss nicht wissen welchen sie verwendet. Mit statischen Methoden bräuchte man z.B. einen FileLogger und einen MailLogger, die fest in der Anwendung verdrahtet sind. Auch wäre es nicht möglich zwei verschieden konfigurierte FileLoggers gleichzeitig zu verwenden, falls das mal notwendig sein sollte.

Gruss
Pulpapex

Hallo zusammen!

Ich würde sagen, wenn die Instanziierung von Klassen viel Speicher ausmacht, dann würde ich auf Singletons zurückgreifen. Oder aber wenn die Klasse nur unter bestimmten Voraussetzungen wirklich benötigt wird, dann würde ich ebenfalls aus Speichergründen Singletons anwenden, statt statische Konstruktoren.

Prinzipiell ist es nur eine Frage des Geschmacks.

Was mich jetzt interessieren würde, ob es irgendwie möglich ist aus einer statisch definierten Klasse mehrere Instanzen zu erzeugen, dann wäre ja der Fall klar. Aber ich wüsste nicht ob das überhaupt geht?

Ciao
Norman-Timo

Hallo Pulpapex,

Debug.WriteLine zeigt doch, dass diese Flexibilität ohne weiteres auch bei den statischen Methoden vorhanden ist. Ich halte es beim Lögging eher für einen Nachteil, wenn die einzelne Klasse durch GetLogger bestimmen kann, wohin sie logged. Zumindest widerspricht das meinem Ansatz, ein möglichst anwendungsweit einheitliches und konsistentes Logging zu erreichen.

Hallo norman_timo,

das muss aber schon sehr viel Speicher sein, damit sowas heutzutage einen Unterschied macht. Davon abgesehen können auch die statischen Methoden intern mit Objekten arbeiten, die nur allokiert werden, wenn sie benötigt werden.

Was mich jetzt interessieren würde, ob es irgendwie möglich ist aus einer statisch definierten Klasse mehrere Instanzen zu erzeugen

Jede Klasse gibt es nur einmal. Instanzen von Klassen kann man in C# gar nicht erzeugen. Dazu müsstest du zu Smalltalk wechseln, wo Klassen selbst wieder Objekte sind.

herbivore

Hallo,

Original von herbivore
kann mir einer der Singelton-Anhänger mal den Vorteil gegenüber static erklären?

ein Singleton ist besonders praktisch, wenn:

• es ein Interface implementiert und dadurch an anderen Code weitergegeben werden kann. Also bspw. ILogger in diesem Fall. So kann man für vorhanden Code einen beliebigen Logger verwenden, aber dieser wird nur genau einmal erstellt. (In diesem Fall ist das ja genau unerwünscht, denn man müsste die Singletoninstanz immer mitübergeben)

oder

• das Singleton erweiterbar ist. Ist diesem Fall müssen Konstruktor und instance-Variable protected sein. So könnte man nach ner Weile einfach eine Subklasse erstellen, meinetwegen WebserviceMessenger, welcher die Logs an einen Webservice weiterleitet. Bei Applicationsstart wird dann einfach einmal WebserviceMessenger.Instance aufgerufen und danach geben alle Messenger.Instance aufrufe die neue Instanz zurück und die Applikation arbeitet mit dieser, ohne noch irgendwo Code geändert zu haben.
  (@citizen.ron: Deine Messenger-Klasse klingt ja recht praktisch. Stell dir jetzt vor du benutzt sie auch in anderen Projekten. In einem Projekt willst du aber noch Funktionalität hinzufügen. Einfach die Klasse ändern ist nicht möglich, denn das beeinflusst alle Projekte.)

Ich persönlich verwende sehr gern Singletons, aus beiden obengenannten Gründen, die natürlich perfekt kombinierbar sind. Selbst wenn es noch gar nicht absehbar ist, dass man das mal benötigt. Es ist schließlich (fast) kein Mehraufwand ein Singleton zu erstellen und benutzen.

Statische Methoden benutz ich aber auch oft, allerdings nur für Sachen wie CalculateBlabla, ConvertBla, usw. Also Kontextunabhängige Dinge.

Statische Konstruktoren kenn ich auch 😉. Benutz ich aber eigentlich nur um readonly-Variablen zu füllen, o.ä.

Wenn man aber (nichtkonstante) statische Variablen hat, sollte man schon stark nachdenken, ob man nicht lieber ein Singleton draus machen sollte.

So viel zum Thema Singletons. Aber nun noch kurz zum eigentlichen Problem. Du solltest dir erstmal überlegen, ob dir wirklich EINE Instanz reicht. Denn selbst mit einem Singleton bist du daran gefesselt. Könnte es bspw. passieren dass verscheidene Klassen in verschiedene Logfiles und/oder nur einige in die Windowseventlogs schreiben sollen. Oder ob sich noch andere Aufspaltungen ergeben. Wenn ja dann wäre vl. eher ein Observeransatz passend. D.h. du hättest verschiedene Observer: für Logfile u.ä. Und deinen Klassen die es betrifft fügst du alle gewünschten hinzu. Du könntest z.B. ein Interface Loggable erstellen, welches einfach nur ein Event hat. So wäre auch für alle Klassen der Logging aufruf gleich und du wärst erheblich flexibler.

So viel auch gleich zum Thema Wie designed ihr?. Man sollte gleich richtig planen, um am Ende so flexibel wir möglich und nötig zu sein. 🙂

cu, tb

Hallo Pulpapex,

ergänzend zu meinen Anmerkungen weiter oben, ist mir nach dem Lesen des Singelton-Kapitels im GoF-Buch aufgefallen, dass das von dir geschilderte Vorgehen nicht dem Singleton-Pattern entspricht, weil es eben mehrere Logger-Objekte parallel geben kann. Bei der GoF wird auch bei mehreren Unterklassen der Singleton-Klasse nur genau ein einziges Objekt nach außen zur Verfügung gestellt. Singleton eben.

Dann ist aber für mich endgültig jeglicher Vorteil von Singletons gegenüber statischen Methoden geschwunden, weil ich bei Singeltons immer stumpf messenger.TueWas () statt Messenger.TueWas () schreiben muss, nur dass man sich eben zusätzlich mit der (statischen?) Variable messenger rumschlagen muss. Oder ich verzichte auf diese Variable und scheibe immer Messenger.Exemplar.TueWas (), was die Sache auch nicht besser macht.

Auf der anderen Seite verhindert Messenger.TueWas () ja nicht die Konfigurierbarkeit des Logging (Ziel, Art, Umfang). Hier sei nochmal auf Debug.WriteLine verwiesen.

herbivore

Ein Singleton kann auch in folgendem Szenario Sinn machen ...

Es darf nur eine Instanz geben / diese wird je nach Konfiguration lokal oder Remote (Remoting) erstellt....

Hallo Herbivore!

Jede Klasse gibt es nur einmal. Instanzen von Klassen kann man in C# gar nicht erzeugen. Dazu müsstest du zu Smalltalk wechseln, wo Klassen selbst wieder Objekte sind.

Ja, ich wollte eigentlich fragen, ob es möglich ist, aus statisch definierten Klassen, mehrere Objekte zu generieren, aber das würde mehr oder weniger dem "statisch" widersprechen.

Ciao
Norman-Timo

Hallo norman_timo,

dann verstehe ich wohl immer noch nicht, was du meinst. In C# ist eine Klasse eine Klasse und ein Objekt ein Objekt. Jede Klasse gibt es genau einmal, Objekte zu einer Klasse kann es beliebig viele geben, mal abgesehen davon, dass die Klasse die Anzahl ihrer Objekte z.B. durch den Singleton-Pattern beschränken kann.

Durch static sagt man, dass das Member (Variable, Methode, Eigenschaft, Ereignis) der Klasse gehören soll, ohne static hat jedes Objekt das Member je einmal (für Variablen werden mir da wohl alle zustimmen, aber abstrakt sehe ich das auch z.B. für Methoden so).

Da es jede Klasse nur einmal gibt, gibt es statische Variablen entsprechend auch nur einmal. Nicht statische Variablen gibt es einmal pro Objekt.

Unter 1.1. kann man ja keine Klassen statisch definieren, sondern nur für jedes Member einzeln entscheiden, ob es statisch ist oder nicht - mit den eben beschriebenen Auswirkungen.

Natürlich kann man auch zu Klassen, die statische Member enthalten, Objektinstanzen erzeugen - vorausgesetzt es ist (explizit oder implizit) ein nicht statischer Konstruktor vorhanden und zugreifbar (also public oder protected, wobei im zweiten Fall die Objekterzeugung dann nur in den Unterklassen möglich ist).

Oder meintest du eine ganze Klasse static definieren, wie das ab .NET 2.0 geht?

A class can be declared static, indicating that it contains only static members. It is not possible to create instances of a static class using the new keyword.

Static classes and class members are used to create data and functions that can be accessed without creating an instance of the class. Static class members can be used to separate data and behavior that is independent of any object identity [...]. Static classes can be used when there is no data or behavior in the class that depends on object identity.

herbivore

Hallo Herbivore!

Also gut ich versuche das mal in Code auszudrücken, was ich meine, und damit teste ich gleichzeitíg ob´s überhaupt geht:

using System;

namespace TestConsoleApp
{
	class Startklasse
	{

		#region Main Entry Point

		[STAThread]
		public static void Main()
		{
			Teststatic myObj1 = new Teststatic();
			Teststatic myObj2 = new Teststatic();

			// Ist dieser Vergleich richtig?
			if ( myObj1.Equals(myObj2) )
			{
				Console.WriteLine("Vgl1: Das gleiche Objekt!");
			}
			else
			{
				Console.WriteLine("Vgl1: Unterschiedliche Objekte!");
			}

			// Oder ist dieser Vergleich richtig?
			if (myObj1 == myObj2)
			{
				Console.WriteLine("Vgl2: Das gleiche Objekt!");
			}
			else
			{
				Console.WriteLine("Vgl2: Unterschiedliche Objekte!");
			}

			Console.ReadLine();
		}

		#endregion

	}

	#region Teststatic-Klasse

	public class Teststatic
	{
		static Teststatic()
		{
		}
	}

	#endregion
}

Ergebnis: Beides Mal wären es untersch. Objekte??

Also dann kann ich doch nur sagen, dass es durchaus eklatante Unterschiede zw. Singleton und Static gibt, oder habe ich da etwas übersehen?

Bitte um Hilfe.

Ciao
Norman-Timo

Hallo norman_timo,

du sitzt einem Fehlschluss auf. Die Klasse ist nicht statisch. Es gibt lediglich einen statischen Konstruktor. Weiterhin gibt es implizit einen nicht statischen Konstruktor, der benutzt wird, wenn du mit new Objekte erzeugst.

Eingentlich sieht deine Klasse also so aus (den impliziten Konstuktor explizit gemacht):

public class Teststatic
{
    static Teststatic()
    {
    }
    public Teststatic()
    {
    }
}

Und da der statische Konstuktor nichts tut, kann man ihn auch ohne Semantikänderung weglassen. Letztendlich hast du also folgende Klasse.

public class Teststatic
{
    public Teststatic()
    {
    }
}

Und die lässt keine Rückschlüsse auf die von dir beabsichtigte Aussage zu.

In meinem vorigen Beitrag stehen schon alle relevaten Aussagen dazu drin. Vielleicht werden sie durch das Beispiel aus diesem Beitrag jetzt deutlicher.

herbivore

Hallo Herbivore!

Na siehste, jetzt hab sogar ich das geschnackelt 🙂

Jetzt weiß ich warum da mein Vergleich fehlschlägt. Dann ist zumindest bei mir alles klar.

Danke Dir.

Ciao
Norman-Timo

Hm, ich hab das immer so aufgefaßt, das der statische Konstruktor einer Klasse dann aufgerufen wird, wenn der erste Zugriff auf die Klasse erfolgt...

Hallo sheitman!

Genau das ist ja nicht der Fall, da der statische Konstruktor nur einmal aufgerufen wird, sobald die Applikation sich startet. Das ist der Sinn von statisch. Es wird einmal bei Beginn instanziiert, und ist dann die gesamte Laufzeit über erreichbar.

So geschieht das auch mit den Attributen und Methoden.

Mein Problem hier war nur, dass ich gedacht habe, dass sich statische Konstruktoren nochmals aufrufen lassen, aber da wird der Standard-Konstruktor aufgerufen, der immer vorhanden ist, wenn kein anderer (nicht-statischer) da ist.

Ciao
Norman-Timo

Der SDK sagt:

Der statische Konstruktor für eine Klasse wird in einer bestimmten Anwendungsdomäne höchstens einmal ausgeführt. Die Ausführung eines statischen Konstruktors wird durch das erste der folgenden Ereignisse ausgelöst, die in einer Anwendungsdomäne auftreten:

Eine Instanz der Klasse wird erstellt.
Es wird auf beliebige statische Member der Klasse verwiesen.

@norman_timo
hm... aber quallos quelle (sdk) bestätigt da eher mich... bzw. so hab ich das gemeint...

dann müßte das bei einer klasse mit statischem konstruktor ja folgender maßen ablaufen wenn ich ein objekt erzeuge

erster aufruf
-> statischer konstruktor
-> konstruktor zum erzeugen des objektes

zweiter und folgende aufrufe
-> konstruktor zum erzeugen des objektes

statische konstuktoren gab es ja auch schon mit .net 1.1
ist also nichts neues...

Hallo!

Boah, da hab ich jetzt echt keine Ahnung, wie das genau im Hintergrund abläuft.

Also wenn die SDK sagt, dass erst dann eine Instanz eines statischen Objekts erzeugt wird, wenn erstmalig eine Instanz erstellt wird, oder erstmalig eine statische Methode/Attribut aufgerufen wird, dann wird das wohl stimmen.

Für mich persönlich ist das aber das Gleiche, einfach nur weil, sobald ich Zugriff auf die statischen Eigenschaften brauche, ich ihn habe, auch ohne Instanz. Wann genau jetzt das "statische Objekt" erzeugt wird, ist da nur interessant, wenn man überhaupt keine statischen Eigenschaften dieser Klasse benutzt. (Dann würde es also kein Speicher von vornherein belegen, was nicht schlecht zu wissen ist 😉

Dann ist es so wie Du sagst, sobald ich ein Objekt der Klasse erzeuge, wird gleichzeitig ein "statisches Objekt" mit erzeugt, also quasi 2 Objekte. (Bäh, ich hasse das in Worten zu fassen was ich meine 🙂

Ciao
Norman-Timo

Hallo norman_timo,

da geht aber noch einiges durcheinander.

Der statische Konstruktor erzeugt kein statisches Objekt. Es gibt gar keine statischen Objekte. Folgerichtig gibt es auch keine Variablen, in dem man eine "statisches Objekt" speichern könnte. Mindestens ist aber der Begriff irreführend. Was du mit dem statischen Objekt meinst, ist einfach die Klasse selbst.

Auch reserviert weder ein Instanz-Konstruktor noch ein Klassen-Konstruktor Speicher, sondern initialisiert ihn nur. Ein Konstuktor sollte also eigentlich bessser Initialisier heißen. Wenn der statische Konstruktor also erst spät aufgerufen wird, heißt das also keineswegs, dass der Speicher erst zu diesem Zeitpunkt reserviert wird.

Auch ist es ein Unterschied, ob man Zugriff auf statische Member hat, oder ob man tatsählich zugreift. Den Zugriff hat man von Beginn an, zugreiffen tut man aber vielleicht erst nach einiger Zeit.

herbivore

Original von herbivore
Auch reserviert weder ein Instanz-Konstruktor noch ein Klassen-Konstruktor Speicher, sondern initialisiert ihn nur. Ein Konstuktor sollte also eigentlich bessser Initialisier heißen. Wenn der statische Konstruktor also erst spät aufgerufen wird, heißt das also keineswegs, dass der Speicher erst zu diesem Zeitpunkt reserviert wird.

Das gilt doch aber nur für WerteTypen, die in einer Klasse sind, nicht für ReferenzTypen.

Wenn ich zum Beispiel eine statische Instanz vom Typ XMLSerializer in meiner Klasse habe, die im statischen Konstruktor erschaffen wird, wird der Speicherplatz den die Instanz braucht erst belegt, wenn ich sie erschaffe. Vorher habe ich nur den Speicherplatz belegt, den die Referenz auf die Instanz benötigt.
Bei int oder DateTime natürlich was anderes.

Grüße Christoph

Hallo Quallo,

ich rede über den Speicherplatz für die statischen Variablen. Wenn man im Konstruktor ein Objekt mit new erzeugt, wird ja Speicher für das neue Objekt reserviert.

herbivore

Hallo Herbivore!

Ja, danke, ich habe Schwierigkeiten das richtig formal korrekt auszudrücken.

Aber dank Dir gewöhne ich mich langsam an formal korrekte Ausdrucksweisen 🙂

Sorry, wenn das bei mir so verwirrend klingt.

Ciao
Norman-Timo