Code-Unabhängigkeit

Hallo!

Es ist lange her, aber ich habe ja gesagt das ich euch die Merkliste schreiben werde was bei der Programmierung mit Forms und Code-Unabhängigkeit zu beachten ist, dabei gehe ich nicht auf Namespaces oder Klassen ein, sondern nur was man wenigstens beachten sollte um möglichst Codeunabhängig zu bleiben. Diese Merkliste ist nicht auf C# spezialisiert, sondern kann für alle möglichen Sprachen angewendet werden.

Merkliste:

1. Eine Form greift nur auf die Inhalte seiner eigenen Komponenten zu. Damit ist das lesen und schreiben von Daten gemeint.
2. Wird mehr als eine Form verwendet so gilt für jede weitere Form Punkt 1! Es greift also keine Form auf Komponenten einer anderen Form zu!
3. Jegliche Bearbeitung von Daten findet nicht in der Form-Datei statt, sondern in einer gesonderten Datei. Damit ist es gleichzeitig möglich für andere Forms auf die Daten zuzugreifen, die von einer anderen Form zur Verfügung gestellt, und zu bearbeiten.
4. Benutzt eine Schnittstelle für eure Daten über die sich die Dateien (sowohl formlos als auch formbehaftet) einander zugriff verschaffen können und dabei nicht von der Implementation der jeweils anderen Datei abhängig sind (Beispiel: Speichern von Daten die von einer anderen Datei verwaltet werden).

Ich denke das sollte es vorerst gewesen sein, wenn mir noch etwas einfällt und ich etwas mehr Zeit habe ziehe ich nochmal meine Unterlagen aus den Vorlesungen zu rate und seh mal ob und was ich vergessen habe.

Code-Hacker

jo
am besten machen wir eine globale statische Klasse 😉

warum sollen eigentlich Forms nicht auf Members von anderen Klassen zugreifen?
Auserdem ist das relativ unproduktiv.
Warum soll ich für vielleicht ein einfach MessageBox Result über eine andere Klasse gehen?

Einfach ein public Propety und die sache hat sich

Original von Hauptmann
jo
am besten machen wir eine globale statische Klasse 😉

warum sollen eigentlich Forms nicht auf Members von anderen Klassen zugreifen?
Auserdem ist das relativ unproduktiv.
Warum soll ich für vielleicht ein einfach MessageBox Result über eine andere Klasse gehen?

Einfach ein public Propety und die sache hat sich

1. Ich habe das mal aus dem gelernten von Delphi übernommen. Da kannst du globale allerdings nur für die Datei geltende Variablen benutzen, also nicht von außen nutzbar. Funktioniert wie in einer Klasse ist aber keine sondern eine Datei für z.B. die Listenverarbeitung eines Programms.
2. Wenn du immer auf deine 1. Form zugreifen musst und alles in Ereignis-Methoden machst wird dein Projekt extrem abhängig sein von dieser Form.
3. Wer redet von einer anderen Klasse? Das sagt ja keiner! Wie du es löst ist ja deine Sache. Und ich weiß ja nicht wie du es machst, aber ich habe mir dafür eine Klasse geschrieben über die ich meine Nachrichten aufrufe und meinen bedürfnissen anpassen kann, ist allerdings noch nicht ganz das was ich mir vorstelle.
4. Was ist daran unproduktiv? Wenn du nicht auslagern kannst und meinst du lässt Form2 auf die TextBox von Form1 zugreifen dann tue dies. Ich denke eher das das unproduktiv und unflexibel ist. statisch muss es ja nicht sein, nur wenn du was speichern musst was woanders verfügbar sein soll, gehe ich lieber den Weg der statischen Variablen, als das ich meine 2. Form von meiner 1. Form abhängig mache.
5. Also auf Membervariablen greifst du schon mal gar nicht zu, das solltest du aber wissen, ansonsten kannste gleich ne öffentliche Struktur benutzen. Du greifst natürlich nur auf Methoden zur Verwaltung bzw. Bearbeitung deiner Daten zu und dabei auch nur auf die auf die du zugreifen sollst. Statisch? Wozu? Das war ein Beispiel (wenn auch kein besonders gutes). Du kannst ja auch nen Copy-Konstruktor nehmen und damit die Instanz mit den Daten an deine 2. Form übergeben. Wie du das löst bleibt dir überlassen.

