Auslagerung von Code in verschiedene Klassen ist zwar grundsätzlich eine super Idee, aber hier hast du Ziel weit verfehlt; bist quasi genau drübergeflogen.

Wenn sich Klassen gegenseitig referenzieren ist das auch immer eher suboptimal. Zirkelreferenzen machen den Code unübersichtlich und unlesbar (wie du ja gerade selber merkst).

Anstatt zwei Klassen, baue das Ganze doch mal in eine Klasse ​FileHandling um. Darin kümmerst du dich um alles, was File(handling) angeht; löschen, schreiben, kreieren, etc.
Dann hast du alles in einer Instanz und kannst lesen, schreiben, löschen - im Zweifel dann sogar direkt nacheinander

Allein die Klassennamen sagen, dass was falsch läuft. WriteFiles, DeleteFiles. Das sind Bezeichnungen von Aufgaben, also Methodennamen. Keine Klassenbezeichungen. Als Klassenbezeichungen verwendet man normalerweise Substantive. Form (= Formular), Button (Knopf/Taste(r)), List (Liste), MyFancyWebBrowser.

Prinzipiell geht das. Aber als Merkregel für Dich: Wenn Klassen immer in Paaren oder Gruppen aufgerufen werden müssen und nie wirklich unabhängig voneinander zugewiesene Aufgaben erledigen können, sollten sie wohl zu einer Klassen zusammengefasst werden. Wenn also immer Methoden von xyzOne aufgerufen werden und dann immer erst Methoden von xyzTwo, dann gehören wohl die Methoden von xyzOne und xyzTwo in eine gemeinsame Klasse.
Beispiel: ein 3D-Objekt soll gezeichnet werden.

• Du hast eine Klasse, die das Zeichnen vorbereitet
  
• eine, die die Daten für das Zeichnen zusammensammelt
  
• eine, die das Objekt mit den gesammelten Daten das Zeichnen durchführt
  
• eine, die das ganze wieder aufräumt
  

Wenn diese Klassen immer zusammen verwendet werden, weil es keinen Sinn ergäbe, sie unabhängig voneinander zu nutzen, gehört der Code nicht in vier Klassen sondern in eine.

​
Auf dem Form feuert eine Methode, mit Parameter (1) eine Methode in Class xyzOne an. Diese erledigt ihre Arbeit und feuert ein Event zurück ans Form.Das feuert dann wiederum eine Methode in der Class xyzTwo an, welches seine Arbeit erledigt und feuert dann ebenfalls per Event zurück ans Form.Und dann wieder zurück mit mit Parameter (2) an die Class xyzOne.Wäre das eine Möglichkeit im Sinne von CleanCode, OOP, Klassen und Methoden klein halten, usw??

Nein.

Im einfachsten Fall werden die beiden Methoden direkt hintereinander aufgerufen.
So versteht das dann auch jeder:



Man kann die Dinge nun mutwillig beliebig verkomplizieren. Da setzt die Kreativität wohl keine Grenzen.

Mit deinem Vorschlag wäre die Ausführung nur noch durch Mithilfe des Forms sichergestellt, was aber überhaupt nicht notwendig ist.
Am Ende kommt bei solchen Aktionen immer nur rum, dass nur der Autor den Code versteht und nach Ablauf von einigen Monaten auch dieser nicht mehr durchsteigt.
Ich berichte natürlich aus eigener leidvoller Erfahrung

Amelie schrieb:

Wäre das eine Möglichkeit im Sinne von CleanCode, OOP, Klassen und Methoden klein halten, usw??

Der Teufel steckt nunmal im Detail. In diesem Fall schießt du weit über das Ziel hinaus. Das ist zwar dann maximal OOP, aber hat wenig mit Clean Coding zu tun.

Clean Coding besagt nicht nur, dass der Code vernünftig lesbar sein soll, sondern auch einfach zu verstehen. Wenn ich eine Klasse sehe, die effektiv nur eine Methode hat und direkt abhängig von einer anderen Klasse(nmethode) ist, dann verwirrt mich das nur. Da bleibt mir nur die Frage "was hat sich der Entwickler dabei nur gedacht?"

VaporiZed schrieb:

Prinzipiell geht das. Aber als Merkregel für Dich: Wenn Klassen immer in Paaren oder Gruppen aufgerufen werden müssen und nie wirklich unabhängig voneinander zugewiesene Aufgaben erledigen können, sollten sie wohl zu einer Klassen zusammengefasst werden.

Genau das. Hätte ich besser nicht sagen können!

VaporiZed schrieb:

Wenn diese Klassen immer zusammen verwendet werden, weil es keinen Sinn ergäbe, sie unabhängig voneinander zu nutzen, gehört der Code nicht in vier Klassen sondern in eine.

