C# - Programmstruktur

[Edgar C. (ec-develo)]

Hallo zusammen,

kurzer Hintergrund: bin langjähriger C-Programmierer und beschäftige 
mich derzeit mit C# (und Java).

Erstellt man mit dem Visual Studio Express eine Windows-Forms-Anwendung, 
dann werden defaultmäßig die Klassen "Program" (in Program.cs) und die 
Klasse "Form1" (verteilt auf die Dateien Form1.cs und Form1.Designer.cs) 
erstellt.

Die statische Klasse "Program" enthält dann nur die Methode static void 
Main(), die eine Instanz der Klasse "Form1" erzeugt.

Bisher habe ich alle weiteren Methoden meiner recht kleinen Programme in 
die Klasse "Form1" gepackt. Das kann aber nicht der Sinn der Sache sein, 
besonders wenn die Programme größer werden.

Außerdem widerstrebt mir die Idee, eine von "Form" abgeleitete Klasse 
mit allen möglichen anderen artfremden Funktionalitäten vollzupacken 
(Datei-I/O, mathematische Berechnungen etc.)

Daher möchte ich den Code in mehrere Klassen zerlegen.

Eigentlich kein Problem, da es programmtechnisch tausendundeine Lösung 
dafür gibt.

Aber was sind bewährte und sinnvolle Aufteilungen? Sollte man z.B. die 
Klasse "Program" erweitern, die dann Objekte der andere Klassen 
instanziiert?

Wie lässt man die einzelnen Objekte dann am geschicktesten miteinander 
kommunizieren? Beispiel: Buttonklick in "Fensterobjekt" soll Berechnung 
in "Matheobjekt" auslösen und das Ergebnis soll zurück in das Fenster 
übergeben und dort dargestellt werden.

Wie gesagt, realisierbar ist Vieles. Aber gibt es dafür best practices?

Google hat mit bisher nicht weitergeholfen.

Danke schön.

[Test (Gast)]

Ein Eventbus ist eine elegante Lösung in Kombination mit dependency 
injection

[Marcus W. (Gast)]

Ich handhabe es immer so, dass ich einen Ordner "Klassen" oder "Classes" 
erstelle und dann die jeweiligen Klassen mit "class.xyz.cs" reinpack. 
dann kann man recht elegant über die Verzeichnisstruktur darauf 
zugreifen oder sie per using-direktive einbinden.

In den jeweiligen forms hab ich dann nur noch die eventhandler und 
eventuell ein paar komfortfunktionen, die nur dieses eine form benötigt.

[nicht"Gast" (Gast)]

Edgar C. schrieb:
> Wie lässt man die einzelnen Objekte dann am geschicktesten miteinander
> kommunizieren? Beispiel: Buttonklick in "Fensterobjekt" soll Berechnung
> in "Matheobjekt" auslösen und das Ergebnis soll zurück in das Fenster
> übergeben und dort dargestellt werden.

Hallo,

dazu erzeugst du am Besten eine Zwischenklasse, welche die Verwaltung 
der Daten übernimmt.

Also das Abholen der Daten von der Oberfläche/Datei/Netzwerk, dann die 
Übergabe an deine Berechnungsklasse und dann das senden der Daten an die 
Oberfläche zurück.

hier noch ein kleiner Link:
http://de.wikipedia.org/wiki/Model_View_Controller

[Edgar C. (ec-develo)]

Hallo zusammen,

danke für eure Antworten, die Links und die Anregungen.

Ich glaube, ich bin einfach noch ein bisschen übervorsichtig, was das 
tatsächliche Codieren in C# angeht. Die abstrakteren Ebenen der 
Programmierung sind mir ja geläufig und ich glaube, mittlerweile auch 
ein gutes Verständnis der Mechanismen der OOP zu haben.

Aber wenn es dann tatsächlich losgeht, stehe ich öfter wie Ochs vorm 
Berg und befürchte Seiteneffekte innerhalb meines Codes, die ich nicht 
überblicken kann. Besonders im Zusammenspiel mit dem vom Visual Studio 
generierten Code.

Ist aber wohl nur eine Übungssache ;-)

Danke nochmal!

[T_K (Gast)]

Google: "MVC C#"
und: vergess für den Anfang das mit dem Eventbus und Dependency 
injection
grüße,
tk

[Marc O. (o_patrick)]

Also ich benutze für die Kommunikation zwischen solchen Ebenen bzw. den 
Ebenen bei MVC auch immer Events. Diese sind nicht schwer zu schreiben 
(auch am Anfang) und ich finde es persönlich sehr elegant.
Und wenn du einen Button anklickst wird ja sowieso schon ein Event 
ausgelöst und du musst halt dann richtig darauf reagieren.

Zur Ordnerstruktur: Ich erstelle mir für jede Klasse, die ich habe 
normalerweise eine eigene Datei. Habe ich von Java damals übernommen und 
finde es bis heute sehr sinnvoll.

[T_K (Gast)]

ack. beim begriff bus in kombination mit events und dep. inj. muss ich 
allerdings an sowas wie eclipse rcp denken, das brauchts imho fuer eine 
saubere architektur erstmal nicht. will man mit plugins oder bundles 
arbeiten, siehts natuerlich anders aus.
ggüber java finde ich die nutzung von delegates für die saubere trennung 
von gui und logik bei c# sehr angenehm...