Vielleicht solltest du dir mal die Übungsaufgaben von mir ansehen, wie etwas ausgelagert wurde bzw. werden soll und lernst es dann zu verstehen.
Ein schönes Beispiel mit einer 2. Form ist folgendes Programm:
http://www.fh-wedel.de/~ps2/uebungen/ueb01/ueb01.pdf
Ansonsten kannst dir auch die anderen Übungen ansehen um mal zu sehen was wie ausgelagert werden sollte:
http://www.fh-wedel.de/~ps2/menu_1/4_welche_uebung_wann.html
Achte bei den Programmen nicht auf die Aufgabenstellung sondern seh dir die Unitaufteilung an. Dort siehst du auch das Typen gesondert definiert werden und in die anderen Units diese Datei mit den Typen eingebunden wird und dann Variablen von diesen Typen deklariert werden. Vielleicht sollte ich das auch noch als Punkt mit aufnehmen.

Ich glaube das ich mit den geforderten Auslagerungen letztenendes ein sehr flexibles Programm habe. Sämtliche geschriebene Dateien zur Listenverarbeitung, Dateiverarbeitung usw. benutze ich auch in anderen (eigenen) Projekten. Vorteil ist ganz klar der das ich niemals von der einen auf die andere Form zugreife und von nichts abhängig bin außer von der Datei und die kann man einfach einbinden und benutzen.

Wie gesagt, schmeiß Forms in die Ecke und lebe mit der Konsole. Da haste deinen Mainteil und kannst net allzuviel verkehrt machen da du dort idR sämtliche Deklarationen und Definitionen machst und auch Daten austauschst der verschiedenen Variablen.

Code-Hacker

also

Ich denke eher das das unproduktiv und unflexibel ist

es gibt Fälle, in denen man keine flexibilität benötigt. Und bei den Forms, bei denen ich das bisher so gemacht habe, benötigt die eine Form die andere. Da treten beide zusammen auf.

Wie gesagt, schmeiß Forms in die Ecke und lebe mit der Konsole. Da haste deinen Mainteil und kannst net allzuviel verkehrt machen da du dort idR sämtliche Deklarationen und Definitionen machst und auch Daten austauschst der verschiedenen Variablen

warum sollte ich das machen? Nur weil ich nicht so programmiere wie du willst?

aber sobald man flexibilität braucht, sollte man jede Klasse so implementieren, das sie unabhängig voneinander sind. Ohne zusätzliche Klassen

Ich hab mal ne Frage dazu: Nehmen wir mal an, ich hätte ein Dataset oder eine Hashtable. Wie könnte ich die zwischen den Forms austauschen?

Hi!

@Hauptmann:

1. Ob man das braucht oder nicht ist eigentlich egal. Ich hatte noch nie eine Aufgabe (nicht schulicher Art) bei der ich eine Form auf die andere hätte zugreifen lassen, da ich mir damit nur selbst Steine vor die Füsse geworfen hätte und gegen OOP verstoßen hätte.
2. Ich sage nicht das du es tun sollst. Wer nicht mit Forms umgehen kann soll es lassen. Jeder vernünftige und an die OOP orientierte Programmierer lagert erstmal grundsätzlich aus, alles was er kann. Dazu kommt nämlich Übersichtlichkeit.
   Es ist so das wenn mir jemand Code vorlegt ich am liebsten die Zettel nehmen würde um sie zu zerreißen. In diesen Programmen wurde so programmiert das sich alle Forms gegenseitig austauschen. Wenn man mir dann sagt ich soll das Programm erweitern, dann bleibt mir nur noch eines zu sagen: "Ich schreibe es neu!". Auf die Frage "Warum?" antworte ich nur noch das der Programmierer alles falsch gemacht hat was er nur hätte falsch machen können. Solche Programme kann man Grundsätzlich nicht erweitern, da sie unflexibel, unübersichtlich und somit unproduktiv sind. Fehleranalyse bei diesen Programmen ist unmöglich da ich keine Übersicht habe.
   Hingegen bekomme ich ein Programme welches für die Konsole gemacht wurde. Dort erlebe ich wesentlich öfter das sich der Programmierer weitestgehend an das OOP-Konzept gehalten hat und ich es problemlos erweitern kann. Woran das lag? Er hatte seinen Mainteil und hat dort den Datenaustausch vorgenommen. In einer Win-App konnte er sich komischerweise nicht mehr daran halten.

