ich habe ein kleines Antipattern-Problem
Je mehr Funktionalität ich einbaue, neigen meine Klassen manchmal dazu, dass sie sich etwas aufblähen. Die Frage ist: bis zu welchem Grad sind große Klassen tolerierbar und ab wann spricht man von einer "Gottklasse" ?

In meinem Fall habe ich eine Klasse Matrix entwickelt, die schon in die Richtung einer Gottklasse geht. Sie enthält

- die notwendigen Konstruktoren um eine m x n Matrix zu erstellen
- Get(i,j); und Set(i,j,value);
- überladene Operatoren: *+ - * = += -= = << >> == !=
- Extend(b); // Matrix A zu [A b] erweitern
- Transpose(); // transponierte Matrix zurückgeben
- Inverse(); // Inverse berechnen
- Det(); // Determinante berechnen
- Submatrix(i,j); // Untermatrix zurückgeben (entsteht durch Streichen von Zeile i und Spalte j)
- Gauss(); // Gauss-Algorithmus (Matrix auf Dreiecksform bringen)
- Decomposite(L,U); // LR-Zerlegung durchführen (A=L*U)
- ColumnPivotSearch(); // Spaltenpivotsuche
- TotalPivotSearch(); // Vollständige Pivotsuche
- SwapRows(row1, row2); // Zeilentausch
- SwapCols(col1, col2); // Spaltentausch

