Code Aufräumen und Methoden auf verschiedene Dateien aufteilen

Moinmoin,

langsam komme ich immer besser mit C# klar und meine Programme werden auch immer größer. Nun wollte ich Funktionen einer Klasse noch separat in eine extra Datei speichern um eine bessere Übersicht zu haben.
Das heiß ich habe eine Klasse "myClass" in der Datei myClass.cs, da die Klasse aber relativ viele Methoden/Funktionen Variablen etc. enthält möchte ich diese in mehreren Dateien Speichern. Geht das?

ich stelle mir etwa so etwas vor:

myClass.cs:

namespace myApp
{
    public class myClass
    {
        public int i;
        //...
        Funktionen aus Datei myClassFunktionen1.sc
        Funktionen aus Datei myClassFunktionen2.sc
        ...

    }
}

Danke und vielen Grüße Thommy

Hallo Thommy,

naja, das sind Grundlagen der objektorientierten Programmierung.

Du machst dir eine Klasse, instanziierst sie mit

MyWorkerClass workerClass = new MyWOrkerClass()

und kannst dann auf die Methoden zugreifen. Oder benutzt Dependency Injection. Aber fang lieber erstmal mit "new()" an. Schau auch gleich nach Interfaces 😃

Siehe auch [Artikel] Drei-Schichten-Architektur

Gruss

Coffeebean

Hallo,
eine Klasse auf mehrere Dateien kannst du mit partial aufteilen: Partielle Klassen und Methoden (C#-Programmierhandbuch)

Hallo,
eine Klasse auf mehrere Dateien kannst du mit partial aufteilen:
>

Das aufteilen in partial Klassen, sollte man meines Erachtens vermeiden und lieber "richtig" Klassen verwenden. Wenn es keinen guten Grund dafür gibt z.B. WindowsForms.

Hi zusammen,

danke für die Infos und ja es sind WindowsForms. die Klasse ist mir einfach zu groß und unübersichtlich, ich nutze auch einen TabController mit 5 Tabs und da lässt es sich doch gut und logisch aufteilen 😉

Thx and cya Thommy

partial für größere Klassen ist absolut in Ordnung und auch üblich, sofern die Klasse nicht sinnvoll kleiner gemacht werden kann (zB auf Basis von Single Responsibility).

Wenn eine Klasse z.B. mehrere Interfaces implementiert, kann es schon mal sein, dass ich Teile der Klasse in Dateien nach dem Aufbau Klasse.Interface.cs extrahiere.

Edit:
Ein weiterer Vorteil des Ansatzes: Wenn meine Klasse das Interface nicht mehr implementieren muss, muss ich nur die Datei löschen und der Drops ist gelutscht.

Bei TabControls solltest du besser aus den verschiedenen Tabs UserControls erstellen - am besten sogar dann aus dem TabControl selbst auch. So hast du dann automatisch den Code jeweils in eigenen Klassen (und kannst dann dafür ein passendes Interface bereitstellen).

partial für größere Klassen ist absolut in Ordnung und auch üblich, sofern die Klasse nicht sinnvoll kleiner gemacht werden kann (zB auf Basis von Single Responsibility).

Wenn man nach SRP Arbeitet (was Thommy jetzt nicht unbedingt kennt, ist jetzt nicht böse gemeint), ist es sehr selten das Klassen so groß werden, das man Partielle Klassen braucht.

Ich denke mal wenn Leute Programmieren lernen, ist es besser ihnen erst mal zu anderen Klassen zu raten, als zu Partiellen Klassen. Und wenn man es doch macht sollte man das SRP erwähnen.

Nö, seh ich anders; vor allem gegenüber Anfängern.
partial ist absolut legitim 👍

Das .NET Team separiert so zB. Plattform-Eigenheiten / Features - sogar sehr fein granular.
partial macht's auch in größeren Teams einfacher gemeinsam am Code zu arbeiten (Geringerer Review-Aufwand, Weniger Merge-Conflicts etc..).

Nö, seh ich anders; vor allem gegenüber Anfängern.
partial ist absolut legitim 😮

Ist natürlich ein bisschen Geschmackssache, ich persönlich finde es besser das SRP umzusetzen, bevor ich partial greife. Dazu kommt, das andere Sprachen (z.B.) das Feature nicht haben.
Ich persönlich halte es für sinnvoller einen Anfänger, möglichst Sprach unabhängig die Grundlagen der OOP zu vermitteln.

Das
> so zB. Plattform-Eigenheiten / Features - sogar sehr fein granular.

Da werden z.B. Plattform-Eigenheiten ausgelagert um z.B. Unix und Windows Abhängigkeiten zu trennen. (Ich muss gestehen ich hätte an den Punkt eher Vererbung erwartet.)
Ich sage ja nicht das es keine Anwendungsfälle für partial gibt, sondern das SRP zu bevorzugen ist.

(Geringerer Review-Aufwand, Weniger Merge-Conflicts etc..).

1. Punkt ist Geschmackssache, ich Scroll lieber alles was "zusammen" gehört in einer Datei nach unten als die Klasse zu wechseln.
2. Punkt die Quellcode Verwaltung macht, beim Mergen schon recht gute Arbeit. Der Unterschied ist dann einfach, das ich Anstelle von 3 Konflikten in einer Datei, 3 Konflikte in 3 Dateien habe.