Sauberer, schöner Programmierstil (OOP)
-
Hallo,
habe mal eine Frage bezüglich des Programmierstils.
Ich glaube mein Schwerpunkt liegt bei OOP Denkweise.
Ich habe jetzt ein Programm geschrieben das via serielle Schnittstelle Daten aus dem Gerät liest und auswertet. Das Programm ist noch nicht 100% fertig aber das meiste Funktioniert bis jetzt.
Naja nun zu meinem Problem, mein Programm wächst und wächst und wird immer unübersichtlicher. Da ich ein TreeView, DataGridView und die serielle Schnittstelle verwende, besitzen diese auch ihre events natürlich kommen noch benutzerdefinierte Funktionen hinzu und und und...
Als erstes hab ich meine Form mit dem Designer gebastelt nach und nach die events zusammengebastelt und dann noch die serielle Schnittstelle in die Form eingefügt. Natürlich wird ja alles in eine Klasse geschrieben (Formklasse). Jetzt ist mein Code schon sehr groß unübersichtlich und co.
Nach den Büchern die ich habe lernt man das richtige gestalten bzw. das richte Objekt orientierte Programmieren nicht richtig. Es wird jediglich mit Beispielen als gezeigt wie gewisse Sachen funktionieren.
Gibt es eine Möglichkeit sich eine saubere und schöne OOP Programmierweise aneignen zu können?
War mein Ansatz vielleicht doch nicht so verkehrt? Ich hab halt erstmal alles in eine Klasse runtergeschrieben das erstmal alles funktioniert. Und jetzt mach ich mir die Gedanken ob ich doch besser alles in verschiedene Klassen zu Packen.
Mein Hauptgedanke ist jetzt das ich das mit der seriellen Schnittstelle in einer eigenen Klasse umsetzen möchte. Denn diese läuft dann als Thread und liest unterschiedliche Daten in gewissen Abständen aus dem Gerät. D.h. dem Objekt gebe ich den passenden Modus welche Daten er holen soll. Die Daten kann ich ja dann in der Hauptklasse dann über eine Getterfunktion holen, wenn ich diese brauche.
Mein Ziel ist es ein Funktionierendes und übersichtliches Programm zu gestalten.
Was mit dem Einrücken und bennenen der Variablen angeht kein Thema das halte ich alles ein. Geht nur um das OOP.Vielleicht kann mir jemand ein Hinweis oder Tip geben und evtl. Ideen geben wie ich das mit der seriellen Schnittstelle realisieren könnte. Ich denke auf jedenfall in einer eigenen Klasse. Denn nur so könnte ich diese Daten evtl auch in anderen Fenstern verwenden.
Besten Dank schonmals.
-
Wie man richtig und ordentlich Projekte strukturiert lernt man mit der Zeit. Alles in einer Klasse runterzuschreiben, empfinde ich es jetzt nicht so gut.
Meine Erfahrung ist es das du ebend für verschiedene Aufgaben verschieden Klassen gestaltest, oder sogar noch abstrakter für verschiedene Aufgaben, verschiedene Projekte in deiner Solution anlegst.
Meinetewegen alles was mit der seriellen Schnittstelle zu tuen hat in das Projekt,
"Beispiel.Projekt.SerielInterface"
Ebend die Sachen wegdelegieren.
-
Vielen Dank für deinen Tip mit den verschiedenen Projekten. Werde mal versuchen damit zurecht zu kommen. Vielleicht wäre es auch nicht schlecht ein paar Projekte anzuschauen z.B. bei CodeProject.
Danke dir
-
Möglicher Weiße.
Du musst halt dran denken, die Projekte als Verweise in deinen anderen Projekten einzubinden wo du Zugriff auf das andere Projekt brauchst.Achja und als Klassenbibliothekt gestalte ich die dann immer.
-
Ich schau mal ob ich es so hinbekomme und damit klar komme.
Danke dir.
-
Ich halte es für fragwürdig schon bei kleinen Projekten diese gleich auf mehrere DLLs zu verteilen. Meherer Klassen, ok. Je nah Umfang die Klassen durch passende Namespaces aufgetrennt, auch ok. Aber gleich für jede kleine Klasse ne eigene DLL anlegen? Das geht imho zu weit.
Klassen sollten genau eine Thematik zusammenfassen (z.B. Serial-Klasse, Gui-Klasse, etc.)
Namespaces fassen wiederum Klassen zusammen die eine bestimmte Thematik haben, z.B. Windows.Form für alle Forms, Windows.Collections für alle Collections usw.
DLLs sind können einen oder mehrere Namespaces zusammenfassen, je nach Thematik oder Umfang.
Bei kleinen Anfängerprojekten würde ich hier erstmal bei den Namespaces aufhören.
Man darf auch nicht vergessen das DLLs hilfreiche Funktionen wie z.B. Refaktoring und ähnliches erschweren weil diese Funktionen nicht über DLL-Grenzen hinweg funktionieren.
-
@ loks: Recht haste. Da ich aber nicht wusste was für ein Umfang sein Projekt genau hat, hab ich einfach mal die Hardcorelösung vorgeschlagen die alles enthält.Ok das mit den Namespace hatte ich nicht erwähnt, danke für den Nachtrag.
-
loks schrieb:
Man darf auch nicht vergessen das DLLs hilfreiche Funktionen wie z.B. Refaktoring und ähnliches erschweren weil diese Funktionen nicht über DLL-Grenzen hinweg funktionieren.
Und ob das funktioniert. Ich habe hier eine Solution mit 14 Projekten die sauber Refactoring unterstützen wenn ein Bezeichner verändert wird. Aber es braucht etwas Zeit alles zu kompilieren und zu ersetzen.
Ein weiterer Einsatz -allgemein gesprochen- für das Auftrennen in mehrere Assemblies ist m.E. der Zugriffsschutz. Da das C++-Feature friend in den .Net-Sprachen nicht existiert ist das Ausweichen auf internal und Abbilden der Logik in einem anderen Assembly oft eine Alternative.
-
witte schrieb:
loks schrieb:
Man darf auch nicht vergessen das DLLs hilfreiche Funktionen wie z.B. Refaktoring und ähnliches erschweren weil diese Funktionen nicht über DLL-Grenzen hinweg funktionieren.
Und ob das funktioniert. Ich habe hier eine Solution mit 14 Projekten die sauber Refactoring unterstützen wenn ein Bezeichner verändert wird. Aber es braucht etwas Zeit alles zu kompilieren und zu ersetzen.
Ein weiterer Einsatz -allgemein gesprochen- für das Auftrennen in mehrere Assemblies ist m.E. der Zugriffsschutz. Da das C++-Feature friend in den .Net-Sprachen nicht existiert ist das Ausweichen auf internal und Abbilden der Logik in einem anderen Assembly oft eine Alternative.Ich wollte auch nicht grundsätzlich gegen die Auftrennung in mehrere Assemblies argumentieren sondern zu einer gewissen Vernunft raten. Grundsätzlich jede einzelne Klasse in eine separate Assembly kann in einem ziemlichen Chaos enden (mein aktuelles Projekt hätte dann mitllerweile ca 100 Assemblies)
Klassischer Anwendungsfall der Regel: So wenig wie möglich, soviel wie nötig.
-
Danke für eure Beiträge. Eure Beiträge haben natürlich etwas bei meiner Denkweise nun geholfen.
Ja mein Projekt ist jetzt noch nicht so riesig.
Die Sachen was jetzt der Designer in die Formklasse erstellt hat, wie events und co sind jetzt bei mir noch in der Klasse geblieben. Ich habe jetzt erstmal nur um eine Klasse mein Projekt erweitert was der seriellen Schnittstelle angeht, da dies ja mehr oder weniger unabhängig der Formelemente bzw. Form läuft. Also bis jetzt Thema Form blieb in Form und Thema serielle Schnittstelle ist nun in der Eigenen Klasse.Dennoch ist der Code ja noch recht groß, weil der Designer nun die Events in die Formklasse packt. Und ich noch Funktionen reingebastelt habe die die Formelemente füllen bzw. Initialisieren unter anderem bei Events werte berechnen. Ist es vernünftig Events von Formelemente auch in der Klasse zu lassen oder soll diese Sachen in eine seperate Datei wie z.B. formevents.cs also keine eigene Klasse nur eine Auftrennung oder ist dies garnicht möglich. Vielleicht sollte man ja auch nicht soviel trennen, wenn man am Schluss ja garnicht mehr weiß wo was zu finden ist. Dachte nur Thema zu Thema. Aber das ist ja ansichtssache. Events sind ein Teil der Formelemente, aber Events könnte man auch als eigenes Thema betrachten. Aber ich glaube dann müßte ich später bei verschiedenen Formen schauen wie ich das mit den Events dann machen wenn diese in einer seperaten Datei ist.
Nun habe ich noch ein anderes Problem bei einem CustomControl, aber dazu in einem anderen Forumsbeitrag.
Mein Projekt muß bald Fertig werden, daher die vielen Posts. Sorry!!!! Es nimmt aber Tag zu Tag Form an
Danke nochmals für eure Hilfe!