Hier bin ich etwas unentschlossen, ob und wie ich die Klasse sinnvoll entschlacken kann. Sinnvoll wäre es vielleicht, die Klasse auf Grundfunktionalität (+ - * abzuspecken und alles andere, z.B. den Gauss-Algorithmus auszulagern. Andererseits finde ich es auch schön Operationen wie Inverse() oder Det() drinzulassen, und die basieren wiederum auf den Gauss-Algorithmus. Irgendwelche Vorschläge ?

Grüße, Lutz

Wir haben in unseren Projekten auch solche Gottklassen. Die sind so an die 10.000 Zeilen lang. Da ist niemand von uns stolz drauf, das kannst du wissen!

Was ist mit den Operatoren? Du solltest die Zuweisungsoperatoren ( *= , += etc.) in der Klasse deklarieren und die unabhängigen ( * , + , == , != , etc.) ausserhalb.

Aber grundsätzlich habe ich nicht das Gefühl, deine Klasse ist zu mächtig. Sie ist halt eine umfangreichere Matrixklasse, hat aber im Grunde genommen hauptsächlich eine Aufgabe. Ich glaube nicht, dass du viel gewinnen würdest, wenn du das noch gross auftrennst. Ich würde wie gesagt ein paar Funktionen (darunter auch Operatoren) als freie Funktionen implementieren, aber sonst eigentlich nicht viel mehr.

Es ist damit eher gemeint, das eine Klasse viele Funktionen übernimmt. Z.B. wenn deine Matrix-Klasse noch String- und Filestream-Funktionen hätte, würde sie Gott "spielen".

Was soll es denn bringen, ehemalige Memberfunktionen als freie Funktionen zu implementieren? Klar, die Klasse wird kleiner. Aber wenn ich vernünftig mit ihr umgehen wollte, müsste ich trotzdem diese ganzen freien Funktionen kennen. Die wären dann aber weiter von der Klasse entfernt.

Ich finde die Klasse wie sie ist in Ordnung.

Stefan.

Was soll es denn bringen, ehemalige Memberfunktionen als freie Funktionen zu implementieren?

Erhöht die Kapselung und lässt mehr Spielraum für Erweiterungen.

DStefan schrieb:

Was soll es denn bringen, ehemalige Memberfunktionen als freie Funktionen zu implementieren?

Erhöht die Kapselung und lässt mehr Spielraum für Erweiterungen.

Hat mir Kapselung nicht das Geringste zu tun und mit Spielraum für Erweiterungen auch nicht.

BTW: Ich find's immer klasse, wenn jemand seine Meinung so herrlich begründet, wie du....

Stefan.

BTW: Ich find's immer klasse, wenn jemand seine Meinung so herrlich begründet, wie du...

Ja, da hast du Recht, bin gerade bissl zeitknapp und einen Link kann ich dir auch nicht geben, da ich nicht an meinem Rechner sitze.

Meyers oder Herb hatte mal was dazu geschrieben, ich versuchst mal kurz.

class A
{
    private:
            int b;
    public:
            void setB(int x)  { b = x; }
            void getB() const { return b; }
            void transformB() { b = b*(-3); }
}

Ähnlich der MatrixKlasse. Nun wieso erhöhe ich die Kapselung, wenn ich transformB aus der Klasse hole ?
Was macht transformB eigentlich ? Es greift auf meine private Variable zu. Somit ist da nichts geschützt bzw sicher gekapselt, aber auch nicht schlimm.

Würde es die Kapselung erhöhen, wenn ich transformB rausholen würde?

class A
{
    private:
            int b;
    public:
            void setB(int x)  { b = x; }
            void getB() const { return b; }
}

void transformB(A& a) { a.setB( a.getB()*(-3) ); }

Was ist hier passiert ? Eine Funktionen weniger, die auf b direkt zugreifen kann, dh b ist noch besser gekapselt, da weniger Funktionen auf sie Zugriff haben.

Soviel zur Kapselung.

Kommen wir zur Erweiterbarkeit:
Was ist wenn nun ein B kommt, im Matrix-Fall könnte es ein Vektor sein, der von Matrix ableitet:

class B : public A

Und siehe da, ich kann transform auch mit einem B-Objekt aufrufen, wäre es noch in der Klasse A dann würde dass nicht gehen. Somit kann ich mit freien Funktionen einfacher meine Software erweitern ( *ganz so auch nun wieder nicht* ).

Ich hoffe so reicht dir meine Meinung

Edit: Da schreibt man ne Zeit lang nicht mehr so oft und überall schleichen sich Fehler ein ...

Für gewöhnlich brauche ich Memberfunktionen, um auf die privaten Elemente zugreifen zu können.

Ein bsp. aus Scott Meyers Buch:

class Browser
{
public:
    void clear();  // Seite aus Speicher löschen
    void load();   // Seite laden

    void reload()
    {
         clear();
         load();
    }
};

DIe reload-Funktion ist eine reine Komfortfunktion für den Anwender! Man sieht an der Implementierung, das sie nicht auf private oder protected Elemente zugreifen muß.

Das zeigt mir, das es keinen Grund gibt, diese reload-Funktion als Member Element zu haben.

class Browser
{
public:
    void clear();  // Seite aus Speicher löschen
    void load();   // Seite laden
};

void reload(Browser &b)
{
     b.clear();
     b.load();
}

Jetzt hat man noch die Möglichkeit, reload(Browser&) in eine andere Header-Datei auszulagern. Und somit wäre es sogar möglich, das jemand eine andere reload-Funktion bereit stellt, ohne die reload-Funktion überschreiben zu müssen. Denn die neue reload-Funktion könnte nämlich sogar im selben Namespace liegen.

Wenn ich die Algorithmen wie z.B. die Pivotsuche, Gauss, LR-Zerlegung auslagere, so dass nur noch grundlegende Rechenoperationen für Matrizen in der Klasse übrig bleiben, wäre das ein bißchen klarer getrennt.

Die Gauss- und Pivotsuche- Funktionen sind ja nicht mehr "nur" Matrizenrechnung sondern schon eine Anwendung der Matrizenrechnung für eine bestimmte Aufgabe (Gleichungssysteme lösen).

Noch ist die Klasse ja relativ klein, aber wenn ich weitere Funktionen einfach immer nur in die Klasse packen würde, kann es schnell unübersichtlich werden.

Naja, mit Kapselung hat das tatsächlich nichts zutun.

Das sehe ich nicht so. Wenn die Funktion, die lediglich Funktionen braucht, die öffentlich verfügbar sind, dann heisst das ja nicht, dass man zwangsweise auch nur diese benutzt. Sprich für mich als Programmierer dieser Funktion verschafft das auslagern auch ein gewisses Mass an Sicherheit, dass ich die Invariante nicht störe. Sprich es ist mir gar nicht möglich, wenn die Funktion ausgelagert ist. (Sofern die öffentlichen Funktionen das nicht tun).

Wenn ich z.B eine Fenster Klasse habe, die triviale getter, welche die X/Y Koordinaten zurückgeben, haben und dann in einer Funktion aus irgendeinem Grund halt anstatt die getX -Funktion zu benutzen einfach direkt auf den Wert zugreife, dann hast du sofort ein Problem, wenn du jetzt die getter auf z.B relative Koordinaten umrechen musst (was dann im getter passiert). Eine Funktion, die von aussen darauf zugreift, benutzt brav die getter und alles funktioniert wunderprächtig. Aber in der Funktion, die halt dann doch die Member benutzt läuft alles schief. Und das ist imo ein unnötiges Risiko.

- Gauss(); // Gauss-Algorithmus (Matrix auf Dreiecksform bringen)
- Decomposite(L,U); // LR-Zerlegung durchführen (A=L*U)
- ColumnPivotSearch(); // Spaltenpivotsuche
- TotalPivotSearch(); // Vollständige Pivotsuche

Das sind Algorithmen und brauchen nicht als Methoden der Klasse implementiert sein.

Naja, mit Kapselung hat das tatsächlich nichts zutun.

Das sehe ich nicht so. Wenn die Funktion, die lediglich Funktionen braucht, die öffentlich verfügbar sind, dann heisst das ja nicht, dass man zwangsweise auch nur diese benutzt. Sprich für mich als Programmierer dieser Funktion verschafft das auslagern auch ein gewisses Mass an Sicherheit, dass ich die Invariante nicht störe. Sprich es ist mir gar nicht möglich, wenn die Funktion ausgelagert ist. (Sofern die öffentlichen Funktionen das nicht tun).

Wenn ich z.B eine Fenster Klasse habe, die triviale getter, welche die X/Y Koordinaten zurückgeben, haben und dann in einer Funktion aus irgendeinem Grund halt anstatt die getX -Funktion zu benutzen einfach direkt auf den Wert zugreife, dann hast du sofort ein Problem, wenn du jetzt die getter auf z.B relative Koordinaten umrechen musst (was dann im getter passiert). Eine Funktion, die von aussen darauf zugreift, benutzt brav die getter und alles funktioniert wunderprächtig. Aber in der Funktion, die halt dann doch die Member benutzt läuft alles schief. Und das ist imo ein unnötiges Risiko.

Und wer garantiert dir, das die ausgelagerte Funktion noch richtig funktioniert, wenn sich plötzlich die Schnittstelle ändert und relative statt absolute koordinaten zurück gibt?

Dieses ganze Auslagern und überall Wiederverwenden solcher Funktionen führt meiner Meinung nach nur zu "Gottfunktionen". Wenn die Funktionen nicht so trivial wie reload sind und irgendwas geändert werden muss, dann kann es schnell passieren, dass die Funktion für ein paar Klassen nicht mehr das tut was sie soll. Das führt einfach nur zu unzähligen Abhängigkeiten im Code.

@tralala! Wenn sich das Verhalten der Schnittstelle ändert, ist das mit oder ohne freie Funktion ein Problem. Eine Schnittstelle soll genau sagen, was sie tut. getX() und getY() ist natürlich generell undeutlich. Man kann deshalb das Verhalten dieser Funktionen in der API-Doku beschreiben (natürlich darf man die Doku nicht nachträglich ändern...).

Am besten wäre aber natürlich ein eindeutiger Funktionsname, wie getRelativX() und getRelativY() ! Und wenn die Implementierung auf Einmal absolute Werte liefert, dann ist das ein Fehler. Aber was hat da die freie Funktion damit zu schaffen? Die ist total unschuldig. Denn nicht nur die frei Funktion wäre von diesem Fehler betroffen, sondern JEDER der die getter-Funktionen benutzt.

Am besten wäre aber natürlich ein eindeutiger Funktionsname, wie getRelativX() und getRelativY() !

Wobei natürlich auch das nicht eindeutig sein muss.

Ich denke, man kann die Funktionsnamen soweit so bennen, sofern es im logischen Kontext Sinn macht, oder wenn es unterschiedliche Möglichkeiten gibt, wie eben das Abfragen der absoluten oder relativen Koordinaten. Den Rest muss halt in der Referenz stehen. Sonst müsste man ja so etwas schreiben:

void getx_relative_and_clamp_to_0_1024 (){...}

@tralala! Wenn sich das Verhalten der Schnittstelle ändert, ist das mit oder ohne freie Funktion ein Problem. Eine Schnittstelle soll genau sagen, was sie tut. getX() und getY() ist natürlich generell undeutlich. Man kann deshalb das Verhalten dieser Funktionen in der API-Doku beschreiben (natürlich darf man die Doku nicht nachträglich ändern...).

Am besten wäre aber natürlich ein eindeutiger Funktionsname, wie getRelativX() und getRelativY() ! Und wenn die Implementierung auf Einmal absolute Werte liefert, dann ist das ein Fehler. Aber was hat da die freie Funktion damit zu schaffen? Die ist total unschuldig. Denn nicht nur die frei Funktion wäre von diesem Fehler betroffen, sondern JEDER der die getter-Funktionen benutzt.

Ja, seh ich auch so, aber ich versteh nicht, was es dann bringt eine freie Funktion zu machen, statt sie in der Klasse zu lassen. Ich versteh einfach nicht was an drakons Beispiel jetzt besser gekapselt und sicherer sein soll bzw. wieso man die Funktion nicht in der Klasse lassen kann, man kann ja trotzdem die getter verwenden. Ich finde halt einfach das die Gefahr, dass man sich ungewollte abhängigkeiten schafft viel größer ist, vorallem, wenn man die freien Funktionen so schreibt, dass sie auch von anderen Klassen verwendet werden können.

Auf den ersten Blick sehe ich SwapCols und SwapRows.

Das ist sinnfrei. Gerade diese beiden Methoden profitieren enorm vom Wissen der Speicherung der Daten in einer Matrix. Außerhalb der Klasse sind die Elemente nur noch über die Indizes ansprechbar, während innerhalb der Klasse man ggf. Zeiger auf Spalten oder Reihen vertauschen kann.

Ja, seh ich auch so, aber ich versteh nicht, was es dann bringt eine freie Funktion zu machen, statt sie in der Klasse zu lassen.

Lassen wir den Guru etwas dazu sagen:

http://www.gotw.ca/gotw/084.htm

tralala schrieb:

Ich finde halt einfach das die Gefahr, dass man sich ungewollte abhängigkeiten schafft viel größer ist, vorallem, wenn man die freien Funktionen so schreibt, dass sie auch von anderen Klassen verwendet werden können.

Und was sagt der Guru dazu?

tralala schrieb:

Ich finde halt einfach das die Gefahr, dass man sich ungewollte abhängigkeiten schafft viel größer ist, vorallem, wenn man die freien Funktionen so schreibt, dass sie auch von anderen Klassen verwendet werden können.

Toller Guru Aber du warst da glaub ich nicht gemeint...

Ich weiß nicht welche "ungewollten Abhängigkeiten" du meinst... Sei mal deutlicher!
Es geht hier auch um den generischen Ansatz.

template < typename ContainerT >
void clear( ContainerT &cnt )
{
    cnt.erase( cnt.begin(), cnt.end() );
}

Sollte für vector/list/... aber eben auch für basic_string funktionieren.
Stattdessen gibt es das clear() in den Klassen vector/... und basic_string.

Und wenn deine allgemeine freie Funktion mal ausnahmsweise für einen bestimmten Typen anders implementiert wird (weil die Schnittstelle anders ist, blame you), dann gibt es eine Spezialisierung, die man auch gleich über den Header der nötigenden Klasse bekommt.

Ich seh immer noch keine Abhängigkeiten...