Konventionen für den Aufbau einer Klasse?

Hallo,
ich hab die Suchfunktion benutzt, aber nichts passendes gefunden. Hier also meine Frage: Was besagen die allgemeinen Regeln zum Aufbau einer Klasse? In welcher Reihenfolge werden die Klassenelemente (heißt das so?) gesetzt. Bislang hab ich öfter diese Reihenfolge gesehen:

#region Constructors

      #endregion

      #region Member Variables

      #endregion

      #region Properties

      #endregion

      #region Methods

      #endregion

Ist das so richtig? Sollte die Region für Membervariablen nochmal in private, public usw unterteilt werden? An welche Stelle werden Structs und Event handler gesetzt (hab ich was vergessen?)?

Hallo Cyron,

ich deklariere meist in der Reihenfolge: Variablen, Properties, Konstruktoren, Methoden. Dann sind Variablen und Properties sowie Konstruktoren und Methoden - zwischen denen ich jeweils einen engeren Zusammenhang sehen - näher beieinander. Events sind Zwitter zwischen Variablen und Properties, passen also gut dazwischen. Structs und andere innere Typen (z.B. Enums) kommen - quasi also Voraussetzungen - noch vor die Variablen oder sogar vor und außerhalb der Klasse. Innerhalb der Methoden deklariere ich private Hilfsmethoden tendentiell weiter hinten.

Regions benutze ich dabei nicht, weil mir das nichts bringt (benutze kein VS). Deshalb halte ich das Schema auch nicht strikt ein. Wenn ich z.B. eine Member-Variable nur in einer Methode brauche, kann es gut sein, dass ich sie unmittelbar vor der Methode deklariere.

Ich bin der Meinung, dass es hier soviele widerstreitende Gründe für die eine oder andere Einordnung gibt und soviele Ausnahmetatbestände gibt, dass es schwer ist, hier ein striktes Vorgehen einzuhalten.

herbivore

Hallo Cyron,

herbivore hat recht, es ist schwer ein allgemeingültiges Schema zu manifestieren.

Ich persönlich schreibe meine Properties immer unter die Methoden. Bei vielen Properties bin ich so "schneller" bei meinen Methoden 😉

Viele Grüße
🙂 Torsten

Hallo Cyron,

herbivore hat ja schon gut erklärt, warum eine allgemeingültige Regel schwer und wahrscheinlich gar nicht zu finden ist.
Prinzipiell schließe ich mich aber Deinem Beispiel an. So mache ich das auch meistens. Events und Enums deklariere ich oftmals vor den Properties bzw. bei Enums auch teilweise außerhalb der Klasse, so wie herbivore das schon beschrieben hat.

Ob man dann noch weitere Unterteilungen macht, hängt sehr stark vom aktuellen Fall ab. Ich finde, man sollte es so machen, wie man es am besten findet 🙂.

Gruß,
Fabian

Wozu überhaupt darüber Gedanken machen?

Hallo Traumzauberbaum,

sich über sowas Gedanken zu machen, unterscheidet den Profi vom Stümper. 😛

herbivore

Hey cool,

dann bin ich ja ein Profi! 😁

🙂 Torsten

Hallo Traumzauberbaum,

Original von Traumzauberbaum
Wozu überhaupt darüber Gedanken machen?

herbivore hat es auf den Punkt gebracht 🙂. Der Erfolg eines Softwareprojekts hängt auch zum großen Teil von der Planung ab und zur Planung gehören auch solche Dinge. Vor allem, wenn man im Team mit mehreren Entwickler arbeitet, ist es sehr wichtig, einen einheitlichen Code-Stil zu haben.

Ansonsten geht schon sehr viel Zeit dafür drauf, nur den Code des anderen lesen zu können. Das muss ja nicht sein.

Gruß,
Fabian

Vielen Dank für eure Antworten. =)
Ja, private Variablen machen dort wo sie gebraucht werden, mehr Sinn. Das sehe ich auch so.

In Zeiten von Intellisense finde ich die Reihenfolge, in der eine Klasse aufgebaut ist, für vernachlässigbar. Wichtig ist, dass ähnliche / gleichartige Elemente (Öffentliche Methoden / Private Methoden oder wie auch immer ;o)) gruppiert werden. Noch wichtiger aber, wie Fabian oben bereits geschrieben hat:

Original von Fabian
Vor allem, wenn man im Team mit mehreren Entwickler arbeitet, ist es sehr wichtig, einen einheitlichen Code-Stil zu haben.

Ein gemeinsamer Styleguide vereinfacht das Lesen von Code eines anderen ungemein.

-yellow

Hallo Yellow,

Original von Yellow
In Zeiten von Intellisense finde ich die Reihenfolge, in der eine Klasse aufgebaut ist, für vernachlässigbar. Wichtig ist, dass ähnliche / gleichartige Elemente (Öffentliche Methoden / Private Methoden oder wie auch immer ;o)) gruppiert werden. Noch wichtiger aber, wie Fabian oben bereits geschrieben hat:

Ich denke nicht, dass unterstützende Techniken die Strukturierung vernachlässigbar machen, weil die nämlich nicht jedem bereit stehen. Druck Deinen Code aus oder schick ihn einem Projektleiter, der auf Mac arbeitet und schon sind all die Helferlein dahin 8).

Alex

Original von sprinter252
Ich denke nicht, dass unterstützende Techniken die Strukturierung vernachlässigbar machen, weil die nämlich nicht jedem bereit stehen. Druck Deinen Code aus oder schick ihn einem Projektleiter, der auf Mac arbeitet und schon sind all die Helferlein dahin 8).

Hallo Alex,

dann weiss der Projektleiter, wo er was zu finden hat, weil ich mich an den Styleguide gehalten habe ;o). Was ich damit eigentlich sagen wollte: Ich halte nicht die Strukturierung vernachlässigbar, nur die Reihenfolge! Ob jetzt z. B.: die Deklarationen zuerst kommen und dann die Konstruktoren/Destruktoren folgen, oder andersherum, ist egal, die Hauptsache ist bei jeder Klasse geschieht es immer auf die selbe Weise an der selben Stelle.

...und wenn ich's ausdrucke, einem Projektleiter schicke und der es dann tatsächlich von Papier liest... dann frage ich mich viel eher, ob es nicht kostengünstiger wäre, den Projektleiter einzusparen und das Budget andersweitig sinnvoller einzusetzen. ;o))

-yellow

Hallo Yellow,

ok, sehe ich ein.

Alex