it-swarm.dev

Wie viele Zeilen pro Klasse sind in Java zu viele?

Was ist Ihrer Erfahrung nach eine nützliche Faustregel dafür, wie viele Codezeilen für eine Klasse in Java zu viele sind?

Um es klar auszudrücken, ich weiß, dass die Anzahl der Zeilen nicht einmal dem tatsächlichen Standard entspricht, der für das verwendet werden soll, was in einer bestimmten Klasse sein sollte und was nicht. Klassen sollten gemäß den richtigen OOP) Philosophien (Kapselung usw.) gestaltet werden. Eine Faustregel könnte jedoch einen nützlichen Ausgangspunkt für Überlegungen zur Umgestaltung bieten (dh "Hmmm, diese Klasse" hat> n Codezeilen; es ist wahrscheinlich unlesbar und macht einen miesen Job der Kapselung, also möchte ich vielleicht sehen, ob es irgendwann überarbeitet werden sollte ").

Auf der anderen Seite haben Sie vielleicht Beispiele für sehr große Klassen gefunden, die immer noch gehorchten OOP Design gut und trotz ihrer Länge lesbar und wartbar waren?

Hier ist ein verwandtes, nicht doppeltes Frage zu Zeilen pro Funktion .

76
Michael McGowan

Einige interessante Metriken:

 junit fitnesse testNG tam jdepend ant Tomcat 
 ----- -------- ------ --- ------- --- - ----- 
 max 500 498 1450 355 668 2168 5457 
 Mittelwert 64,0 77,6 62,7 95,3 128,8 215,9 261,6 
 min 4 6 4 10 20 3 12 
 Sigma 75 76 110 78 129 261 369 
 Dateien 90 632 1152 69 55 954 1468 
 Gesamtzeilen 5756 49063 72273 6575 7085 206001 384026 

Ich benutze FitNesse als Benchmark, weil ich viel damit zu tun hatte, es zu schreiben. In FitNesse ist die durchschnittliche Klasse 77 Zeilen lang. Keine ist länger als 498 Zeilen. Die Standardabweichung beträgt 76 Zeilen. Das bedeutet, dass die überwiegende Mehrheit der Klassen weniger als 150 Zeilen umfasst. Sogar Tomcat, das eine Klasse mit mehr als 5000 Zeilen hat, hat die meisten Klassen mit weniger als 500 Zeilen.

Vor diesem Hintergrund können wir wahrscheinlich 200 Zeilen als gute Richtlinie verwenden, um unten zu bleiben.

80
Uncle Bob.

Codezeilen sind für mich in diesem Zusammenhang irrelevant. Es geht um die Anzahl der verschiedenen Gründe, warum ich in diese Klasse kommen würde, um sie zu ändern.

Wenn ich zu dieser Klasse kommen würde, wenn ich die Regeln für die Validierung einer Person ändern möchte, möchte ich nicht zu derselben Klasse kommen, um die Regeln für die Validierung einer Bestellung zu ändern, und ich möchte auch nicht hierher kommen, um zu ändern, wo ich bin eine Person bestehen.

Das heißt, wenn Sie darauf abzielen, werden Sie selten Klassen mit mehr als 200 Zeilen finden. Sie werden aus triftigen Gründen passieren, aber sie werden selten sein. Wenn Sie also nach einer Metrik mit roter Flagge suchen, ist dies kein schlechter Ausgangspunkt. Aber machen Sie es zu einer Richtlinie, nicht zu einer Regel.

32
pdr

Es tut mir leid, aber ich bin sehr überrascht, dass viele Antworten besagen, dass es "nicht wirklich wichtig" ist. Es ist sehr wichtig, wie viele Zeilen in einer Klasse sind. Warum? Betrachten Sie diese Prinzipien beim Schreiben von good Java code ...

  • Testbarkeit
  • Zusammenhalt
  • Kupplung
  • Verständlichkeit

Klassen mit vielen Zeilen verstoßen höchstwahrscheinlich gegen all diese Prinzipien.

Für diejenigen, die gesagt haben, dass es "nicht wirklich wichtig ist" ... wie viel Spaß hat es für Sie gemacht, eine Klasse mit mehr als 5000 Zeilen zu verstehen? Oder um es zu ändern? Wenn du sagst, dass das Spaß macht, hast du eine seltsame Affinität zu Schmerz ...

Ich würde sagen, dass jede Klasse, die mehr als 1000 Zeilen enthält, dies tun sollte mindestens in Frage gestellt werden, wie sie möglicherweise gegen die oben genannten Prinzipien verstoßen und möglicherweise in mehrere "Off-Shoot" -Klassen unterteilt werden.

Meine Kommentare basieren auf dem Lesen und Studieren von Autoren wie Martin Fowler, Joshua Bloch und Misko Hevery. Sie sind ausgezeichnete Ressourcen, um guten Java Code) zu schreiben.

