[Java] API für ähnliche Brickelt-Typen vereinheitlichen

[teichsta]

Hallo,

 

gibt es möglicherweise Überlegungen, die API um ein paar sinnvolle Abstraktionen zu erweitern?

 

Aktuell setze ich bspw. ein BrickletIndustrialQuadRelay und ein BrickletDualRelay ein. Um einen "Kanal" des BIQR zu schalten rufe ich

 

relay.setValue(channelMask);

 

auf. Will ich das gleiche mit dem BDR machen heißt die Methode:

 

relay.setState(state.relay1, state.relay2);

 

Schöner wäre es aus meiner Sicht, wenn es vielleicht sowas wie eine Superklasse  "AbstractRelayBricklet" oder "AbstractSwitchableOutput" oder sowas gäbe, worüber man eben beide speziellen Bricklets gleich benutzen könnte. Immerhin will man ja auch das gleiche erreichen ;-).

 

Die Inputs habe ich mir noch wieder angeschaut, aber da könnte das möglicherweise auch sinnvoll sein?

 

Was meint Ihr?

 

Gruß,

 

Thomas E.-E.

[AuronX]

Gerade bei den Relays fällt das ganz schön auf

 

Ich würde behaupten die aktuelle Art wie die Bindings generiert werden lässt keine Verallgemeinerung auf eine gemeinsame Oberklasse zu.

Gegen eine einheitlich aussehende API spricht nichts außer backwards-compatibility. Aber die würde man auch durch doppelt angebotene Methoden herstellen können.

 

Ansonsten würde ich dir empfehlen solche Dinge durch eigene Wrapper zu abstrahieren, das habe ich bei einem meiner (derzeit schlafenden) Projekte auch schon für bestimmte Bricklets gemacht, z.B.:

abstraktes Interface

eine mögliche Implementierung

 

Der Vorteil dessen ist übrigens auch, dass wenn TF irgendwann mal das Protokoll 3.5 rausbringt (oder auf sonst merkwürdige Ideen kommt), dass du nur deine Wrapper aktualisieren musst, dein restlicher Code aber davon unberührt bleibt weil er den TF-Kram gar nicht kennt.

[teichsta]

danke für die schnelle Antwort!

 

Hmm ... wäre es denn aufgrund der Gleichförmigkeit der Methoden eventuell eine Lösung generischere Methoden in entsprechenden Superklassen anzubieten und dann nur noch die reine Übergabe der Funktionsidentifier in den speziellen Implementierungen zu haben anstatt immer alles in jeder Klasse implementiert zu haben?

 

Am Anfang ist das mit dem generieren zwar immer ganz nett, weil es eben noch viele Änderungen gibt, aber am Ende des Tages ist die Vielfalt der Bricklets ja auch beschränkt und ihr haut ja nicht jeden Tag ein Neues raus, oder?!

 

[cfranz]

Ich kann dem Kommentar von teichsta nur beipflichten - ich bin ja gerade dabei, ein abstraktes interface zu schreiben (einen objective-C layer für TF). Nicht nur die relais sind wenig einheitlich - alle Sensoren (so nenne ich die bricks, die einen wert messen und einen A/D-Wert zurückliefern (Temperatur, Entfernung, Feuchtigkeit, Luftdruck etc.). Die prozeduren haben anstelle einer method 'value' einzeln benannte 'humidity', 'temperature' etc. Macht mich wahnsinnig 

 

In diesem Zusammenhang ist ein Abstraktionslayer sehr sinnvoll. Ohne falsche Bescheidenheit - die TF-Blöcke in Objective-C zu programmieren (mit meinem Layer natürlich - ich sagte ja *ohne* Bescheidenheit) ist viel eleganter und schneller als mit purem C.

 

Andererseits - wo bleibt denn bei voll durchengineerten Layers der Bastlerspass?

 

-ch

 

[teichsta]

Andererseits - wo bleibt denn bei voll durchengineerten Layers der Bastlerspass?

 

beim basteln (mit der Hardware) ;-)

[AuronX]

Also ich bin ja selbst nicht TF, deswegen ist meine Antwort nur zum Teil gültig

 

Aber ich denke nicht, dass es möglich wäre die aktuelle Vielfalt an unterstützten Programmiersprachen ohne automatische Erzeugung der Bindings zu erreichen.

 

Es gibt viele Situationen wo das Generieren sinnvoll ist:

• Beim Hinzufügen eines neuen Bricks/Bricklets (generiere für alle Sprachen das neue Device)
  
• Beim Hinzufügen neuer API zu einem/vielen Bricks/Bricklets (generiere für alle Sprachen die neuen Funktionen)
  
• Bei Veränderung des Zusammenspiels zwischen IPConnection und Devices (vor kurzem passiert; generiere für eine Sprache ALLE Devices neu)
  
