wieso static void Main(string[] args)

[^.^]

netrobot schrieb:

static ist fast wie global, man kann die Funktionen od. die Klassenvariblen überall aufrufen.

Dafür gibt es ja Zugriffsmodifier.

[Konrad Rudolph]

netrobot schrieb:

static void Main()

ist in eine Klasse definiert, um die aufzurufen muss das System eine Instanz zuerst erzeugen. Weil das System is nicht in der Lage so eine Instanz zu erzeugen, daher muss man die Funktion als static deklarieren.

Wieso sollte das System nicht in der Lage sein, eine Instanz einer Klasse zu erzeugen? Das ist doch Quatsch.

Dass die 'main'-Methode in C# und Java 'static' ist, ist reine Vereinbarungssache. Genausogut könnte sie nicht-statisch sein, oder statt der Methode könnte auch als Einsprungspunkt eine Klasse (bzw. deren Konstruktor) verwendet werden. Alles kein Problem.

[Talla]

Sehe ich nicht ganz so. Du kannst die Main Methode in eine beliebige Klasse setzen. Einfach den Konstruktor aufzurufen wäre unklug, wer weiß was der Konstruktor macht und was die Nebeneffekte sind. Da müsste man wieder vereinbaren dass nichts gemacht werden darf, nur damit schränkst du die Funktionalität der Klasse wiederum ein. Dann lieber gleich sagen dass die Methode statisch sein muss, man kann die Methode aufrufen und sich sicher sein dass es keine Nebeneffekte gibt und man ist glücklich

[Konrad Rudolph]

Talla schrieb:

Sehe ich nicht ganz so. Du kannst die Main Methode in eine beliebige Klasse setzen. Einfach den Konstruktor aufzurufen wäre unklug, wer weiß was der Konstruktor macht und was die Nebeneffekte sind. Da müsste man wieder vereinbaren dass nichts gemacht werden darf, nur damit schränkst du die Funktionalität der Klasse wiederum ein. Dann lieber gleich sagen dass die Methode statisch sein muss, man kann die Methode aufrufen und sich sicher sein dass es keine Nebeneffekte gibt und man ist glücklich

Kapiere ich nicht. Was für Nebeneffekte? Wieso darf es keine Nebeneffekte geben? welche Nebeneffekte kann denn ein Konstruktor haben, die die 'main'-Methode nicht haben kann?

/EDIT: Ich möchte nochmal deutlich machen, dass der Unterschied rein syntaktisch wäre. Semantisch wäre das ein und dasselbe, ob der Einsprungspunkt nun eine Methode oder eine Klasse ist.

Das geht sogar so weit, dass man den Einsprungspunkt in VB in einem Modul deklarieren kann, statt als statische Methode in einer Klasse. Es kommt trotzdem dasselbe heraus.

[Wiss0r]

Das ist halt einfach eine Notlösung, weil der statische Einstiegspunkt einfach mehr Sinn macht, aber man global statische Methoden ja für uncool hält und im Buzzword-Bingo damit Minuspunkte kassiert, deshalb hat man als Notlösung halt die statische Klassenmethode main.

Saubere wäre natürlich, wenn der Interpreter einfach ein Objekt einer Main-Klasse erzeugen würde und dann eine Methode auf diesem Objekt aufrufen würde.
Warum das nicht so gemacht wurde, ist mir bis heute ein Rätsel, vllt. weil es dann zu befremdlich für die C++ Leute wäre. Und der statische Main-Kompromiss ist halt auch Buzzword-Bingo kompatibel.
Und mehr zählt heutzutage in der IT-Welt eh nicht mehr.

[Talla]

Konrad Rudolph schrieb:

Kapiere ich nicht. Was für Nebeneffekte? Wieso darf es keine Nebeneffekte geben? welche Nebeneffekte kann denn ein Konstruktor haben, die die 'main'-Methode nicht haben kann?