Tun Sie dem nächsten Mann (der Sie in ein paar Jahren sein könnte) einen Gefallen und bemühen Sie sich, Klassen zu schreiben, die weniger als mehr Zeilen enthalten.

24
Zack Macomber

Dies hängt von der Komplexität ab, nicht von der Anzahl der Zeilen. Ich habe große dumme Routinen geschrieben, die leicht zu verstehen waren und genau eines taten und es gut machten, aber Hunderte von Zeilen weitergingen. Ich habe ziemlich kurze Funktionen geschrieben, die schwer zu verstehen (und zu debuggen) waren.

Eine andere Sache, die Sie betrachten könnten, ist die Anzahl der öffentlichen Funktionen in einer Klasse. Das kann auch ein Warnzeichen sein.

Ich habe keine guten Zählungen zur Verfügung, aber ich würde vorschlagen, einen anständigen Code zu betrachten, der nützliche Dinge in Ihrem Geschäft tut, und ihn darauf aufzubauen. Natürlich sollten Sie sich die längsten Klassen und die größten APIs ansehen.

12
David Thornley

Die richtige Antwort ist 42. Nur ein Scherz.
Tatsächlich beträgt die maximale empfohlene Anzahl von Zeilen pro Klasse 2000 Linien.

"Java Code Conventions" seit 1999 haben es so ausgedrückt:
Dateien mit mehr als 2000 Zeilen sind umständlich und sollten vermieden werden.

Nachdem ich die Sun/Oracle-Codierungskonventionen befolgt habe, seit Java erfunden wurde), habe ich festgestellt, dass diese Faustregel für Zeilen pro Klasse angemessen ist. 99% Ihrer Java = Code sollte konform sein ... Und wenn es über 2000 geht, setzen Sie einfach ein TODO an die Spitze und sagen Sie, dass die Klasse Arbeit braucht.

Das Schlimmste ist der umgekehrte Fall, wenn Programmierer zu viele kleine Klassen mit fast keiner wirklichen Funktionalität in jeder Klasse erstellen. Programmierer ignorieren den Ratschlag "Komposition bevorzugen" und erstellen Hunderte von ererbenden Klassen, die komplizierte Objektmodelle erstellen, die weitaus schlimmer sind als das Problem der großen Klassen (die zumindest normalerweise die Funktionalität mit einem relevanten Klassennamen beibehalten).

http://www.Oracle.com/technetwork/Java/javase/documentation/codeconventions-141855.html#304

5
user1865223

Es gibt zu viele Codezeilen, wenn die Klasse zu viele verschiedene Dinge tut. Wenn Sie dem Prinzip der Einzelverantwortung für Klassen folgen, ist die Größe der Klasse im Wesentlichen begrenzt.

In Bezug auf physikalische Einschränkungen können Sie haben (Quelle: Klassendateiformat Java5 ):

  • 65.536 Konstanten, angewendete Schnittstellen, Felder, Methoden und Attribute - jeweils. HINWEIS: Ihnen wird der konstante Speicherplatz ausgehen, bevor Ihnen der anderen Elemente ausgehen. ANMERKUNG 2: Attribute sind Klassendateikonstrukte - nicht zu verwechseln mit '@Attribute'-Markern (d. H. Debug-Informationen und Bytecode werden als separate Attribute für eine Methode gespeichert).
  • Jede Methode kann 4 GB (32 Bit) generierten Bytecode enthalten. HINWEIS: Java-Versionen vor 1.5 konnten für jede Methode nur 64 KB (16 Bit) generierten Bytecode enthalten.