Ebenfalls goldrichtig. Dadurch sollte eine Klasse auch nicht riesig werden. Was du dazu noch machen kannst, was ich immer ganz charmant finde, ist partial class zu verwenden.
Sprich: du hast eine Klasse, kannst aber die verschiedenen Aufgaben logisch unterteilen, in verschiedene Dateien.
So macht es der Formdesigner schließlich auch. Alles was UI angeht und das Layout der einzelnen Elemente ist in FormX.Designer.xx und dein Codebehind ist in FormX.xx.

Genau so könntest du:
MyFoo.XXY.cs:


MyFoo.ZZR.cs:


machen. Dann hast du die Aufteilung die du wünscht, hast aber alles in einer einheitlichen Klasse, damit dein Code nicht plötzlich nach Carbonara riecht.

Amelie schrieb:

Ja und oft kommt mir dann das ganze OOP usw. so widersprüchlich vor.
Kleine, kurze Klassen und Methoden, und dann doch wieder vieles in eine Klasse / Methode packen, was diese dann wieder "aufbläht".

Wiedersprüchlich ist da nichts.
Ist anfangs schwer zu verstehen, das stimmt schon. Da mach dir keinen Kopf, das wirst du auch noch alles schaffen.

Aber auch wenn eine Klasse eine (große) Aufgabe übernimmt (z.B. FileHandling), machen die Methoden darin die kleinen Aufgaben. Die sollten nur so atomar wie möglich und sinnvoll geschrieben werden.

Es gibt aber auch Außnahmen. Ich schreibe z.B. viel für Linux in C++. Da gibt es manchmal Konstrukte, die lassen es schlicht nicht anders zu, als dass du Funktionen (C++ Methoden) hast, die unfassbar groß werden, weil man jeden Schrott doppelt und dreifach prüfen und durchiterieren muss, weil es die Runtime nicht anders vorsieht.
(Zumindest wenn man nicht unnötig weniger Bytes als Pointer durch die Gegend schieben will, aus Gründen)

bzgl. Partial Classes:
Ich nutze das auch in jedem Projekt. Meine größeren Klassen, die also mehr als eine Bildschirmseite ausfüllen, unterteile ich ich mehrere Dateien, um sie thematisch zu sortieren. Als Beispiel: Ich verwende derzeit* die Aufteilung API, Integration, Commands, Queries, Properties bei nicht-GUI-Klassen.

• API: Alle von außen (also anderen Klassen) zugänglichen Methoden
  
• Integration: Methoden (Subs und manchmal auch Functions), die nur andere Methoden aufrufen**
  
• Commands: Subs, die nur einfache Dinge ausführen (Variablenwerte setzen) oder Anweisungen an andere Klassen geben
  
• Queries: Functions, die Werte berechnen/ermitteln, ggf. mithilfe anderer Klassen
  
• Properties: naja, Properties der Klasse eben
  

Das ist meine Interpretation von IOSP.

* hält sich schon so seit ein paar Jahren, scheint für mich also ein passabler Weg zu sein
** enthält aber auch zu Methodenbeginn ab&zu Abbruchprüfungen (If … Then Return) und Variablenwertsetzungen (Dim Foo = GetValueOfFoo())

##########

Amelie schrieb:

wann welche Methoden in eine oder mehrere Klassen gehören

Wenn eine Methode in mehrere Klassen gehören könnte, wäre es vielleicht sinnvoll, dass diese Methode in eine eigene Klasse gehört, die von anderen genutzt wird.

Amelie schrieb:

Vermutlich denke ich oft zu "kompliziert" oder auch zu "simpel"

Leider kann ich als Einzelentwickler (ich wünschte ich könnte Pair Programming machen, aber ich hab niemanden) nur sagen: Das dauert wohl leider bei jedem von uns, da das Mittelmaß zu finden.

Amelie schrieb:

Kleine, kurze Klassen und Methoden, und dann doch wieder vieles in eine Klasse / Methode packen, was diese dann wieder "aufbläht".

dito

Amelie schrieb:

OMG diese Klasse ist viel zu groß!

Die Klasse ist dann zu groß, wenn sie mehr macht als eine klar umrissene Aufgabe zu erfüllen. Wenn eine Klasse 1000 Zeilen hat, aber ihre Arbeit macht, für die sie gedacht ist, ist das ok. Wenn Du eine Klasse hast, die 100 Zeilen hat, aber zig Aufgaben erledigt, weil die Aufgabe nicht sinnvoll definiert ist, dann ist das schlecht. Die Aufgabe spiegelt sich meist sehr gut im Namen der Klasse wieder. Wenn Du eine Klasse als etwas schwammiges wie AppManager benennst, dann ist die Aufgabe nicht klar umrissen. Wenn sie House oder FileSorter, oder SortableList heißt, dann ist das sehr konkret und die Größe ist egal, solange sich die Klasse um ihren Kram kümmert und nicht um die Angelegenheiten anderer Objekte.

Ja, so ähnlich handhabe ich das auch. Nicht unbedingt nach Klassengröße, sondern mehr wenn ich merke dass man die Aufgaben besser aufteilen könnte, aber dennoch sehr ähnlich.

