Hallo,

jetzt hab ich mal eine völlig untypische Frage. Da meine KLassen zunehmend größer und unübersichtlicher werden.
Wollte ich euch mal fragen, wie Ihr so eure Klasse aufbaut und ob ihr es nicht mal an ner Bspklasse demonstrieren könnte.
Sortiert ihr nach Private, Public, etc oder nach Funktionen, Variablen, Etc...

Also mal davon ausgegangen ihr habt ne Klasse die

- private Variablen
- protected Variablen
- eine statische KlassenVariable
- private, public, protected Funktionen
- mehrere Konstruktoren, einen Destruktor, eine statische Klassen funktion
- evtl noch n paar Konstanen enthält

Wie würdet ihr die Klasse nun aufbauen, damit man den Überblich nicht verliert.
Baut ihr "regions" ein?

Danke,
winx

Ich bin gerade dabei zwei Klassen zu programmieren.
Zur Übersichtlichkeit benutze ich selbstverständlich "region". Selbst kleine Klassen haben schnell mal ein paar hundert Zeilen Source-Code. Wenn man dann mit Regions ganze Code-Blöcke ausblenden kann, erleichtert das die Übersicht ganz enorm.
Außerdem hat es sich bewährt, die Private-Deklarationen an oberste Stelle zu setzen. Dabei unterscheide ich noch zwischen Variablen und Methoden:

Das ist es im Groben.

Auch wenn es möglich ist, Variablen mitten im Source zu deklarieren, vermeide ich das grundsätzlich. Ich möchte immer auf einen Blick sehen können, welche Variablen benutzt werden (können). Das geht nur, wenn diese an einem festen Platz stehen.

jasocul hat folgendes geschrieben:

Selbst kleine Klassen haben schnell mal ein paar hundert Zeilen Source-Code.

ich habe die Daumenregel, dass sämtliche Code files, die mehr als 3 Bildschirme hoch sind, 1,5 Bildschirme zu hoch sind.
Im Gegensatz zu Delphi gibt es reduzierte Sichtbarkeiten und dank multi pass kann man seine Klassen über soviele Dateien verteilen wie man es für notwendig hält.
Bei solch ausufernden Klassen würde ich schon längst begonnen haben Funktionalität in weitere Klassen umzuverteilen.(Kleinere, generic Päckchen erhöhen auch die Wiederverwendbarkeit )
Außerdem gehe ich strikt nach max. ein Typ pro Datei vor. Nichts ist nerviger als eine Datei zu öffnen und nicht auf Anhieb erkennen zu können was dort alles passiert...

danke für eure Hilfe.

Aber wie verteile ich denn ein Klassen auf mehrere Dateien? Das ist nur mit dem 2.0er Framework möglich, oder???

Da ich, arbeitsbedingt, von der Delphi und Java Ecke komme, entspricht euer Klassenaufbau schon sehr der von Delphi.

Noch ne Frage, wo packt ihr statische Variablen rein?
Und was sind Modifizierer, getter und setter, ne das sind die Properties, oder?

winx hat folgendes geschrieben:

Aber wie verteile ich denn ein Klassen auf mehrere Dateien? Das ist nur mit dem 2.0er Framework möglich, oder???

Ich weiß, dass es geht. Da ich aber auch noch Anfang mit C# stehe, hatte ich da noch keinen Bedarf. Mehr als 600 Zeilen hatte ich da noch nicht, soweit ich weiß.

winx hat folgendes geschrieben:

Da ich, arbeitsbedingt, von der Delphi und Java Ecke komme, entspricht euer Klassenaufbau schon sehr der von Delphi.

Der ist doch auch gut. Sehr strukturiert und übersichtlich. Warum sollte man bewährtes nicht übernehmen?

winx hat folgendes geschrieben:

Noch ne Frage, wo packt ihr statische Variablen rein? Und was sind Modifizierer, getter und setter, ne das sind die Properties, oder?

Statische Variablen? Habe ich bisher nicht verwendet. Da das im Prinzip globale Variablen sind, würde ich die auch nicht einsetzen. Das würde auch dem Konzept von OOP wiedersprechen. Oder bin ich da falsch informiert?
Getter und Setter entsprechen den aus Delphi bekannten Properties.
Modifizierer (in der Hilfe von SharpDevelop gefunden):
- public
- private
- internal
- protected
- abstract
- const
- event
- extern
- override
- readonly
- sealed
- static
- unsafe
- virtual
- volatile

Ich redete von 1 Typ pro File Wird der Typ mehr als 2-3 Bildschirme groß ist er mir in 90% aller Fälle mindestens einen zu hoch.
Partial classes machen meist da Sinn, wo ein Teil der Klasse etwas tut, was im Rest relativ unerheblich ist. Explizites Implementieren von Interfaces ist da ein Beispiel. Das ist in C# so verflucht hässlich, das will ich nicht in Code stehen haben den ich öfters lesen muss.
Außerdem ist es sinnvoll für Klassen, die autogeneriert werden. Wenn du Klassen aus einem XSD anlegen lässt, kannst du weitere Properties/Methoden/Vorgänger in einer weiteren Datei anlegen ohne dass sie verloren gehen, wenn man das XSD aktualisiert.

jasocul hat folgendes geschrieben:

winx hat folgendes geschrieben: Noch ne Frage, wo packt ihr statische Variablen rein? Und was sind Modifizierer, getter und setter, ne das sind die Properties, oder? Statische Variablen? Habe ich bisher nicht verwendet. Da das im Prinzip globale Variablen sind, würde ich die auch nicht einsetzen. Das würde auch dem Konzept von OOP wiedersprechen. Oder bin ich da falsch informiert?

Eine Klasse zu versiegeln und dort eine Statische Variable & Property zu definieren die auf die auf eine Instanz von sich selber zeigt( Kurz: Singletonklasse ), ist etwas was soweit ich weiss nicht gegen OOP verstößt!

static ist in C++ was anderes als in C#. So, wie es in C# verwendet wird, passt es natürlich schon ins OOP-Konzept. Da du speziell static-Variablen angesprochen hattest, bin ich vermutlich von falschen Voraussetzungen ausgegangen.
Außerdem hasse ich versiegelte Klassen.