Zitat von
r2c2:
Danke für den Hinweis, werde ich mir aufjedenfall mal ansehen.
Zitat von
r2c2:
Wie viele Programme hast du jetzt? Ich dachte zwei: Einen Dienst und eine
GUI. Und die
GUI muss ja vom
Com-Zeug eigentlich nix wissen. Oder hab ich da was falsch verstanden?
Ja, ich habe vor zwei Programme zu schreiben. Allerdings sollen beide die selbe Aufgabe erfüllen. Soll heißen, startet man die Anwendung, hab ich eine Oberfläche auf der ich die Aktivitäten auf den
Com-Schnittstellen und den Datenverkehr der Datenbank beobachten kann. Siehe Screenshot 1.Desweiteren möchte ich einen Dienst, der die selbe Aufgabe erfüllt, allerdings die Funktion eines Dienstes hat. z.B. "Keine Windows Anmeldung erforderlich". Somit muss aber die
GUI auch einen Bezug zu den
COM-Ports haben. Zum Außerwerden der Datenbank, so vermute ich war dein Gedanke, gibt es eine weitere Anwendung die WEB-basierent läuft.
Zitat von
r2c2:
Nein, das sind Parameter, die man aus ner Konfigurationsdatei lesen sollte. "Put Abstractions in Code, details in metadata". Der Einfachheit halber kann man dieses Prinzip auch mal ignorieren (KISS). Das is mal wieder so ne Trade-off-Geschichte...
In diesem Fall würde ich aber auch die Factory nehmen. Egal ob jetzt von mir aus in der Factory hardgecoded oder aus ner Konfigurationsdatei gelesen. Aber deine Klasse muss von Baudrate & Co. eigentlich erstmal nix wissen. Das ist Sache von TComPort. ==> Separation of Concerns.
Hab ich verstanden, werde ich allerdings für mich als Zusammenhang in die
Unit der entsprechenden Hardware packen. Da denke ich so wie "Bummi".
Zitat von
Bummi:
Man kann und ich würde es in diesem Fall so tun, das ganze auch als hochspezialisierte/erweiterte Comportklassen sehen.
Zitat von
r2c2:
Das hört sich für mich an, als wären deine Klassen zu groß. Als täten sie zu viel. Eine Klasse sollte genau eine Aufgabe haben. Nicht mehr und nicht weniger. ==> Single Responsibility Princliple.
Ich weiß nicht, was deine Klasse alles tun soll, aber, wenn sie mehr tut als das Protokoll verarbeiten (also vermutlich das, was du Parsen nennst), dann solltest du das in mehrere Klassen aufteilen.
Von der Sache her ja, allerdings macht diese Klasse/das
Unit ja nur folgendes. Die Parameter bereitstellen welche notwendig sind um Daten anzufordern und zweitens diese Angeforderten Daten Parsen"Verarbeiten" bzw. in seine Einzelteile zerlegen und an das Datenmodul zurück zu geben. Die an das Datenmodul übergebenen Daten werden dann von dem Datenmodul in die Datenbank geschrieben. Somit wäre in der Klasse bzw.
Unit ein kleines Packet max. 4 Methoden die aber für eine Aufgabe zuständig sind. Alle diese Methoden werden benötigt um Daten von A - B zu bekommen. Und daher denke ich, das die Klasse nicht zu viele Aufgaben hat. Vieleicht sollte ich einfach sagen, das ich damit meinen Code mehr Strukturieren will. Hätte ich dies nicht vor, würde diese Aufgabe auch im Datenmodul Platz finden.
Vieleicht konnte ich meine Ziel jetzt noch etwas besser erläutern. Was mir wichtig ist, ist halt, das wenn schon eine externe
Unit, das diese auch sauber Programmiert ist. Ich fange gerade halt erst mit Klassen an und da will ich halt nicht direkt den größten Bock schießen.
Gruß Jens