Bin gestern mit dem Blog-Artikel über Magic Values doch nicht mehr fertig geworden. Jetzt aber endlich:
http://www.christian-rehn.de/2010/12/31/magic-values/
Zitat:
Ich nehme ein Datenmodule, füge diesem 4 ComPort Komponenten zu, welche über den Dienst oder über die Anwendung
konfiguriert und genutzt werden können.
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?
Zitat:
Soll heißen, da jede Hardware andere
Einstellungen nutzt(Baudrate, Parität, Parser), verankere ich die Einstellungen doch am besten in der
entsprechenden Klasse.
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.
Zitat:
So habe ich doch den Vorteil, einen neue Hardware, eine neue Klasse.
Das hast du bei DependencyInjection genauso.
Zitat:
Desweiteren wird ja der Parser der entsprechenden Hardware in der Klasse implementiert. Somit habe ich alles
was zur Hardware MB100 gehört in der Klasse MB100, usw.
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.
Zitat:
Alles was zur Zentrale A gehört, befindet sich auch in dessen Klasse.
Eben das genau nicht. Das ist nicht objektorientiert. Nicht alles in eine Klasse. Sonst kriegst du Gottklassen, die letztendlich nur noch unübersichtlich sind. D.h. du solltest feiner Aufteilen. Es ist schon richtig, dass du das, was zusammengehört auch zusammen haben sollst, aber das muss nicht notwenidigerweise eine einzige Klasse sin. Das kann auch eine Gruppe von Klassen sein, sofern jede Klasse für sich genommen eine abgegrenzte Aufgabe hat und du dich nicht in Redundanzen verrennst. Lies mal
http://www.christian-rehn.de/2009/08...hinen-und-ood/ bzw.
http://www.objectmentor.com/resource...offeeMaker.pdf
mfg
Christian