• Bei grundlegenden Design-Änderungen (Upgrade auf Protokoll 2.0; generiere für alle Sprachen alles neu)
  

 

Bestimmt habe ich noch etwas vergessen ^^

 

Das Generieren der Bindings hat halt immense Vorteile für die Entwicklung, dadurch wird das alles erst möglich. Der Nachteil: Die API einzelner Sprachen ist suboptimal, aber noch immer besser als vieles was ich sonst so gesehen habe

 

P.S.:

Ohne falsche Bescheidenheit - die TF-Blöcke in Objective-C zu programmieren [...] ist viel eleganter und schneller als mit purem C.

 

Es wäre traurig wenn nach Schema F generierte Bindings eleganter wären als deine mit viel Schweiß erzeugten Handcrafted Bindings

 

Das Argument mit Humidity vs. Value sehe ich nur zur Hälfte ein:

Ja es wäre natürlich leichter, weil du im Zweifel nur einen einzigen Wrapper brauchst.

Aber nein, es wäre schlechter Stil, weil eine API (und das haben wir hier) immer aussagekräftig und lesbar sein sollte.

 

P.P.S.: In meinem eigenen Code gehe ich sogar so weit, dass ein DistanceSensor keinen int zurückliefert sondern eine Distance, dort unterscheidet sich also sogar der Rückgabetyp

[cfranz]

Aber nein, es wäre schlechter Stil, weil eine API (und das haben wir hier) immer aussagekräftig und lesbar sein sollte.

 

P.P.S.: In meinem eigenen Code gehe ich sogar so weit, dass ein DistanceSensor keinen int zurückliefert sondern eine Distance, dort unterscheidet sich also sogar der Rückgabetyp 

 

Das ist natürlich eine hochinteressante frage der philosophie beim programmieren. Klar müssen API aussagekräftig und lesbar sein, doch die Frage ist hier die Interpretation des Wortes 'aussagekräftig' bzw. 'lesbar'. Wenn aus dem Kontext klar ist, um was für ein objekt es sich handelt, ist die 'value' funktion (meiner meinung nach) genau so lesbar wie 'geschwindigkeit'.

 

als code-dinosaurier habe ich natürlich beide arten der programmierung kennen gelernt. dein besipiel ist ein klassischer vertreter der hochverlässlichen programmierung wie sie bei kritischen systemen (z.b. kraftwerken, schiffssteuerungen) zu anwendung kommt: eieindeutiger code, auditierbar, hochgeradig wartbar, sicher. die nachteile (kaum refactoring oder reuse) fallen nicht ins gewicht, weil diese art von code spezifisch hergestellt wird. ich habe selber einmal für ein jahr im team so programmiert - für ein echtzeitsystem einer bank, die damit zahlungen abwickelt. da muss jede zeile sitzen, doppeldeutigkeiten sind ein no-go.

 

der objektorientiere ansatz (generische prozedurnamen - z.b. gibt es in einem grafikprogramm x verschiedene geometrische objekte, die alle die generische nachricht 'draw' kennen) kommt dann zum einsatz, wenn es nicht so auf die code-sicherheit ankommt und der code effizient programmiert (nicht unbedingt ausgeführt) werden soll. in den letzten zwanzig jahren habe ich diese art des programmieres sehr zu schätzen gelernt. in der programmierung von consumer-applications, wo ein fehler keine katastrophalen auswirkungen hat, kann ich so für den bruchteil des aufwandes eine gute, lauffähige app schreiben - die immerhin noch 80% der resilienz einer klassichen secure app hat.

 

wo passen da die TF block APIs ins bild? ich glaube, die art wie heute die bindings erzeugt werden, hat sehr viel damit zu tun. Da viele verschiedene sprachen unterstützt werde sollen, wird ein generator verwendet. bei dem design des generators wurde das augenmerk (meiner meinung nach) darauf gelegt, möglichst schnell und verlässlich ein akzeptables ergebnis zu liefern. Dies erfüllt der generator gut. dass das ergebnis nicht alle glücklich macht war nicht nur vorhersehbar, es ist auch einigermassen irrelevant - denn jeder, der nicht zufrieden ist kann sich ja (so wie ich) hinsetzen und was "besseres" machen - und dann hier darüber philosophieren, wie viel besser die welt doch wäre, wenn er selber das sagen hätte.

 

Nur weil ich hier über das API rummeckere heisst das noch lange nicht, dass es schlecht ist oder meine Lösung besser. Wie heisst es so schön: "gute ideen gibt es viele..."

 

Als 99% software-Typ (ich verstehe fast gar nichts von elektronik) ist es klar, dass ich mich auf die SW stürze und damit rumspiele. Was ich mit meinen bricks baue ist dementsprechend wenig anspruchsvoll. dafür ist die software voll durchgestylt. Am wichtigsten für mich aber: ich habe extrem viel spass.

 

-ch