c++: member acces to other members of parent
wergor 02.03.2018 - 11:04 2735 7
wergor
connoisseur de mimi
|
ich habe eine klasse (wetterstation) die mehrere andere klassen (sensoren) als member enthält. die sensor-klassen haben ein einheitliches interface und sind komplett unabhängig voneinander. sie werden einmal konfiguriert und werden danach nur noch gelesen. class ObservingConditions
{
[...]
private:
YAAASensor *sensor_dew_point_;
YAAASensor *sensor_humidity_;
YAAASensor *sensor_temperature_;
};
class YAAASensor
{
public:
[...]
virtual bool begin() = 0;
virtual bool measure() = 0;
virtual bool hasValue() = 0;
virtual float getValue() = 0;
};
in diesem beispiel lässt sich der taupunkt aus der temperatur und luftfeuchtigkeit berechnen. wie verschaffe ich dem objekt sensor_dew_point_ zugriff auf die anderen beiden sensoren? ich könnte dem taupunktsensor referenzen auf die anderen beiden sensoren mitgeben, was aber imho bestenfalls fragwürdig ist, oder eine referenz auf das ObservingConditions objekt, was mir aber auch nicht so recht gefallen mag. das YAAASensor interface will ich nicht ändern und den einen sensor auch nicht anders behandeln als alle anderen (also keine zusätzlichen funktionen).
|
Obermotz
Fünfzylindernazi
|
|
tinker
SQUEAK
|
Vielleicht überseh ich grad was, aber warum machst du die Berechnung nicht einfach in der Klasse ObservingConditions? Dort hast du Zugriff auf alle Sensoren.
Und was ich nicht ganz check: Warum gibt es einen eigenen Sensor für den Taupunkt, wenn er aus den Daten der anderen beiden Sensoren berechnet wird?
|
-=Willi=-
The Emperor protects
|
Vielleicht überseh ich grad was, aber warum machst du die Berechnung nicht einfach in der Klasse ObservingConditions? Dort hast du Zugriff auf alle Sensoren.
Und was ich nicht ganz check: Warum gibt es einen eigenen Sensor für den Taupunkt, wenn er aus den Daten der anderen beiden Sensoren berechnet wird? Ja seh ich auch so. Ich würd `sensor_dew_point_` entfernen und `ObservingConditions` ein paar Methoden zum Holen/Berechnen der eigentlichen Werte geben.
|
that
Hoffnungsloser Optimist
|
in diesem beispiel lässt sich der taupunkt aus der temperatur und luftfeuchtigkeit berechnen. Damit ist es kein Sensor, sondern ein Berechner. wie verschaffe ich dem objekt sensor_dew_point_ zugriff auf die anderen beiden sensoren? ich könnte dem taupunktsensor referenzen auf die anderen beiden sensoren mitgeben, was aber imho bestenfalls fragwürdig ist, oder eine referenz auf das ObservingConditions objekt, was mir aber auch nicht so recht gefallen mag. Fragwürdig ist es nur, weil du verschiedene Dinge mit dem selben Interface behandeln willst und dein Interface "Sensor" heißt. Ich würde es auch fragwürdig finden, wenn ein Sensor irgendwas von anderen Sensoren wissen soll. Wenn du YAAASensor aber weniger als Sensor-Interface siehst, sondern eher als einheitliches Interface zum *Auslesen* von Sensordaten oder abgeleiteten Daten, ist das in Ordnung. Du hast aber hinter dem Interface zwei grundverschiedene Implementierungen deiner "Sensoren": Echte Sensoren messen irgendwas aus der Außenwelt, und dein "Taupunktsensor" leitet Daten aus anderen Sensoren ab. Damit brauchst er eine andere Implementierung, und da darf er durchaus andere Sensoren kennen. Das ist aber ein Implementierungsdetail und muss/soll sich nicht auf das Auslese-Interface auswirken.
|
wergor
connoisseur de mimi
|
Und was ich nicht ganz check: Warum gibt es einen eigenen Sensor für den Taupunkt, wenn er aus den Daten der anderen beiden Sensoren berechnet wird? die idee dahinter ist, dass ich stattdessen einen physischen taupunktsensor verwenden könnte, dann müsste ich nur ein anderes objekt instanzieren und mich um sonst nichts kümmern. die einfachste lösung wäre natürlich die taupunktberechnung in ObservingConditions zu implementieren, ich würde aber gerne das sammeln / berechnen von daten von dieser klasse getrennt halten.
|
Vinci
hatin' on summer
|
Ist imho eine legitime Idee und damit ein klasssiches Dependency Injection Problem. Ich würde das YAAASensor Interface um eine Variante erweitern, die die beiden anderen Sensoren im Konstruktur schluckt. class YAAASensorMock : public YAAASensor {
YAAASensorMock(YAAASensor* hs, YAAASensor* ts) : hs{hs}, ts{ts} {}
virtual bool hasValue() final { ... };
private:
YAAASensor* hs;
YAAASensor* ts;
};
Naja, nein, würd ich eigentlich nicht.  Ich würd das Sensor-Interface mittlerweile wohl als Concept anlegen um die vtables verlässlich loszuwerden... aber das ändert am grundlegenden Design nichts.
|
wergor
connoisseur de mimi
|
ich werde die berechnung in der ObservingConditions klasse implementieren, ist die saubere lösung (glaube ich).
|