Kommunikation von Klassen

Ich glaub du suchst etwas wie Listener...

http://de.wikipedia.org/wiki/Listener

Nach dem Schema (ungetestet):

class MeasuringData;

class MeasuringDataListener{
public:
	virtual ~MeasuringDataListener(){}
	virtual void measuringDataChanged(const MeasuringData&, int pos, double value) = 0;

};

class MeasuringData{

public:
	void setData(int pos, double value){
		for(std::vector<MeasuringDataListener>::const_iterator = listeners.begin(); it!=listeners.end(); ++it){
			(*it)->measuringDataChanged(*this, poa, value);
		}
	}

	void addListener(MeasunringDataListener& listener){
		listeners.push_back(&listsner);
	}

private:
	std::vector<MeasuringDataListener*> listeners;
};

class Diagramm : public MeasuringDataListener{
public:
	Diagramm(MeasuringData& data){
		data.addListener(*this);
	}

	virtual void measuringDataChanged(const MeasuringData&, int pos, double value){
		// update diagramm
	}

}

EDIT: Naja... Man sollte den Listener spätestens im Destruktor wieder entfernen... (zusätzliches Feld auf MeasuringData notwendig)

blurry333

aha.

noch eine Frage.

Was ist design by contract.

Zwischen wem wird hier ein Vertrag geschlossen ?
Den Entwicklern ? Den Klassen ?

drakon

http://de.wikipedia.org/wiki/Design_by_contract

Grob gesagt:
Pre/Postconditions und Invarianten genau definieren.

Was das mit einem Vertrag zu tun hat: Als Benutzer einer Schnittstelle ist man verpflichtet die Precondition einzuhalten und kriegt dafür die Postcondition garantiert.

blurry333

Soll das heissen man prüft falsche Eingaben nicht und verlässt sich
auf den Benutzer ?

Noch eine fRage zum unified process.
ER wird doch in Unternehmen heutzutage verwendet. Da der Wasserfall bei großen
Projekten zu statisch ist. Es muss ja jede Phase abgeschlossen sein.

Was bedeuten diese humps also Hügel im Diagramm. Was bedeutet die Y-Achse
also z.B. IMplementation , test, deploment. DAs hab ich doch in der Phase
inception gar nicht dort werden doch erst nur die Anforderungen erarbeitet.

blurry333 schrieb:

Soll das heissen man prüft falsche Eingaben nicht und verlässt sich
auf den Benutzer ?

Ganz einfach:
Wenn du deine Bedingungen einhälst, garantiert dir dein Programm ein gewisses
Verhalten.

Dabei ist der Benutzer der Entwickler!!! Nicht der Endbenutzer!!!

Ganz einfaches Beispiel:

Du hast eine Methode, die dir alle Primzahlen bis zu einer Zahl ausgibt.

Diese verlangt von dir, dass die übergebene Zahl größer als 0 ist.

Wenn der Entwickler jetzt eine Zahl dafür von der Tastatur einliest, muss
er vorher selber checken, damit die Bedingung erfüllt ist.

Falls die Logik des Programm es allerdings verbietet, dass diese Zahl
(sie kommt jetzt woanders her) <= 0 ist, dann braucht er sich um nichts zu kümmern.

drakon

Um mal CSpille in (Eiffel)-Code zu demonstrieren
(Kommentare kommen nach '--' )

my_function (in: INTEGER) : INTEGER
 local                              -- lokale Variablen definieren
   temp: INTEGER
 require                            -- hier fängt der Block mit Preconditions an
   in_greater_zero: in >= 0         -- in muss grösser 0 sein, ansonsten gibts einen Runtime Fehler, wo das Tag 'in_greater_zero' angezeigt wird
 do
   -- do some stuff
   Result := temp                   -- Result enthält den Rückgabewert
 ensure                             -- Block mit Postconditions
   greater_10: Result > 10          -- Rückgabewert muss Grösser 10 sein, ansonsten wieder Runtime Fehler.
 end

Der Vertrag (Contract) kommt hier zwischen dem Anwender der Funktion und dem Programmierer der Funktion zustande. Wenn der Anwender einen Integer Grösser/Gleich 0 übergibt, dann kann er sich darauf verlassen, dass die Funktion korrekt funktioniert und der Rückgabewert Grösser 0 ist.

Eiffel ermöglicht es 1:1 solche Contracts in Code abzubilden, was auch kein Wunder ist, denn der Entwickler von "Contract by Design" ist auch der Gründer dieser Sprache.

blurry333

Noch eine fRage zum unified process.
ER wird doch in Unternehmen heutzutage verwendet. Da der Wasserfall bei großen
Projekten zu statisch ist. Es muss ja jede Phase abgeschlossen sein.

Was bedeuten diese humps also Hügel im Diagramm. Was bedeutet die Y-Achse
also z.B. IMplementation , test, deploment. DAs hab ich doch in der Phase
inception gar nicht dort werden doch erst nur die Anforderungen erarbeitet.

Schöner Beispielcode!

drakon schrieb:

ensure                             -- Block mit Postconditions
   greater_10: Result > 10          -- Rückgabewert muss Grösser 10 sein, ansonsten wieder Runtime Fehler.

Als zusätzliche Anmerkung an blurry333:
wobei in C++ Runtime-Fehler i.d.R. != Exception...
Wird in Eiffel ne Exception geworfen? (Ich hab 0 Plan von Eiffel)
Nicht Erfüllen der Preconditions kann z. B.

falsches Ergebnis
Endlosschleife
undefiniertes Verhalten (z. B. Programmabsturz)

zur Folge haben.

drakon

In Eiffel gibt es so etwas, wie Exceptions nicht. Das würde komplett gegen die Mentalität von Eiffel/Meyers gehen.

Ein verletzen einer Condition hat einen Laufzeitfehler zur Folge (ausser mal stellt die naütrlich aus), wie bei C/C++ Programmen assertions (also mit assert ).

Wenn die Conditions aber ausgeschaltet sind (das kann man sehr selektiv machen mit EiffelStudio), dann tauchen natürlich die genannten Sachen auf.