Aber wer meint Forms programmieren zu müssen ohne jeglicher Professionalität und meint das es doch ganz legal ist das die Forms ihre Daten gegenseitig austauschen dann werde ich dieses Programm bestimmt nicht nutzen, sondern neue Programmieren.

Zu deiner Aussage das ich wolle das so programmiert wird, so hast du es scheinbar nicht verstanden was ich meine. Es geht dabei nicht nur um übersichtlichkeit und flexibilität sondern darum das sowohl du selbst als auch andere noch in n Jahren deine Programme verändern und erweitern können.
Ich glaube um zu verstehen was ich meine Hauptmann solltest du mal in eine Firma gehen und sowas machen, dann wird dein Chef nicht lange zögern und dir sagen du kannst von vorne beginnen, wenn du mir das nicht glaubst, dann kannst du dich ja mal mit einem Berufsprogrammierer unterhalten. Also bevor du weiter meckerst mache eine Ausbildung und lerne zu verstehen was es bedeutet Forms nicht aufeinander zugreifen zu lassen. Diese Programme sind schlecht erweiterbar und die Wahrscheinlichkeit das dort Code drin ist den man duch auslagerung um ka wieviel Zeilen hätte kürzen können ist nicht gering. Wenn du jetzt meinst das erweitern ja nicht nötig sei genau so wenig wie das man manchmal flexibilität nicht braucht, dann solltest du das programmieren sein lassen, weil du es dann einfach nicht verstanden hast was ich meine.

@Franknstein:
Dein Dataset existiert doch nur optisch weil du es dir anzeigen lässt. Erzeuge ein Dataset in einer Datei und mache dort deine Dataset-Operationen.

Ganz egal um welches Problem es sich handelt. Schlechter Code ist nicht wartbarer und nicht wiederverwendbarer Code.

Ich werde auch nur noch auf produktive Kommentare antworten. Jeder der Hauptmanns Meinung ist der soll weiterhin Formabhängig programmieren allerdings anderen Programmierern, die sich an das OOP-Konstrukt halten, damit nicht zu konfrontieren.

Code-Hacker

btw: Die Interaktion verschiedener Forms (also Objekte) wiederspricht als solches nicht den OOP Konzepten - sofern man schön kapselt und die Daten-Besitzer Beziehungen sinvoll berücksichtigt ... viel mehr wiederspricht es den Multi-Tier Konzepten (verteilter (oder auch nicht verteilter)) Anwendungen, die strikt auf eine Trennung der verschiedenen Layer setzen (Presentation, Data, etc..) ...

Es widerspricht schon den Konzepten von OOP ... Kohäsion und Kopplung ...

ok, ich hatte zugegebenermassen die postings oben nur kurz überflogen und dachte somit an eine leicht andere Situation.

Trotzdem wiederspricht eine Interaktion zwischen Forms imho nicht grundsätzlich der Kopplung und Kohäsion. Gehören mehrere Controls in einem hohen Grade zusammen, kann man sie in manchen Fällen gut als einziges Modul mit einer folglich recht hohen Koheränz betrachten - ohne störende Kopplungseffekte. Das widerspricht aber auch nicht Code-Hackers Richtlinien, die ich natürlich unterstütze ...

Nun ja, es widerspricht der Kopplung insofern, als diese so gering wie nur irgends möglich sein sollte ... jedenfalls nach Rombach und Basili.

Zwei Forms gehören entweder so eng zusammen, dass es keine zwei Forms mehr sind, oder es sind eben zwei Forms, dann haben sie aber auch eine logische Trennung ... alles andere ist IMHO schlechtes Anwendungsdesign ...