Kurz gesagt, die Klassendatei kann viel größer sein, als jeder für nützlich halten würde. Wenn Sie sich an das Prinzip der Einzelverantwortung halten, haben Ihre Klassendateien die richtige Größe.

5
Berin Loritsch

Code reinigen:

Klassen sollten klein sein!

Die erste Regel von Klassen ist, dass sie klein sein sollten. Die zweite Regel von Klassen ist, dass sie kleiner sein sollten. Nein, wir werden nicht genau denselben Text aus dem Kapitel "Funktionen" wiederholen. Aber wie bei Funktionen ist kleiner die Hauptregel beim Entwerfen von Klassen. Wie bei Funktionen lautet unsere unmittelbare Frage immer "Wie klein?"

** Mit Funktionen haben wir die Größe durch Zählen der physischen Linien gemessen. Bei Klassen verwenden wir ein anderes Maß. Wir zählen Verantwortlichkeiten. **

Der Name einer Klasse sollte beschreiben, welche Aufgaben sie erfüllt. Tatsächlich ist die Benennung wahrscheinlich die erste Möglichkeit, die Klassengröße zu bestimmen. Wenn wir keinen präzisen Namen für eine Klasse ableiten können, ist dieser wahrscheinlich zu groß. Je mehrdeutiger der Klassenname, desto wahrscheinlicher ist es, dass er zu viele Verantwortlichkeiten hat. Beispielsweise weisen Klassennamen, einschließlich Wieselwörtern wie Processor oder Manager oder Super, häufig auf eine unglückliche Zusammenfassung von Verantwortlichkeiten hin.

Dann:

  • Stellen Sie einfach sicher, dass Ihre Methoden nur eines tun.
  • Stellen Sie dann sicher, dass die Klasse nicht zu viele Verantwortlichkeiten hat.

Sie erhalten eine Klasse von überschaubarer Größe.

4

Versuchen Sie es mit einer besseren Metrik.

Ein Beispiel ist die ABC-Metrik. Es ist eher ein Maß dafür, wie viel Arbeit der Code leistet, als wie viel Code vorhanden ist.

2
sylvanaar

Die Anzahl der Zeilen ist eine ziemlich schlechte Metrik für die Klassenqualität. Für mich beschäftige ich mich gerne (wie andere bereits erwähnt haben) mit öffentlichen Methoden sowie mit öffentlich zugänglichen Eigenschaften (ich denke, öffentliche Getter/Setter in Java). Wenn ich eine Zahl aus der Luft ziehen müsste, um meine Aufmerksamkeit zu erregen, würde ich sagen, wenn es jeweils mehr als 10 gibt. Wirklich, wenn es mehr als 5 von Eigenschaften oder Methoden sind, werde ich einen Blick darauf werfen und oft Wege finden, um zu refaktorieren, aber alles über 10 ist normalerweise ein Warnsignal dafür, dass etwas ziemlich wahrscheinlich schlecht exponiert ist.

Es ist ein ganz anderes Gespräch, aber private Methoden und Felder riechen für mich weniger. Wenn sie also viel zur Anzahl der Zeilen beitragen, bin ich möglicherweise nicht so besorgt. Zumindest zeigt es, dass es wahrscheinlich keinen Gott-Controller gibt, der das Objekt aus der Ferne manipuliert, was ein ziemlich problematisches Designproblem ist.

2

Jede Zeile, die in die Problemdomäne Ihrer Klasse fällt, die außerhalb der Klasse geschrieben wurde, ist eine Zeile zu wenig und eine zu viele in der Klasse, in der sie lebt. Stellen Sie sich eine Klasse als Thema vor. Du musst es abdecken. So präzise wie möglich ist ideal, aber wenn es 500 Zeilen dauert, dauert es 500 Zeilen. Wenn 100 dieser Zeilen ein anderes Thema abdecken, gehören sie woanders hin. Das Aufteilen in kleinere Subdomänen innerhalb der Klasse als Innenklassen ist sinnvoll, aber ich würde diejenigen außerhalb der Klasse nur definieren, wenn sie anderweitig verwendet würden.

1
Erik Reppen