OOP in der Messtechnik

Hallo C++ Gemeinschaft,

Ihr habt Euch hier wirklich ein tolles Forum aufgebaut und mir durch die vielen interessanten Beiträge schon sehr geholfen.

Ich arbeite momentan an einem Messtechnik-Projekt und habe mich, in Hinblick auf die zukünftige Weiterentwicklung der Software, entschieden objektorientiert zu programmieren. Nun bin ich auf dem Gebiet noch recht unerfahren und so schwanken meine Gefühle wöchentlich zwischen „Warum habe ich mir das angetan?“ und „Bloß gut, dass ich diesen Ansatz gewählt habe.“

Ein Problem sieht derzeit folgendermaßen aus. Nehmen wir mal an, es gäbe die drei Objekte Datenerfassung, Daten und Anzeige. So wären aufgrund des Prinzips „Verstecken von Informationen im Objekt“ mehrere Kopiervorgänge der Messdaten notwendig. Vom Objekt Datenerfassung zum Objekt Daten und schließlich zur Anzeige. Gäbe es noch eine Klasse Signalverarbeitung wären es sogar noch mehr.

An und für sich kein Problem. Da es nun aber viele Messdaten sind, ist diese Vorgehensweise zeitintensiv und bei mehrfacher Ausführung hintereinander (500-mal) leider ein Problem.

Könnt Ihr mir evtl. Literatur empfehlen, oder sonstige Hinweise geben, wie ich derartige Probleme elegant lösen könnte. Vielleicht liege ich mit meinem OO-Ansatz bei dieser Aufgabe ja auch gänzlich falsch.

Gruß

EinGast

darthdespotism

Literatur hab ich dir keine aber an der Stelle würde ich wohl die Messdaten kapseln und als Referenz weitergeben, dann muss nichts kopiert werden

Hallo darthdespotism,

Danke für Deine Antwort.

Die Messdaten befinden sich im Daten-Objekt. (Ich könnte es auch Messdaten-Objekt nennen.) Benötigt nun ein Objekt, z.B. die Anzeige, diese Messdaten, so übergebe ich dem Anzeige-Objekt den Handle des Messdaten-Objekts.

Die Messdaten sind private und so kann die Anzeige nur über eine entsprechende Methode (GetData) auf die Daten zugreifen. Die Folge, die Daten werden kopiert. Möchte ich das Kopieren umgehen, muss ich die Messdaten als public deklarieren. Soweit mein Verständnis.

Genauso läuft es auch bei der Datenerfassung ab. In diesem Fall mit der Methode SetData, aber wiederum werden die Daten kopiert.

Die Deklaration als public möchte ich jedoch nur im Notfall vornehmen, denn so könnten ja die Daten von außen manipuliert werden. Was beim Zugriff über Methoden nur kontrolliert möglich ist.

Wenn ich nun eine Referenz übergebe, hätte ich doch wieder das Problem, dass die Daten direkt manipuliert werden können.

Genau das ist der Punkt, wo ich mich im Kreis drehe.

Gruß

EinGast

thordk

class C
{
 int dat;

 public:
 const int & getDat() { return dat; }
};

so bekommst du eine const referenz. es wird nix kopiert, aber es ist auch kein anderer wert zuweisbar.

hustbaer

Wenn die Daten einfach nur Daten sind spricht IMO nix dagegen sie einfach in eine public Struktur zu packen.
Der "Anzeige" Klasse gibst du einfach eine const Referenz auf die Daten, der "Datenerfassung" Klasse gibst du eine normale Referenz.
Fertig.

Da viel mit (Daten-)Klassen rumzuwerken halte ich für übertrieben.

Hallo thordk, Hallo hustbaer,

ebenfalls Danke für Eure Hilfe.

Eine gute Idee die const Referenz. Sozusagen ein Kompromiss zwischen Aufwand und Nutzen. Werde das so machen.

Es wäre sicher auch kein Problem die Daten public zu definieren. Als ich jedoch mit der OOP begann und in ein paar Büchern las das public-Daten viele Nachteile haben, packte mich dann irgendwie der Ehrgeiz. Da fehlt eben noch die Erfahrung, wo welcher Aufwand gerechtfertigt ist.

Ansonsten hat so eine Messdaten-Klasse, im Gegensatz zum Mehraufwand, auch einige Vorteile. So kann ich die Daten leicht im Programm herumreichen oder mehrere Messreihen im Arbeitsspeicher aufbewahren. Diese später vergleichen, speichern, laden und anzeigen. Z.B. Speichern und Laden bringt die Klasse als Funktionalität gleich mit.

Das eigentliche Problem (zu langsam) trat erst auf, als ich begann Messdaten zu mitteln (500-mal). Aber nun ist ja eine Lösung gefunden.

Gruß

EinGast

thordk

public member sind nur dann von nachteil, wenn deine klasse methoden anbietet, diese member zu manipulieren, die davon ausgehen, dass die member ihren zustand nicht durch externe einflüsse ändern.

ganz simples beispiel, welches keinen anspruch auf vollständigkeit erhebt.

class Foo
{
  public:
  int *p;
  Foo()
  {
    p = new int;
    *p = 23;
  }
  void show()
  {
    std::cout << *p << std::endl;
  }
}

das ding ist so konstruiert, dass die methode show davon ausgeht, dass der konstruktor dafür sorgt, dass p ein gültiger wert zugewiesen wird. da das ding aber public ist, könnt irgendwer auf die idee kommen, das ding von außerhalb zu löschen oder auf ungültigen speicherbereich zu biegen. deine methode show würde also im schlimmsten fall dein programm zum absturz bringen.

außerdem werden getter/setter gern verwendet, wenn mehr als eine einfache zuweisung oder rückgabe eines internen wertes nötig ist. wenn alle member 1:1 auf getter/setter abgebildet werden, handelt es sich sehr wahrscheinlich um eine simple datenstruktur. in so einem fall könnten auch alle member public gemacht werden (empfiehlt sogar die in dieser hinsicht sehr rigide sprache java).
allerdings könnte man sich damit selbst ins knie schiessen, wenn man die klasse irgendwann doch mal erweitern möchte und für einen member ein bisschen mehr interne logik beim zugriff benötigt. und aus diesem grund gilt der grundsatz "alle member private".

hustbaer

wenn alle member 1:1 auf getter/setter abgebildet werden, handelt es sich sehr wahrscheinlich um eine simple datenstruktur

Jo, genau den Fall meinte ich.