Da sich dann nicht ausschließen lässt, dass die eine Form mal geändert / ergänzt / gelöscht / was auch immer wird, halte ich die Kopplung beider den OOP-Paradigmen abträglich.

Eine bessere Lösung wäre IMHO ein zentraler Form controller, der die Geschäftslogik enthält und die einzelnen Forms nacheinander aufruft und die zurückgegebenen Daten weiterreicht ... dann wird später nur hier eine Änderung fällig, nicht an den einzelnen Forms ... diese sind Präsentationslogik und sollten - wenn sie erst mal stehen - auch so bleiben ...

Hallo!

Das versprochene Tutorial findet ihr hier, mitsamt Code-Beispiel:
http://www.visual-cplusplus.net/forum/viewtopic.php?t=171

Code-Hacker

Hallo,

Ich muss hier Code-Hacker deutlich zustimmen.

Klar KANN man das anders machen. Da schöne ist ja, daß immer viele Wege ans Ziel führen.

Aber je strenger man GUI, Core und Data trennt, umso leichter gestaltet sich ein Umbau/Neukonstruktion/Erweiterung der Anwendung.
Je weniger Funktionalität in der Klasse der Form liegt, desto leichter ist es diese den Bedürnissen des Users nach umzugestalten.

Das hat auch nur bedingt was mit OOP zu tun, sondern kristallisiert sich immer mehr heraus, je länger man programmiert.

Der schöne Nebeneffekt ist der ziemlich strukturierte und ubersichtliche Code der in vielen Dateien verteilt in den Ordnern der Solution liegt. 🙂

Klar kann man niemanden Vorschriften machen wie er programmieren soll, aber ch denke das es mehr als ein Denkanstoss gedacht war.

Gruss,
Ftee

Sehr schön.
Durch dein Tutorial habe ich jetzt auch kapiert wozu Schnittstellen gut sind.
DANKE!

mfg.

moson

Kleine Ergänzung zu dem Thema...

Man kann imho eine ziemlich klare Grenze ziehen, bis wohin die Verzahnung zweier Forms noch legitim ist, und zwar genau bis dorthin, wo eine Form eine Unter-Form einer anderen Form darstellt, d.h. solange die Unter-Form "form-modal" zur anderen Form ist.

Beispiel: Ich habe ein Programm zur Verwaltung von Kontakten. Im Formular zur Anzeige eines Kontakts zeige ich Ort und Postleitzahl an. Diese beiden Informationen stehen in zwei TextBoxen. Ich kann also beides einfach per Eingabe ändern. Um den Komfort zu erhöhen, setze ich daneben einen Button mit einer Ellipse ("...") drauf. Wenn der Anwender darauf klickt, kriegt einer eine Unter-Form angezeigt, in der er nach Orten und Postleitzahlen suchen kann. Wenn er auf dieser Unter-Form nun auf "OK" klickt, werden die beiden Daten "Ortsname" und "PLZ" direkt in die Hauptform übernommen, als hätte ich sie dort mit der Hand eingetragen.

Das hat gleich mehrere Vorteile:

1. muss ich die Hauptform nicht über eine Änderung benachrichtigen.
2. muss ich keine Änderungen im Datenbestand rückgängig machen, wenn der Anwender sich entscheidet, den neuen Ort / die neue PLZ nicht zu übernehmen, den Dialog also mit "Abbrechen" verlässt.

Natürlich müssten hier in die Hauptform entsprechende Get/Set-Paare rein. Die Unter-Form darf nicht direkt auf die Steuerelemente zugreifen.

Ich finde diesen Thread sehr interessant, da ich seit einem Monat dabei bin mich in Windowsapplikationen mit .NET und C# einzuarbeiten. Da dies meine Diplomarbeit ist bin ich natürlich versucht, alles so sauber wie möglich zu programmieren.
Ich habe 2 Forms, jede hat ihre Klasse in getrennten Dateien. In der ersten Form existiert eine Eigenschaft über der es der 2. Form möglich ist den Text eines Labels in der 1. Form zu ändern.
Stellt dieses noch eine saubere Trennung der Forms dar? Oder handelt es sich hierbei schon um unsauberen Code?

