Stilfrage: Neue Klasse wenn es in einer Klasse zu viele Methoden gibt?

[System.exit(0)]

Hallo,

ich programmiere gerade ein Programm zum Lösen von Sudokus und habe ein Problem, dass sich mit der Übersichtlichkeit beschäftigt.

Ich habe eine Klasse Sudoku. Diese Klasse enthält die Daten des Suodku und dient nur der Berechnung der Lösung, Eingabe und Ausgabe sind anderswo geregelt.
Dies zahlreichen Methoden dieser Klasse kann man in primäre und sekundäre Methoden einteilen (oder wie auch immer man das bezeichnen möchte).
Die primären Methoden führen grundlegende Sachen aus und greifen auf (teilweise sehr viele) sekundäre, also unterstützende Methoden zurück.

Insgesamt ist dadurch allerdings die Klasse recht lang. Das hilft nicht unbedingt beim Zurechtfinden.

Wäre es jetzt für die Übersichtlichkeit des Codes ein guter Stil, die sekundären Methoden in eine eigene (Hilfs-)Klassen zu schreiben, um das Ganze übersichtlicher zu gestalten oder würde diese Segmentierung die Lesbarkeit verschlechtern, den Aufwand bloß in die Höhe treiben udn evtl. sogar die Geschwindigkeit des Programmes deutlich senken?

mfg

System.exit(0)

 

[The_S]

Kann man pauschal nicht sagen. Geb mal konkrete Beispiele, was bei dir primär, und was sekundär ist.

Laut Code-Conventions sind Klassen mit bis zu 2000 Zeilen OK (was ich jetzt aber nicht unbedingt ausreizen wollen würde).

 

[System.exit(0)]

Von 2000 Zeilen bin ich dann doch noch ein Stück entfernt.

Primär wären die Methoden, die man zum Lösen von Sudokus anwendet:

Also Zeilen, Spalten, Quadrate usw. nach zu eliminierenden Lösungen absuchen.

Sekundär wären alle Methoden, die dann
- die Daten manipulieren
- Berechnungen zur Orientierung im Sudoku anstellen
- prüfen, ob bestimmte Ereignisse eintreten usw.


mfg

System.exit(0)

 

[ARadauer]

zeig uns mal deine Klasse, du könntest die datenhaltung und die berechnung noch trennen.
Wie viele Methoden hat sie den?

 

[ARadauer]

bzw zeig mal deine ganze Klasse

 

[The_S]

Für was brauchst du das Ganze Zeug? Bei meinem Sudoku-Solver gibts genau 6 Methoden (wovon eine ausgelagert werden könnte, da allgemein), die (inkl. package, imports und Kommentare) 139 Zeilen lang ist.

Generell sollte nur das in eine Klasse, was eine Klasse auch wirklich benötigt. Helper-Klassen sind auch durchaus erlaubt. Kannst dir ja so vorstellen: Ein Haus braucht natürlich Wände und Räume. In einem Haus findet man auch Möbel. Diese liegen aber nicht direkt im Haus, sondern im jeweiligen Raum.

Ansonsten zählt das, was ARadauer gesagt hat.

 

[maki]

Wichtiger als die Anzahl der Zeilen ist die frage welche Aufgaben die Objekte der Klasse selbst übernehmen (d.h. ohne delegation an andere Objekte) was uns zu "Separation of Concerns" bringt.
Religiöse SoC Fanatiker haben dafür einen Test: Beschreibe was deine Klasse selbst macht. Sobald du ein "und" verwendest, solltest du dafür eine eigene Klasse machen.

Refactoring ist der Weg um aus einer Klasse mehrere zu machen: Extract Class

 

[ARadauer]

Religiöse SoC Fanatiker haben dafür einen Test: Beschreibe was deine Klasse selbst macht. Sobald du ein "und" verwendest, solltest du dafür eine eigene Klasse machen.[/qutoe]
ja man kann es übertreiben, was oft zu einer unnötigen komplexitäte des ganzen systems führen kann...

 

[maki]

Der Begriff "religiöse Fanatiker" war nicht zufällig gewählt
Allerdings ist es doch einer der Grundgedanken der OO der da rausspricht.
Strikt OO geschriebene Klassen haben eben nicht soviele Methoden, dafür sind diese sehr klein und deligieren viel.

Man muss halt sehen, wie es in der Praxis für den konkreten Fall am besten umzusetzen ist.

 

[ARadauer]

Man muss halt sehen, wie es in der Praxis für den konkreten Fall am besten umzusetzen ist.

Das ist ein wichtiger Punkt, denn man auch im bereich der design patterns auf keine fall übersehen sollte...

