Regions or no regions – this is the question

Die dnc12 ist gerade vorbei und wir k├Ânnten uns schon wieder zusammensetzen ­čÖé
Heute gab es auf Twitter eine kurz angerissene Diskussion, die das Zeug dazu hatte, die Gem├╝ter aufzuheizen: soll man oder soll man nicht #regions nutzen?

 

Nach dem kurzen Tweet-Austausch wurde es klar, dass es viele Entwickler gibt, die Regions gerne nutzen. Ich habe zwar den ganzen Abend nachgedacht, habe allerdings keine Gr├╝nde gefunden, sie selbst verwenden zu wollen.

 

Ich meine, warum sollte man Code NICHT sehen wollen?

  • Geht es vielleicht um eine oder mehrere Methoden, die man ausblenden will? Das w├╝rde aber entweder bedeuten, dass man
    – die Funktionalit├Ąt der ganzen Klasse ausblendet, aber dann wozu, man ├Âffnet einfach die Klasse nicht ­čśë
    – nur ein Teil der Funktionen ausblendet, und dann stellt sich die Frage, warum manche Funktionen viel ├Âfter angeschaut werden als andere? Das hat f├╝r mich irgendwie ein CodeSmell
  • Geht es vielleicht um ein Teil einer einzigen Methode, und zwar einer ganz gro├čen, sonst w├╝rde man sie nicht teilweise ausblenden wollen? Zusammengeklappt w├╝rde man dann eine Art Kommentar sehen, was mich sofort an Martin Fowlers Hinweis bez├╝glich Kommentare erinnert hat: Kommentare sind ideale Namensgeber. Wenn man im Code einen Kommentar braucht, dann ist das meistens ein Smell f├╝r ein Extract Method (genauso wie die Tatsache, dass die Methode wahrscheinlich zu lang ist)

    You have a code fragment that can be grouped together.

    Turn the fragment into a method whose name explains the purpose of the method.

  • Geht es vielleicht um Regionen um Methoden, Events, Fields, Properties, also nach Sichtbarkeit und Rolle? Daf├╝r k├Ânnte ich einen einzigen Grund vorstellen, und zwar den, dass man auf Anhieb die ├Âffentliche Methoden und Eigenschaften sehen will. Das w├Ąre allerdings die Aufgabe eines Interfaces, oder? Dazu kommt auch noch meine – pers├Ânliche – Vorliebe, Code wie ein Buch zu lesen, von oben nach unten, also von einer ├Âffentlichen Methode weiter in die Details, also zu den privaten Methoden (ganz nach CCD – Single Level of Abstraction (SLA))

    Hilfreich als Analogie ist der Blick auf Artikel in der Tageszeitung: dort steht zu oberst das Allerwichtigste, die ├ťberschrift. Aus ihr sollte in groben Z├╝gen hervorgehen, wovon der Artikel handelt. Im ersten Satz des Artikels wird dies auf einem hohen Abstraktionsniveau beschrieben. Je weiter man im Artikel fortschreitet, desto mehr Details tauchen auf. So k├Ânnen wir auch unseren Code strukturieren. Der Name der Klasse ist die ├ťberschrift. Dann folgen die ├Âffentlichen Methoden auf hohem Abstraktionsniveau. Diese rufen m├Âglicherweise Methoden auf niedrigerem Niveau auf, bis zuletzt die “Bitpfriemelmethoden” ├╝brig bleiben. Durch diese Einteilung kann ich als Leser der Klasse entscheiden, welchen Detaillierungsgrad ich mir ansehen m├Âchte. Interessiert mich nur grob, wie die Klasse arbeitet, brauche ich mir nur die ├Âffentlichen Methoden anzuschauen. In ihnen wird die Funktionalit├Ąt auf einem hohen Abstraktionsniveau gel├Âst. Interessieren mich weitere Details, kann ich tiefer einsteigen und mir die privaten Methoden ansehen.

Was meint ihr, ├╝bersehe ich da was? (Notiz an mich: bei #nossued das Gespr├Ąch fortsetzen!)