Ich habe einen komplexen C++-Source von jemandem übernommen, der vom Typ her ein C-Programmierer ist. Der Source besteht aus mehreren Algorithmen, die jeweils aus zahlreichen Einzelfunktionen bestehen, die einfach hintereinander abgearbeitet werden. Eine gewissen Gruppierung wurde durch Namespaces erzielt, aber die sind nested und bis zu drei Ebenen tief. Der Code ist schwer lesbar, und ich muß ihn umorganisieren, damit er wartbar wird.

Ich halte es für sinnvoll, pro Algorithmus eine eigene Klasse zu machen, die dessen Einzelfunktionen gruppiert und auf natürliche Weise nach außen kapselt. Andererseits besteht nach meinem Verständnis ein Objekt aus Daten _und_ Methoden, aber nicht aus Methoden alleine. Was denkt Ihr, sollte eine zusammengehörige Ansammlung von Funktionen eine Klasse sein?

lg
bts

Ich habe einen komplexen C++-Source von jemandem übernommen, der vom Typ her ein C-Programmierer ist

Ich will jetzt nicht bashen, aber genau das is denke ich das Problem :D.
rya.

Wenn das alles nicht zutrifft, brauchst du keine Klasse. Implementierungen kannst du auch vor dem Anwender in der Implementierungsdatei verstecken. Im Header braucht nur die Deklaration der aufzurufenden Funktionen zu stehen.

Der Source besteht aus mehreren Algorithmen, die jeweils aus zahlreichen Einzelfunktionen bestehen, die einfach hintereinander abgearbeitet werden.

Solange keine Threads vorkommen, ist das auch in einem objektorientierten Programm der Fall

bts2 schrieb:

Eine gewissen Gruppierung wurde durch Namespaces erzielt, aber die sind nested und bis zu drei Ebenen tief.

Uh! Wie schlimm!
Das ist bei mir Standard:
<firma>::<library>::<teilbereich>

bts2 schrieb:

Der Code ist schwer lesbar, und ich muß ihn umorganisieren, damit er wartbar wird.

Erinnert mich an irgendeinen Thread, wo es mal hiess, dass man den Code von anderen Programmierer nie für wartbar hält

bts2 schrieb:

Ich halte es für sinnvoll, pro Algorithmus eine eigene Klasse zu machen, die dessen Einzelfunktionen gruppiert und auf natürliche Weise nach außen kapselt. Andererseits besteht nach meinem Verständnis ein Objekt aus Daten _und_ Methoden, aber nicht aus Methoden alleine. Was denkt Ihr, sollte eine zusammengehörige Ansammlung von Funktionen eine Klasse sein?

Objekte müssen nicht immer reale Objekte repräsentieren und somit auch nicht immer Daten halten. Sieh dir zum Beispiel das Strategy-Pattern an.
Allerdings muss auch nicht immer alles in einer Klasse stehen. Um ein paar Funktionen zu gruppieren, kann man auch Namensräume mit freien Funktionen verwenden. Mache ich des Öftern.

Grüssli

Objekte müssen nicht immer reale Objekte repräsentieren und somit auch nicht immer Daten halten. Sieh dir zum Beispiel das Strategy-Pattern an.

Nur mal eine theoretische Frage...
Welchen Vorteil bietet mir das Objekt für einen Algorithmus beim Strategy-Pattern
gegenüber einem Funktionszeiger?

Nur mal eine theoretische Frage...
Welchen Vorteil bietet mir das Objekt für einen Algorithmus beim Strategy-Pattern
gegenüber einem Funktionszeiger?

Einhalten der Schnittstelle. Vielleicht benötigen gewisse Algorithmen zusätzliche Daten und andere nicht. Man könnte natürlich auch alles über boost::function oder ähnliches lösen, aber zum Teil ist auch einfach eine Basisklasse für die verschiedenen Strategien sauberer und auch lesbarer.

Grüssli

thx

Ich habe einen komplexen C++-Source von jemandem übernommen, der vom Typ her ein C-Programmierer ist. Der Source besteht aus mehreren Algorithmen, die jeweils aus zahlreichen Einzelfunktionen bestehen, die einfach hintereinander abgearbeitet werden. Eine gewissen Gruppierung wurde durch Namespaces erzielt, aber die sind nested und bis zu drei Ebenen tief. Der Code ist schwer lesbar, und ich muß ihn umorganisieren, damit er wartbar wird.

Ich halte es für sinnvoll, pro Algorithmus eine eigene Klasse zu machen, die dessen Einzelfunktionen gruppiert und auf natürliche Weise nach außen kapselt.

Hört sich so an, als ob der "C-Programmierer" ein richtiger C++ Profi war und du ein Java Programmierer bist.

Ich halte es für sinnvoll, pro Algorithmus eine eigene Klasse zu machen, die dessen Einzelfunktionen gruppiert und auf natürliche Weise nach außen kapselt. Andererseits besteht nach meinem Verständnis ein Objekt aus Daten _und_ Methoden, aber nicht aus Methoden alleine. Was denkt Ihr, sollte eine zusammengehörige Ansammlung von Funktionen eine Klasse sein?

nicht notwendigerweise

normalerweise würde ich das in einen namespace stecken.
wenn einige der funktionen "privat" sein sollen, dann kommen die in ein .cpp file, in einen anonymen namespace.
wenn sie in mehreren .cpp file gebraucht werden dann sind die entweder nicht "privat" und kommen ganz normal in den namespace, oder sie kommen in einen "detail" namespace.

Auch wenn Du deine Algorithmen polymorph verwenden möchtest benötigst du Klassen.

Stimmt doch gar nicht.