Ist jedenfalls denke ich auch ein guter Hinweis für dich, @Amelie

Es scheint mir so, als würdest du gerade einen typischen Anfängerfehler machen und ohne Plan drauflos programmieren.

Bevor du jetzt anfängst und dich wieder in einer Zwickmühle befindest; nimm dir ein Blatt Papier (ja, das komische analoge Zeugs) und mal ganz grob auf, was du erreichen möchtest.

Dort werden dir schon Sachen auffallen, die du überarbeiten solltest.
Danach kannst du zumindest anfangen, deine Struktur niederzuprogrammieren.

Amelie schrieb:

weil mir während ich den Code versuche "gut" umzusetzen

Das ist ein altbekanntes Problem, was jeden von uns betrifft. Es wird mit der Erfahrung aber besser.

Amelie schrieb:

einfallen oder ich etwas neues lese

Auch das ist gerade während der Anfangsphase total normal. Naja. Wenn ich ehrlich bin, nach 16 Jahren ist das bei mir immer noch so... Ganz getreu dem Motto "ooh, shiny!".
Mein Rat wäre, probier dich ruhig aus, aber nicht auf Krampf. Versuche erst zu verstehen, was genau du da jetzt anders umsetzen möchtest.

Es ist immer so, dass die erste Iteration suboptimal ist. "Premature optimisation is the root of all evil".
Schau erstmal zu, dass das Ding funktioniert, wenn auch hässlich, und sobald du einen funktionierenden Prototypen hast, gehst du nochmal lang und änderst es dann ab.

Amelie schrieb:

Dann gugg ich mir meine geschriebenen Methoden an und ... schubs fliegen meine Neuronen kreuzundquer...

Ich weiß nicht wie das für dich ist. Mir geht das auch immer gehörig gegen den Strich, wenn etwas nicht meinen Vorstellungen entspricht. Aber ich habe gelernt, erstmal fertig zu machen, bevor ich refactoring betreibe. Auf die harte Tour.

Noch als allgemeiner kleiner Tipp über den ich leider noch heute oft stolpere: Keep it simple!

Wir neigen oft dazu Dinge zu verkomplizieren und denken "Oh das könnte ich aber demnächst dort noch gebrauchen".
Das trifft selten zu und wenn es doch so kommt, füge nur die entsprechende Funktionalität hinzu.

Kleines Beispiel: ServiceCollection Extension mit Dependency als Parameter?
Der dort gebauten Extension habe ich bis heute immer nur fest definierte DelegatingHandler übergeben, heißt die Arbeit hätte ich mir sparen können.

Amelie schrieb:

...Was mir nur so Kopfzerbrechen macht, und mir so unnütz viel vorkommt, ist diese Menge an Code...

Das finde ich noch mit am wichtigsten, dass man ein Gefühl bekommt für "...hmm - das ginge doch auch einfacher?..."

---

Ansonsten ärger ich mich aber über sowas:

Amelie schrieb:

...waren hier nur als Beispiel gedacht..

Bitte verschone uns mit solchen "Beispielen", wenn sie mit der Realität nichts zu tun haben.
Da macht man sich den Kopf, und antwortet leidlich qualifiziert, und dann heissts: "ellabäätsch - war nur ein Beispiel!"
Da will man garnet mehr antworten, weil man weiss nie: Beschäftige ich mich hier mit einem Problem, oder wieder nur mit einem irrealen Hirngespinst?

---

Ansonsten finde ich diesen Thread ziemlich allgemein gehalten. Jo, gute Ratschläge hast du nun bekommen, aber natürlich nix konkretes.
Weil das einzig konkrete - der Code aus post#1 - ist ja so ein "Beispiel".

---

Ich sammel nochma Ratschläge:

• mach es einfach
  
• vorher planen
  
  • Was soll das Programm tun?
    
  • Objekte erkennen
    
  • Aufgaben erkennen
  • den Objekten ihre Aufgaben zuweisen
    nicht irre machen lassen: Mal ergibt sich nur ein Objekt mit 10 Aufgaben, mal 10 Objekte mit je einer Aufgabe
    
  
  
• einen Prototypen erstmal lauffähig machen, dann überarbeiten (oder gar neu schreiben)
  
• richtig benamen
  
• sparsam und sorgfältig kommentieren: nur so wenig wie nötig, aber das nötige auch nicht vergessen!
• Verwende die Programmier-Elemente, die du brauchst - nicht alles was du kannst
  
• Methoden nicht über 30 Zeilen
• Klassen nicht über 300 Zeilen
• Wenns aber anders nicht sinnvoll ist, dann eben doch Methoden über 30 Zeilen und Klassen über 300 Zeilen
  
• Bauchgefühl beachten: bei gefühlt zuvielem Code, oder gefühlt wirrem Code innehalten, überlegen, nachfragen