3. Kommunikation von Klassen

Kommunikation von Klassen

  • B

    Hallo,

    eine klasse Messdaten möchte Daten an die Klasse Diagramm senden.

    Wie würden die Klassen ausschauen, welche Methoden haben sie ?

    class Diagramm
{

private:

Messdaten* ptr;

}

class Messdaten
{

private:

int messungen[10];
}
    0
  • M
     

    struct Diagramm
{
    void doIt() { Diagramm d; d.gimmeDaData(ptr); }

private:
    Messdaten* ptr;
};

struct Messdaten
{
    void gimmeDaData(Messdaten*);

private:
    int messungen[10];
};

    Im Ernst: Was willst du hören?

    0
  • B

    kann man schon so weit gehn , wenn sich die messdaten geändert haben,
    und da der Zeiger ja drauf zeigt, wurde dadurch eine Nachricht an
    Diagramm von Messdaten gesendet ? drückt das ein Kommunikationsdiagramm aus ?

    du wolltest bestimmt folgendes oder.

    struct Diagramm 
{ 
    void doIt() { Messdaten d; d.gimmeDaData(ptr); } 

private: 
    Messdaten* ptr; 
}; 

struct Messdaten 
{ 
    void gimmeDaData(Messdaten*); 

private: 
    int messungen[10]; 
};
    0
  • ?

    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)

    0
  • B

    aha.

    noch eine Frage.

    Was ist design by contract.

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

    0
  • D

    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.

    0
  • B

    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.

    0
  • ?

    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!!!

    0
  • ?

    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.

    0
  • D

    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.

    0
  • B

    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.

    0
  • ?

    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.

    0
  • D

    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.

    0
Anmelden zum Antworten