Patterns im Einsatz

Hallo zusammen

ich habe mich in letzter Zeit unteranderem mit Code-Design-Patterns(MVC, Observer...) beschäftigt.
Allerdings sind für mich die Beispiele, die z.B.: in den Webcasts auftraten, zu abstrakt um sie in meine Anwendungen zu implementieren.
Da ich als reiner Hobbyprogrammierer (auch beruflich hab ich nichts mit Programmierung zu tun) wahrscheinlich niemals die Effizienz eines Profi bzw. Berufsprogrammierer erreiche, habe ich mich entschlossen euch zu fragen wie ich am besten meine Anwendung aufbaue.

Ich habe für diesen Zweck ein Projekt genommen an dem ich gerade arbeite.
Es handelt sich bei dem Programm um eine Art Xml-Adressbuch-Programm.
Ich möchte allerdings jetzt nicht das ganze Programm hier mit euch besprechen, es geht lediglich um ein UserControl das das Adressbuchverzeichniss darstellt.

Dieses UserControl macht folgendes:

• Es öffnet ein XML Adressbuchverzeichniss
• Es zeigt alle im Adressbuchverzeichniss enthaltenden Adressbücher in einer Listview mit Namen des Adressbuches und die Anzahl der Einträge an
• man kann die Adressbücher einzeln anklicken und löschen
• die Namen der Adressbücher einzeln anklicken und ändern
• neue Adressbücher hinzufügen

alle Controls die dafür nötig sind, sind im UserControl integriert.
Die einzige Schnittstelle die nach draußen führt ist ein Click(ein öffentliches Event) auf den Adressbucheintrag der in einem anderen UserControll dann die Auflistung der einzelnen Adressen vornimmt.
Aber in meinem Beispiel geht es nur um das oben beschriebene UserControl.
In meiner bisherigen Vorgehensweise habe ich zwei Klassen:

• Präsentationsklasse (UserControlForm die nur ein bisschen Logic für die Anzeige enthällt)
• XML Klasse (enthällt Methoden zum öffnen und ändern der Einträge in der Xml-Datei)

zum jetzigen Zeitpunkt reiche ich z.B: die ListView per Methoden Parameter an ein Objekt der Xml-Klasse weiter um dort Einträge hinzuzufügen oder zu löschen. Das halte ich für unangebracht weiß aber nicht wie ich es anders machen soll.

Was hättet ihr für Vorschläge wie ich am besten Struktur hineinbekomme um so nahe wie möglich an die OOP zu kommen.

Gruß

x-sharp

Hallo x-sharp,

das grundlegende Konzept klingt sehr gut. Nur die Stelle, an der du dich störtst, solltest du tatsächlich ändern. Die Xml-Klasse sollte als Modell- oder gar Datenklasse in der Tat nichts von ListView wissen und schon gar nicht darauf zugreifen. Täte sie es, könnte man diese Klasse nur für Windows-Forms-Anwendungen nehmen und auch nur dann, wenn die Anzeige in einem ListView erfolgt. Soll das ListView später z.B. durch ein DataGrid ersetzt werden, steht man schon auf dem Schlauch. Aber das ist ja auch vermutlich der Grund, warum du es anderes machen willst. Dafür sehe ich folgende Möglichkeiten:

1. Der Xml-Klasse wird eine ArrayList/List<T> mitgegeben, die sie mit den anzuzeigenden Daten füllt. Das UserControl füllt diese Daten selbst in die ListBox.

2. wie 1) nur dass die ArrayList/List<T> per Rückgabewert an das UserControl gegeben wird.

Ich würde wohl Möglichkeit 2 wählen. Natürlich gibt es noch weitere Möglichkeiten zur Entkoppelung von View und Modell. Insbesondere wenn das Lesen der Xml-Datei lange dauert/dauern kann, kann man mit Events arbeiten.

3. Das UserControl stößt per Methode in der Xml-Klasse das Laden der Daten an, registriert vorher einen EventHandler für den Geladen-Event der Xml-Klasse, die Xml-Klasse feuert den Event, wenn die Daten geladen sind, übergibt in den EventArgs die ArrayList/List<T> und der EventHandler des UserControls füllt die Daten in das ListView.

herbivore

Hallo x-sharp,

eigentlich ist es recht einfach. Wenn man sich an das Grundprinzip von Objekt-Analyse hält, und anständig ein Design sich überlegt. 'Profi-Programmierer' machen das mit UML, da man hier sich schon einen klitzekleinen Teil Codierungsmöglichkeit mit einbauen kann, aber ich halte dieses Werkzeug für überschätzt.

