5. Immer kleinere Klassen

Immer kleinere Klassen

  • G

    Hi!

    Ich habe ja vor einiger Zeit schonmal erzählt, dass meine Klassen recht klein sind und wohl auch immer kleiner werden. Damals hatte eine durchschnittliche Klasse bei mir 60 Codezeilen. Der Trend hat sich fortgesetzt und inzwischen hat eine durchschnittliche Klasse bei mir 46 Codezeilen.

    Das ist doch nicht normal, oder? Wie sieht das bei euch aus? Gibt es Nachteile von vielen kleinen Klassen? ...oder Vorteile? Deutet das auf irgendein Fehldesign meines Projekts hin, was mich vielleicht in ein paar Monaten zur Verzweiflung treibt? 🙂

    Ich arbeite wohl ne Menge mit "Funktoren", oder wie man die nennt. Wahrscheinlich läßt sich die kleine Klassengröße darauf zurückführen. Ist das in dem Maße schlecht?

    Ich habe auch keine größere Klasse. Ich glaube, meine größte Klasse umfaßt weniger als 200 Codezeilen. Somit hat jede Klasse ein sehr begrenztes Aufgabengebiet. Ist das gut oder schlecht?

    Edit : Autsch : Wo ich mir den alten Thread so durchlese, stelle ich fest, dass die Frage eigentlich schon recht ausführlich besprochen wurde. Sorry, dass ich sie nochmal gestellt habe. Ich lasse sie trotzdem mal stehen. Vielleicht hat sich ja bei euch auch etwas verändert, oder jemand anderes möchte noch etwas dazu sagen.

    [ Dieser Beitrag wurde am 16.12.2002 um 04:18 Uhr von Gregor editiert. ]

    0
  • C

    Na ja da gibts verschiedene Ansichten. In der UML beispielsweise gibt es zwei Beschreibungen für Klassentypen die beide nicht unbedingt immer empfehlenswert sind.

    1. Swiss-Army-Knife: Eine Klasse die alles und jedes selbst macht, ein Monolith, omnipotent, riesengroß
    2. Ghost, Poltergeist: Eine kleine Klasse die sofort nachdem sie eine Aufgabe bekommt diese in windeseile ausführt und den Programmablauf wieder zurückgibt. "Aufblitzende Funktionalität", es ist schwer zu glauben, daß eine solche kleine Klasse überhaupt eine Existenzberechtigung bekommt da man sie ohne weiteres in eine andere Klasse mitintegrieren könnte

    Viele kleine Klassen sind eigentlich ein Indiz für Overstructuring - OO-Designs vom Typus "Ich breche alles runter bis aufs Atom" sind nicht wirklich immer vorteilhaft.

    In jedem Fall abere - Je schneller die Ausführung desto besser 🙂

    0
  • G

    Ab wann ist ein Objekt ein Poltergeist? Sind damit nur kleine, temporäre Objekte gemeint, die nach 5ms wieder weg sind? Soetwas habe ich nicht. Ich habe bei meinem Projekt festgestellt, dass solche Objekte echte Performance-killer sind.

    Ich erzeuge allerdings Objekte, die vielleicht 0,5 Sekunden existieren. Zum Beispiel Objekte, die etwas bestimmtes mit einem Pixel machen, die ich dann über alle Pixel eines Bildes rüberlaufen lasse. Eigentlich habe ich diese Objekte nur, um mir ne Menge ifs bzw. switche in vielen Klassen zu ersparen. Sie sind also nur da, um den Code klein zu halten und um Redundanz zu beseitigen.

    0
  • C

    Ich kann das so nicht pauschal sagen ab wann eine Klasse zum Typus "Poltergeist" gehört. Relativ gesprochen würde ich sagen Objekte die nur kurz etwas ausführen und dann sofort wieder von der Bildfläche verschwinden.

    Nur um noch etwas detaillierter zu sein. Die hier angesprochenen Typen finden sich auch unter dem Namen "Anti-Patterns" wieder. Hier eine erweiterte, nicht vollständige Liste der Anti-Patterns:

    • Cut and Paste Programming
    • Hardcodes Are Evil "Ich sollte nie Dinge hartkodieren - wenn ich das tue sorge ich dafür dass es keiner rauskriegt"
    • Blind Faith "Wenn ich OO-Features nutze muss ich daraus einen Vorteil ziehen können.
    • Big Ball of Mud
    • Lava Flow
    • Poltergeist
    • Boat Anchor
    • Speghetti Code
    • Fat Commands
    • Busyspin
    • God Object
    • Bypassing Containers
    • Back Peddeling
    • Abstraction Inversion
    • Functional Classes
    • Object Orgy
    • Feature Envy
    • Empty Subclass Failure
    • Checking Type Instead of Membership
    • Action at a Distance
    • Accumulate and Fire
    • Contrived Interfaces (premature generalitation)
    • Multiple Inheritance
    • Syntax Errors, Runtime Errors, Semantic Errors
    • Race Conditions (Threads, Processes, Callbacks/Events)
    • Excessively Generic Names (synonyms- abstract spawner manager cache - good and bad, c2.com)
    • Keep It Simple (Intention verständlich halten, erweiterbar wenn notwendig ... nicht von vornherein)
    • Polling
    • Caching Failure

    Einige, für mich wichtige, Punkte habe ich markiert.

    [ Dieser Beitrag wurde am 16.12.2002 um 14:06 Uhr von CengizS editiert. ]

    0
  • G

    Noch eine Frage zu Poltergeistern :

    Sind damit Klassen gemint, die genau einmal kurz eingesetzt werden, oder auch Klassen, die öfter kurz eingesetzt werden!

    0
  • G

    Oh! Die Liste scheint interessant zu sein. Wo kriegt man genauere Erläuterungen zu den einzelnen "Anti-Patterns" her?

    0
  • G

    Multiple Inheritance

    Oh-Oh! ...Lass das mal blos nicht die C++-Leute sehen! 😃 🙂

    0
  • C

    Das ist mir egal 🙂 Die ++'er sollen sich um ihren Kram kümmern 😉

    Poltergeister sind diejenigen die oft, sehr kurz eingesetzt werden. Wenn ein Objekt nur einmal aufleuchtet und dann im Nirvana verschwindet hat es a priori keine Existenzberechtigung in meinen Augen 🙂

    [ Dieser Beitrag wurde am 16.12.2002 um 14:08 Uhr von CengizS editiert. ]

    0
  • C

    Bücher dazu:
    ISBN 1-55851-397-3 Pitfalls Of Object Oriented Development
    ISBN 0471197130 Anti Patterns

    0
  • G

    Danke!

    0
Anmelden zum Antworten