Stell dir vor du hast eine Klasse die im Konstruktor irgendwie initialisiert werden muss, die benötigten Werte kommen von mir aus von irgendwelchen Usereingaben. In dieser Klasse implementiert man jetzt die Einstiegsfunktion als Instanzmethode. Um die Methode aufzurufen muss ein Objekt erstellt werden, der Konstruktor wird aufgerufen und wie soll er jetzt ordentlich die Klasse initialiseren wenn noch nicht mal die Einsprungsfunktion ereicht ist? Bzw. man könnte sowas sicherlich implementieren dass der Code im Konstruktor ganz normal ausgeführt wird, aber dann macht eine Einstiegsfunktion gar keinen Sinn mehr, da ja vorher schon beliebiger Code ausgeführt werden kann. Also könnte man das Prinzip einer Einstiegsfunktion als Instanzmethode nur mit leeren Konstruktoren durchführen und das führt die ganze Idee von Einstiegsfunktionen als Instanzmethoden ad absurdum da ich nur unnötig Code habe und ausführe den ich mit der Main Methode als statische Klassenmethode gar nicht bräuchte.
Man kommt in die Main Funktion und kann sich 100% sicher sein dass noch nichts passiert ist und das die erste Anweisung der Main Funktion auch als allererstes im Programm ausgeführt wird (aus Usersicht jedenfalls).
Das wäre bei Instanzmethode halt nicht der Fall und das kann fatal sein.

[bla bla bla]

dass der einstiegspunkt bei java eine statische methode ist, hatte schlicht praktische beweggründe. irgendwie muss halt definiert werden, wo der einstiegspunkt liegt. eine sauberere lösung wäre vielleicht gewesen, der vm irgendwie mitzuteilen, was alles getan werden muss, um ein programm zu starten. vielleicht eine art ini, die den bauplan für ein paar klassen o.ä. vorgibt. da das alles aber beliebig komplex werden kann, hat man sich halt auf eine statische methode geeinigt, der die startparameter als string array reingedrückt werden. war halt im bekannten c auch schon so. und c# hat den krempel dann einfach übernommen.

wenn man sich moderne frameworks anguckt, dann wird der einstiegspunkt in eine application mittlerweile ja tatsächlich über genau die beschriebenen "ini" dateien bestimmt. deployment plans für application server, boot strap XML für swt apps usw.

[Knuddlbaer]

Der Konstruktor einer Einstiegsklasse könnte auch eine vorgeschriebene Signatur alla xyz(string[] args) haben.

Beim Serialisieren von Klassen oder bei der Verwendung von Plugins hat man zumindest keine Probleme eine Klasse mit einem vorgeschriebenen Konstruktur zu initialisieren und dann eine vorgeschriebene Methode aufzurufen.

[Talla]

Beim Serialisieren geht es ja nur darum die Daten wiederherzustellen, deshalb der Konstruktor der die zu deserialisierenden Daten enthält und mit denen man im Konstruktor das Objekt wieder ordentlich initialisieren kann - vollkommen okay, das Programm läuft ja eh schon.

Einen Konstruktor als Einstiegsfunktion ist aber was völlig anderes. In einer Einstiegsfunktion befindet sich das Programm immerhin über die ganze Laufzeit. Wenn man dafür einen Konstruktor verwendet dann hat man für Ewigkeiten ein nichtinitialisiertes Objekt.

@bla bla bla
Diese Angabe von Einstiegspunkten ist aber noch ne Abstraktionsschicht höher. Die ändert nichts daran dass es wie gewohnt irgendwo ne Main Methode gibt in der geschaut wird, was jetzt getan werden muss um das Programm zu starten.

Ob jetzt statische Funktionen als Einstiegspunkte das Gelbe von Ei sind, weiß ich auch net. Aber für Sprachen die der OOP folgen, sind sie meiner Meinung nach das logischste um sprachlich klar und frei von irgendwelchen konventionellen Ausnahmen zu bleiben.

[Knuddlbaer]

StartObject obj = new StartObject();
obj.StartMethode(); // << Initialisiert

konventionellen Ausnahmen zu bleiben

Die Einstiegsmethode ist eine konventionelle Ausnahme ?!

[Konrad Rudolph]

Talla schrieb:

Konrad Rudolph schrieb:

Kapiere ich nicht. Was für Nebeneffekte? Wieso darf es keine Nebeneffekte geben? welche Nebeneffekte kann denn ein Konstruktor haben, die die 'main'-Methode nicht haben kann?

In dieser Klasse implementiert man jetzt die Einstiegsfunktion als Instanzmethode.

Stimmt, das mit der Instanzmethode als Einsprungspunkt war natürlich Blödsinn von mir. Ich hatte eigentlich schon an den Konstruktor als Einsprungspunkt gedacht, auch wenn ich etwas anderes geschrieben habe. Daher auch mein Unverständnis für Deinen Einwand.

Aber (nur um rechtzuhaben) ginge das natürlich auch. Man könnte z.B. einfach per Konvention festlegen, dass diese Startklasse keinen nicht-trivialen Konstruktor haben darf – oder noch einfacher: gar keinen (parameterlosen) Konstruktor. Genauso ist es schließlich auch für Structures geregelt.