Aggregation: Objekt in Aggregat ändern oder nicht?

mein Vorschlag wäre folgender

- Klasse A (Hauptalgo) als Member in B
- Klasse B beinhaltet den Vector, auf den die Berechnungen stattfinden sollen.
- Deine Algo-funktionen bekommen als Übergabeparameter den Vector, zum Beispiel per Referenz, falls dort direkt was geaendert werden soll.

Vorteil der ganzen Sache ist, dass du die Klasse deines Hauptalgorithmus nicht staendig von Programm zu Programm abaendern musst.

das verstehe ich nicht ganz - das würde ja alles umdrehen !? Wie kann ich denn dann in einer klasse C den hauptalgorithmus aufrufen wenn er selbst nur member ist !?

BasicMan01

Wo kommt auf einmal eine Klasse C her ... die hast du dir doch ausgedacht

in welchem Zusammenhang soll sie zu A oder B stehen?
Wird C von B vererbt?
Ist C eine komplett eigenständige Klasse die vielleicht auch A als Member benötigt, um auf die Algo-Funktionen zugreifen zu können?

Hmm...naja...also mein Algorithmus ist doch komplett sauber in einer eigenen Klasse:

class Algorithmus
{
    public:
        void ersterSchritt() {}
        void zweiterSchritt() {}
        //...

     B b;
};

dieser algorthmus wird natürlich so niht laufen - ich muss ihn irgendwo z.B. in der main aufrufen oder in einer sonstigen Klasse.

Und jetzt will ich eben die ganzen rechnungen von Algorithmus nicht in Algorithmus sondern z.B. in einem Member Klasse B machen.

ich steh jetzt auf dem schlauch

drakon

Dann implementier doch in B entsprechend die Methoden, die nötig sind und ruf sie von Algorithmus auf. Wo genau ist denn da das Problem?

Wie man Klassen und Funktionen dazu erstellt ist dir, nehme ich mal klar, oder?

Ja das hatte ich auch vor aber in meinem ersten post hatte ich ja gefragt
ob es sauberer ist den std::vector in Algorithmus zu halten und dann an B zu übergeben oder eben in B den std::vector halten und dort einfach über die methodenaufrufe zu verändern....

BasicMan01

ich hab mal eben was zusammengepfuscht ohne jetzt mit Iteratoren zu handieren.
aber das kann man ja beliebig erweitern.

class Algorithmus
{
    public:
        void ersterSchritt(std::vector<int> &vec) {}
        void zweiterSchritt(std::vector<int> &vec) {}
};

class B
{
	private:
		Algorithmus algo;
		vector<int> vecDaten;

	public:
		void berechnen()
		{
			algo.ersterSchritt(vecDaten);
		}
};

int main(int argc, char *argv[])
{
	B b;

	b.berechnen();

	return 0;
}

drakon

So kann man es machen.
Die Frage kann man aber imo nicht generell beantworten. Es kommt drauf an, wohin der vector eher gehört. Gehört er eher zu B oder zu Algorithmus ?

Ich könnte mir z.B vorstellen, dass du verschiedene Implementierungen von ersterSchritt und zweiterSchritt haben kannst und dann macht es schon Sinn, dass die Daten zu B gehören und nicht zu Algorithmus , weil du dann die Verfahren on the fly ändern kannst ohne da irgendwie etwas rumkopieren zu müssen.
Wenn der vector allerdings lediglich eine Art zwischenspeicher für das Endergebnis ist, dann könnte der schon auch in Algorithmus gehalten werden.

Man kann sicher noch mehr ähnliche Beispiele finden, aber ich denke du verstehst, auf was ich hinaus will.

Hmm danke für das beispiel...ich frage mich nur - macht man das immer so? Also dass man eher von unten hoch gliedert?

BasicMan01

AnfaengerNeu++ schrieb:

[...] macht man das immer so? [...]

Nein, das hängt immer vom Anwendungsfall ab. Wie drakon schon beschrieb.
Ich habe mich an deinem von gestern erstellten Thread orientiert

http://www.c-plusplus.net/forum/viewtopic-var-t-is-266924.html

dort heißt es:

AnfaengerNeu++ schrieb:

ich habe eine ganz einfache frage: Ich habe mehrere klassen die alle einen hauptalgorithmus darstellen. Alle diese klassen haben mehrere Methoden gemeinsam.

mehrere Methoden gemeinsam deutet darauf hin, dass man diese nicht ständig pro Klasse anpassen muss.

DocShoe

Für solche Sachen gibt es sogar ein eigenes Entwurfsmuster (falls der Algorithmus austauschbar sein soll): Schablonenmethode.