Wie so oft wäre hier die Anwendung des MVC-Patterns empfehlenswert. Warum muss das Label in der anderen Form geändert werde? Doch sicher, weil sich der Status des Programms und/oder der Daten geändert hat. Warum also nicht ein Modell benutzen, dass den aktuellen Status enthält und bei dem man sich als Observer anmelden kann? Dann müssten die Forms nichts voneinander kennen.

MfG VizOne

Hallo dschmoegner,

grundsätzliche Zustimmung zu VizOne. Wenn man sich mal auf Observer eingeschossen hat, will man gar nicht mehr ohne.

Trotzdem als Ergänzung: Wenn ein Form der Klasse A ein Form der Klasse B erzeugt, ist ja A ein Benutzer von B und kann damit auch alle Methoden und Eigenschaften aus der Klasse B benutzen, ohne dass das zu bemängeln wäre. Wenn die Klasse A also über eine Eigenschaft aus der Klasse B eine Änderung des Zustands eines Objektes vom Typ B herbeiführt, ist das ok. Forms unterscheiden sich in dieser Hinsicht nicht von anderen Klassen.

herbivore

Also die zweite Form wird nicht direkt von der ersten Form erzeugt sondern per Show() aufgerufen. Es sei denn das meintest du mit "erzeugen".
Habe mal nach MVC gegoogelt und auch einige Modellbeschreibungen dazu gefunden. Ist hierbei der von euch erwähnte Observer dasselbe wie die Views in den Modellen?
Die Frage ist jetzt ob dieses Konzept nicht zu aufwendig für mein Projekt ist. Denn in den einzelnen Forms sollen jediglich Daten eingegeben werden die dann im eigentlichen View angezeigt werden sollen. Beispiel: Über 2. Form wird eine Adresse eingegeben und in der 1. Form, wie bei einem Briefkopf eingetragen. Ich werde wohl auch die Eingabeforms als modale Dialoge gestalten. Dann sollen diese Daten noch in einer Datei gespeichert werden. Dafür sollte doch eigentlich Schnittstellen und Serialisierung ausreichen oder?

Hallo dschmoegner,

Was das "Erzeugen" angeht: Die eigenliche Erzeugung spielt in der Tat nicht die Hauotrolle. Es geht darum, ob A B benutzt oder B A. Es solle immer nur eine der beiden Richtungen geben. Wenn A ein Show von B macht, dann benutzt A B und sollte B nicht auf A zugreifen.

Wenn es um die Rückgabe von Werten geht, solltest du dich so nah wie möglich an dem üblichen Mechanismus orientieren. Wenn du eine Methode aufrufst, bekommst du einen Rückgabewert geliefert. Die Methode selbst versucht nicht eine Variable in dem Code des Aufrufers ausfindig zu machen und zu setzen, um ihm das Ergebnis mitzuteilen. Im Gegenteil die aufgerufene Methode weiß nichts über den Aufrufer und soll nichts über ihn wissen.

Wenn die Verarbeitung in der Methode asynchron erfolgt, steht der Rückgabewert bei Rückkehr der anstoßenden Methode noch nicht zur Verfügung. Deshalb muss braucht man einen Mechanismus, um den Aufrufer zu benachrichtigen, wenn der Rückgabewert zur Verfügung steht. Der Aufgerufene soll dabei trotzdem nichts über den Aufrufer wissen. Dafür ist gibt es den Observer-Pattern. Der Aufrufer holt sich die Werte dann selbst ab, nachdem er die Benachrichtigung erhalten hat.

Observer ist ein Design-Pattern, der bei der Implementierung von MVC genutzt werden kann. Da MVC aber selbst ein Design-Pattern ist, kann man MVC ohne Rückgriff auf Observer implementieren. Allerdings habe ich noch nie MVC in der reinen Lehre benutzt, sondern immer View und Controler als eins behandelt. Und dann bleibt m.E. nicht mehr viel mehr übrig als der reine Observer.

