c++: member acces to other members of parent

Seite 1 von 1 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/c-member-acces-to-other-members-of-parent_250891/page_1 - zur Vollversion wechseln!

wergor schrieb am 02.03.2018 um 11:04

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.

Code: CPP

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 schrieb am 02.03.2018 um 11:22

Einen back pointer auf parent koenntest du schon im Interface definieren, das ist nicht perfekt aber dennoch eine recht gaengige practice.

https://softwareengineering.stackex...he-parent-class

tinker schrieb am 02.03.2018 um 11:23

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=- schrieb am 02.03.2018 um 11:28

Zitat aus einem Post von tinker
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 schrieb am 02.03.2018 um 11:30

Zitat aus einem Post von wergor
in diesem beispiel lässt sich der taupunkt aus der temperatur und luftfeuchtigkeit berechnen.

Damit ist es kein Sensor, sondern ein Berechner.

Zitat aus einem Post von wergor
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 schrieb am 02.03.2018 um 12:32

Zitat aus einem Post von tinker
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 schrieb am 02.03.2018 um 13:01

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.

Code: C++

class YAAASensorMock : public YAAASensor {
  YAAASensorMock(YAAASensor* hs, YAAASensor* ts) : hs{hs}, ts{ts} {}

  virtual bool hasValue() final { ... };

private:
  YAAASensor* hs;  // humidity
  YAAASensor* ts;   // temperature
};

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 schrieb am 03.03.2018 um 09:53

ich werde die berechnung in der ObservingConditions klasse implementieren, ist die saubere lösung (glaube ich).