Das Design kann man problemlos mit einem Zettel und einem Stift erledigen, indem man zunächst sich überlegt, was für Bestandteile (Objekte) gibt es denn überhaupt. Wenn man zunächst die Benutzeroberfläche weglässt, dann sind das meist erschreckend wenig Dinge, erleichtert aber enorm einen gewissen Abstraktionslevel zu erreichen.

Bei Dir wäre das z.B.:

• Das Xml-File
• Ein Objekt (noch ohne Namen), das Daten aus diesem File holt, und auch schreibt.
• Ein Objekt, das genau eine Adresse beschreibt

Dann für die Benutzerschnittstelle (UI):

• Viele Objekte, die nur für die reine Darstellung sorgen (z.B. ListView, oder Textbox etc...)

Jetzt komt die Analyse, was brauchen die Objekte, damit sie miteinander arbeiten können.

z.B. (auszugsweise):
Das Adresse-Objekt muss einmal die Daten irgendwie bekommen, dafür brauch es Kenntnisse über das Objekt, das direkt mit dem File kommuniziert. Das realisiert man z.B. so, dass dieses Objekt innerhalb dieser Adresse gehalten wird, und auch dort verwendet wird.
Genauso muss das Adr.Obj. auch die Daten für die UI vorbereiten, dafür sollten Eigenschaften geschaffen werden, die von den UI Controls als Databinding benutzt werden können.

....

Ich glaube dass der Weg klar geworden ist. Objektorientiertheit heißt nicht, dass man etwas perfekt programmiert, sondern die Möglichkeiten des OOP nutzt. Ob man das jetzt performant programmiert, oder ob der Code für andere Dinge wiederverwertbar ist. Oder ob man ihn einfach erweitern kann, das hat primär nichts mit OOP zu tun.

Das macht auch einen heiden Unterschied zw. Hobbyprogrammieren und berufliches Programmieren. Bei einem Hobby hat man Zeit, und geniesst es, dass es Spaß macht. Beruflich sollte es auch Spaß machen, aber die Zeit bedeutet hier Kosten, und man muss sich eine andere Herangehensweise überlegen, damit man effizient programmiert.

Schwierigkeiten treten meist bei der Umsetzung auf. So wie Du jetzt festgestellt hast, dass eine ListView nicht geeignet für den Datentransport zw. UI und Deinem Adress-Objekt ist.

Wie gesagt, schaue mal nach dem Stichwort DataBinding, mit dem .NET 2.0 ist das nochmal richtig komfortabel geworden, aber auch schon in 1.1 durchaus lohnenswert anzuschauen.

Gruß,
Norman-Timo

hi 😉

ich hab mir jetzt nich alles direkt durchgelesen. aber wenn du etwas zu patterns suchst habe ich hier ienen guten link:

http://www.dofactory.com/Patterns/Patterns.aspx

ansonsten zu observer pattern: google mal nach weatherstation das ist ein bekanntes beispiel zu observerpattern. ich finde daran ist es gut erklärt wie man solch ein pattern am besten aufbauen sollte 🙂

Hallo ihr beiden,

danke das ihr euch mit meinem Thema beschäftigt habt.
Ich habe jetzt mal eine Skizze angefertigt und wie norman_timo schon richtig vermutet hat kenn ich mich mit UML herzlich wenig aus.
Deswegen habt Erbarmen mit meinen ersten Schritten in diese Richtung.
Die Skizze befindet sich im Dateianhang.

Danke

x-sharp

edit: Ich habe soeben bemerkt das ich Adress falsch geschrieben habe 8o --> Address

Hallo x-sharp,

das ist doch schon mal nicht schlecht. Wenn Du jetzt noch zu Deinem Schaubild (das muss auch nicht zwingend UML sein 🙂 dazu schreibst, was die verschiedenen Klassen können, bzw. machen, dann ist es schon perfekt genug für einen Hobby-Programmierer.
Konkret meine ich die Methoden und Eigenschaften, die aber wie gesagt auch textuell beschrieben sein können.

Alles andere kommt sowieso mit der Zeit, je häufiger man sich mit so etwas beschäftigt, desto schneller kommt man zu mehr und mehr Professionalität.

Du bist mit Deinem Ansatz schon weiter als mancher 0-8-15-Hobby-Programmierer...

Weiter so,
Norman-Timo

Hallo norman_timo,

herzlichen Dank für Deine Hilfe und Motivation.
Ich würde mich freuen wenn Du und die anderen natürlich auch mein nächsten Schritte begleiten würdet.
Dann mach ich mich mal an die Arbeit (bis zum nächsten Ergebniss kann es noch was dauern) 😁

Nochmal Herzlichen Dank 👍

x-sharp