Es sieht so aus, als würde innerhalb der Kommunikationsklasse ein Gerät letztendlich über Schnittstelle angesprochen und per Skippy-Kommandos gesteuert. Wofür ist die Geräteklasse überhaupt notwendig?
Nannen: Auf den ersten Blick stellt sich diese Frage tatsächlich. Die textbasierten Skippy-Kommandos wären zur direkten Verwendung geeignet. Allerdings fehlen bei dieser Anwendung wichtige Grundfunktionen, die jedes Mal neu implementiert werden müssten. Genau das gilt es zu verhindern.
Bei Abfrage des an einer Spannungsquelle eingestellten Spannungswertes, muss fast immer ein cast von der textuellen Antwort auf ein Zahlenformat erfolgen. Zusätzlich sind eventuell überflüssige Antwortteile vor der Umwandlung zu entfernen. Erst nach diesen Schritten, liegt die Antwort als Zahlenwert vor, der weiter ausgewertet wird oder in Anzeigeelemente einfließt. Dies alles ist bereits in der Funktion der Geräteklasse implementiert und der Anwender braucht sich um die Funktionalität der Auswertung der Textantwort und den cast nicht kümmern, sondern erhält unmittelbar den richtigen Wert.
Ein weiteres Problem bei der direkten Verwendung von Skippy-Kommandos ist, dass selbst bei Geräten gleicher Funktionalität, sich die spezifischen Skippy-Kommandos zwischen verschiedenen Herstellern schon unterscheiden. Man müsste also von allen Geräten die Kommandos kennen oder nachschlagen, was die Bedienung erschwert.
Eine weitere Möglichkeit, welche die Organisation in einer Geräteklasse bietet, ist das aktive Hinweisen auf falsche Bedienung. Wenn der Nutzer z.B. bei einem Signalgenerator einen Wert setzt, der jedoch bei der aktuellen Konfiguration gar nicht verwendet wird, kann durch eine Warnung darauf hingewiesen werden. Das spart Zeit und eine lästige Fehlersuche.
Alle diese Punkte machen eine Umsetzung der Skippy-Kommandos in einer Geräteklasse äußerst sinnvoll.
Wie messen Sie intuitive Funktionsnamen?
Nannen: Nun gut, die Bedeutung von "intuitiv" hängt letztendlich von der Nutzergruppe ab. Wir setzen beispielsweise auf CamelCase-Schreibweise und wohlbekannte Englische Methodenbezeichnungen, z.B. „get_U“ oder „get_I“ für die Abfrage von Spannungen und Strömen.
Schon alleine durch die Namen der Methoden in der abstrakten Klasse, ist der Spielraum für eigene Namenswahl jedoch recht gering. Die Namen von gerätespezifischen Funktionen werden vom Entwickler selbst festgelegt. Wir wollen eben kein 500-Seitenwerk verfassen, in dem alle Guidelines und Richtlinien hinterlegt sind, sondern es aus der Community der Nutzer und Entwickler heraus beleben.
Die Feedback-Schleife ist deshalb ein wichtiges Instrument. Mit der Verwendung einer Implementierung durch andere Kollegen wird diese auch automatisch validiert.