Geschmacksfrage: Ist ein Algorithmus eine Klasse?

Hallo!

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

Eine Klasse muss in sich funktionieren und erhält von aussen nur bestimmte Parameter unter denen sie ihre Arbeit ausführt.
Eine Ansammlung von Funktionen ist eben nur das. Eine Klasse ist ein Objekt, welches mehr oder weniger eigenständig arbeitet.

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.

brotbernd

Du brauchst keine Klasse zu bemühen um etwas zu Gruppieren oder nach aussen zu kapseln. Ein Algorithmus ist ein Objekt, wenn er einen Zustand hat. Auch wenn Du deine Algorithmen polymorph verwenden möchtest benötigst du Klassen. In Kombination mir der STL empfiehlt es sich ausserdem manchmal eine 'Funktion' von den stl Basisklassen für Funktoren abzuleiten.

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.

Dravere

bts2 schrieb:

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

Dravere schrieb:

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?

brotbernd

Mehr Flexibilität. Ich kann beliebige Argumente an ein Objekt "binden".
Kann man mit function oder einer eigenen Strategie Klasse machen.

Dravere

CSpille schrieb:

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

Stimmt allerdings...

thx

bts2 schrieb:

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.

volkard

Meistens kommt wohl nicht viel dabei heraus, wenn man sortByFoo(v) umschreibt zu Foo().sort(v). Aber es gibt Lehrbücher, die lehren die Vererbung anhand von Bubblesort:Sort, BerechneKreis:BerechneGeo und ähnlichen Albernheiten.

hustbaer

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?

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.

brotbernd schrieb:

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

Stimmt doch gar nicht.