Was den Aufwand betrifft: Observer sind schnell implemeniert. Es mag sein, dass der erste Observer im Leben etwas dauert, aber Observer braucht man ja immer wieder. 🙂

herbivore

bisher für die Antworten. Eine letzte Bitte hätte ich @herbivore.Gibt es irgendwo ein Tutorial was die programmierung von einem Observer behandelt oder hast du Codebeispiele? Nehme natürlich auch Tipps von anderen entgegen. 🙂

Hallo dschmoegner,

passende Tutorials kenne ich nicht.

Aber alle Ereignisse in .NET sind quasi Implementierungen des Observer-Pattern (bzw. einer speziellen Variante). Wenn du die Größe (Size) eines Forms änderst, wird das SizeChange-Ereignis (intern) durch die OnSizeChanced-Methode ausgelöst. Wer wissen will, ob sich die Größe geändert hat, registrert einen EventHandler (und wird damit zum Beobachter). Alle registrieren EventHandler werden aufgerufen, wenn das Ereignis eintritt - das ist quasi die Benachrichtigung der Beobachter.

Wenn man ein eigenes Ereignis definiert (darum geht es ja), dann kann man eigene Typen von EventHandlern definieren oder auf den Standard-EventHandler (nämlich 'EventHandler') zurückgreifen.

Wichtig ist noch, dass man View und Modell trennt. Also speichert man, was man in Form A anzeigen möchte, nicht direkt in der View-Klasse A, sondern in einer oder mehreren Modellklassen-Objekten (nehmen wir an, die Modellklasse heißt M). Das neue Ereignis z.b. YChanged wird in M definiert und OnYChanged implementiert. A erzeugt oder bekommt ein M-Objekt. A registiert seinen EventHandler für das Ereignis YChanged. Das M-Objekt wird an B übergeben. B ändert den Zustand von M. Dadurch wird das Ereignis ausgelöst (M muss so programmiert sein, dass es das mit Hilfe von OnYChanged auch tut). Der EventHandler von A wird aufgerufen und kann die Daten im Form A aktualisieren.

Führ dir das am besten in aller Ruhe zu Gemüte und schau dir auch die Beschreibung der Ereignisbehandlung in .NET an.

HTH

herbivore

Observer

Hi!

Ja, mich gibts noch g. Werde in naher Zukunft wieder mehr Zeit haben und dann wieder öfter herkommen (auch wenn ich kein C# programmiere). 🙂
Wo hier MVC erwähnt wurde, will ich mal ne Buchempfehlung zum Thema OOP abgeben: "Entwurfsmuster - Elemente wiederverwendbarer objektorientierter Software".
Jetzt wo ich dieses Semester noch OOP als Vorlesungsfach habe anhand von Java, muss ich sagen das es bei richtigem Design sehr komfortabel ist, wenn man Klassen wiederverwenden kann. Ich habe 2 Klassen gehabt, die ich über 3-4 Übungen hinweg bereits benutze. Ein paar Klassen die wir entwickelt haben, habe ich mir bereits für Projekte rausgesucht. Wir haben bisher keine GUI-Anwendungen erstellt, außer ein Applet und auch beim Applet kann man sehr schön erkennen wie leicht es doch sein kann die GUI von der eigentlichen Implementierung mit dem richtigen Design zu trennen. Ich könnte jederzeit unsere Umrechnungsklasse die vom Applet genutzt wird, durch eine andere ersetzen ohne auch nur einen Teil an der GUI ändern zu müssen. 🙂

Und wie schon jemand schrieb, dieses Tutorial sollte man nicht als Richtlinie, sondern als Gedankenanstoß sehen. Wenn ich mit meinen Prüfungen und meinen ganzen Seminararbeiten durch bin (im März etwa) kann ich das ganze ja nochmal überarbeiten, wenn da noch Interesse dran besteht und OOP mit einbauen (evtl. krieg ich es ja auch hin C# 1.1 Beispiele dazuzupacken, statt nur C++ und Java). alexander (oder wer auch immer C# jetzt leitet g) kann mich dann ja nochmal anschreiben deswegen. 🙂

Greetz, Vellas