Man muss immer einen guten Zwischenweg zwischen flexibler Software und totaler Zerstückelung des Systems finden...

 

[maki]

Designpattern sind imho überbewertet

Denn wenn dein Code ein gutes Design ausweisst, sind zwangsläufig Pattern drinnen, umgekehrt ist das aber nicht der Fall.
Erinnern wir uns alle mal an unsere Anfänge mit Designpatterns, das nächste Projekt hat schon im Entwurf von Patterns nur so gestrotzt, sinnvoll oder nicht war egal, Hauptsache sie waren drinn, denn Patterns sind ja hip

Ich finde man kommt erst zu einer guten Struktur nach dem man ein paar mal refactored hat, denn mit einer guten Struktur hat man zwangsläufig Patterns drinnen.

Die Möglichkeit wirklich sinnvoll zu refactoren ("changing the design without changing the functionality") hat man aber erst, wenn man weiss dass man nix kaputt macht, d.h. ohne (gute) Unittests wird man nicht viel refactoren.

Gibt da gute Bücher drüber, Martin Fowlers "Refactoring: Improving the Design of Existing Code" sei empfohlen, eines der besten SW Bücher die ich bis heute gelesen habe.

Leute die beim ersten Mal alles richtig machen (Design & Code) brauchen weder Unittests noch Refactoring, für alle anderen sind diese beiden wahrscheinlich die mächtigsten "Werkzeuge" die ein Entwickler haben kann.

 

[ARadauer]

Gibt da gute Bücher drüber, Martin Fowlers "Refactoring: Improving the Design of Existing Code" sei empfohlen, eines der besten SW Bücher die ich bis heute gelesen habe.

ha lustig... das liegt gerade neben mir ;-) habs aber noch nicht gelesen. Hat mal in unserer Firma jeder bekommen... gut dann weiß ich schon was ich mir übers wochenende ansehe...

 

[The_S]

Wer macht denn schon von Anfang an alles richtig? Das ist dann wohl der Ausnahmefall.

 

[maki]

ha lustig... das liegt gerade neben mir habs aber noch nicht gelesen. Hat mal in unserer Firma jeder bekommen... gut dann weiß ich schon was ich mir übers wochenende ansehe...

Er erklärt einem wie man in kleinen zwischenschritten von "stinkendem" Code zu sauberem Code kommt.
Es gibt Refactorings für alles, vom conditionalen if/switch zur Polymorphy, etc. pp.
Warum wir das nicht immer machen?
Weil es eben problematisch ist eine funktionierende SW mit schlechtem Design in eine nicht funktionierende SW mit gutem Design umzuwandeln
Deswegen: Ohne gute Unittests ist bald Schicht im Schacht mit refactoren, alleine der Paranoia wegen.

Wer macht denn schon von Anfang an alles richtig?

imho macht das niemand
Aber wenn's funktioniert lässt man es...

 

[Marco13]

Noch ein bißchen Senf: In erster Näherung ist die Anzahl der Methoden nicht relevant.

Auch nicht die Anzahl der Zeilen. Die Anzahl der Zeilen ist IMHO ein fragwürdiges Maß. Es ist die einzig sinnvolle Möglichkeit, die ich kenne, um die Komplexität eines Programmes ansatzweise zu beurteilen: Man zählt die Zeilen (und das heißt: Die Anzahl der Semikolons). Aber dass man ein und dieselbe Funktionalität entweder mit einer Zeile oder mit 50 Zeilen erreichen kann, sollte einem immer bewußt sein.
Und was die Grenze von 2000 Zeilen angeht: 2000 Zeilen CODE (!?!) sind ziemlich viel. Zufälligerweise enthält die JTable.java ziemlich genau 2000 Zeilen CODE. Und das ist ein 350KB-Monster mit ca. 10000 Zeilen INSGESAMT, und ca. 150 (!) public-Methoden. (Gut, neulich bin ich auch über eine .java-Datei gestolpert, die ca. 2.5 MEGAbyte hatte, aber lassen wir das mal außen vor...)

Relevant ist IMHO eher die Anzahl und die Aufgaben der öffentlichen Methoden. Wenn eine Klasse 3 public Methoden hat, die eine klare, dedizierte Funktionalität bereitstellen, dann ist (erstmal!) nicht so wichtig, ob sie diese Funktionalität denn nun mit 1000 Zeilen in 100 private-Methoden erreicht, oder mit 100 Zeilen in 10 private-Methoden und 10 (nicht-öffentlichen) Hilfsklassen.

Dass ein rechtzeitiges Aufbrechen und Strukturieren besser ist, als so einen Lava-Flow in Form einer unbeherrschbaren Riesen-Klasse entstehen zu lassen, sollte aber klar sein.