Es ist bewiesen, dass wir mehr Zeit mit dem Lesen von Code verbringen als mit dem Schreiben, daher können Sie sicher sein, dass gute Benennungen sich in der Zukunft auszahlen werden.
Eines der häufigsten Probleme von Entwicklern ist die Benennung. Ich kann nicht zählen, wie viele Stunden ich damit verbracht habe, darüber nachzudenken, wie man Dinge benennt und wie viele Stunden es mich gekostet hat, Code mit schlechten Namen zu verstehen. Es spielt keine Rolle, ob es sich um ein Objekt, eine Methode, eine Klasse oder etwas anderes handelt. Es ist bewiesen, dass wir mehr Zeit mit dem Lesen von Code verbringen als mit dem Schreiben, daher zahlt sich gute Benennung immer in der Zukunft aus.
Gute Namen zu verwenden macht Ihren Code besser und sauberer. Es hilft Ihnen, intuitiv zu erkennen, welche Verantwortlichkeiten jeder Teil des Codes hat. Es macht Ihre Anwendung in der Zukunft für andere Entwickler sowie für Sie selbst leicht lesbar.
In den nächsten Minuten möchte ich die Bedeutung guter Benennungen erklären und einige nützliche Tipps zum Finden guter Namen teilen.
Abstraktionsniveau
Methoden und Variablen sollten nach dem benannt werden, was sie bedeuten. Bevor Sie einen Namen vergeben, überlegen Sie sich, welche Verantwortung dieser Codeabschnitt hat.
Betrachten wir den Fall einer Methode, die einen String mit der Entfernung zwischen Warschau und Paris zurückgibt.
Es ist einfach und scheint richtig zu funktionieren, aber was ist, wenn wir die Anforderungen ein wenig ändern? Jetzt möchte ich die Möglichkeit haben, den Satz auf zwei verschiedene Arten anzuzeigen: in Kilometern und Meilen. Dazu muss ich eine Variable in die Klasse einführen. Diese Variable wird verwendet, um das Wort km in der to_s-Methode zu ersetzen.
Die neue Variable sollte auf einem höheren Abstraktionsniveau als ihre Werte benannt werden. Das bedeutet, dass wir zuerst über den Zweck der Variablen nachdenken müssen. Das wird uns helfen, ihr einen allgemeineren Namen zu geben, der gleichzeitig nicht zu vage sein sollte. Zusammenfassend muss der Name den Zweck der Variablen andeuten, aber nicht ihre möglichen Werte.
Was ist also die Verantwortung unserer neuen Variablen? Sie soll die Wörter km oder mi in das Objekt einführen. Der Name könnte also kilometers_or_miles sein, aber das ist genau das gleiche Abstraktionsniveau wie seine Werte. Wenn wir die Möglichkeit hinzufügen wollten, eine andere Einheit (zum Beispiel Tage) zu verwenden, wäre der Name kilometers_or_miles falsch. Wir sollten etwas Allgemeineres in Betracht ziehen. Kilometer und Meilen sind Maßeinheiten, daher wäre ein guter Name unit. Es ist ein Abstraktionsniveau höher (allgemeiner) als die Verantwortung der Variablen. Daher sieht die neue Klassenimplementierung wie folgt aus:
Die zweite Sache ist, dass die Entfernung zwischen Warschau und Paris tatsächlich 1591 Kilometer beträgt, aber auch 988 Meilen. Es ist also Zeit, eine Methode zu implementieren, die den richtigen Wert zurückgibt. Die Regel ist die gleiche wie bei der unit-Variablen. Lassen Sie uns zuerst über die Bedeutung nachdenken. Die neue Methode soll die Werte 1591 oder 988 zurückgeben, die die Entfernung zwischen Warschau und Paris darstellen. Es spielt keine Rolle, wie die Methode ihre Aufgabe erfüllt. Wir könnten sie distance_warsaw_paris nennen, aber das ist auf dem gleichen Abstraktionsniveau wie der zurückgegebene Wert. Das bedeutet, dass der Name der Methode mögliche Rückgabewerte andeutet. Diese Art der Benennung ist zu detailliert.
In Zukunft können die Städte durch andere ersetzt werden, zum Beispiel: New York und London. Daher wird der Name distance_warsaw_paris veraltet sein, und eine Änderung an jedem Ort würde hohe Kosten verursachen. Die beste Lösung ist, sie distance zu nennen. Das ist genau das, was wir wollten — ein Abstraktionsniveau höher als der Methodeninhalt.
Nach diesem Verfahren sehen unsere beiden Methoden wie folgt aus:
Abstraktionsniveau und Klassennamen
Methoden und Variablen sollten auf einem höheren Abstraktionsniveau als ihr Inhalt benannt werden, aber die Benennung von Klassen ist eine andere Geschichte. Bei der Erstellung einer Klasse müssen wir die Zukunft nicht antizipieren. Der Name einer Klasse sollte auf ihren zeitgenössischen Annahmen basieren. Wir erwarten nicht, dass ein Auto die Eigenschaften eines Bootes annimmt. Daher sollte, wenn die aktuellen Anforderungen der App besagen, dass ein Auto benötigt wird, der Klassenname Car anstelle von Vehicle sein.
Kindklassen sollten auf die gleiche Weise benannt werden. Mit der Car-Klasse können wir eine spezifischere Version hinzufügen, zum Beispiel CarPickup für eine spezielle Art von Car, die einen größeren Laderaum hat.
Dies impliziert, dass die Regel, Dinge auf einem höheren Abstraktionsniveau als ihren Inhalt zu benennen, für Methoden und Variablen gilt, jedoch nicht für Klassen.
Prinzip der Einzelverantwortung
Eines der SOLID Prinzipien besagt, dass jedes Modul oder jede Klasse nur für eine Sache verantwortlich sein sollte. Es ist einfach einfacher, ein Element zu benennen, das nur eine Funktion hat.
Zum Beispiel ist die einzige Verantwortung einer Flasche, ein Behälter für Flüssigkeiten zu sein. Wir sollten einem Flaschenmodul nicht die Möglichkeit geben, sich zu bewegen oder andere Dinge zu tun, die nicht die einfache Verantwortung einer Flasche sind (in der App). Wie würden Sie einen Behälter für Flüssigkeiten nennen, der sich bewegen kann?
Es ist ziemlich schwierig, und die Flasche ist nur ein einfaches Beispiel. Anstatt auf die Idee von gehenden (und dann möglicherweise tanzenden, rennenden und sprechenden) Flaschen zu kommen, ist es besser, das Prinzip der Einzelverantwortung zu verwenden. Erstellen Sie eine Klasse für einen Flüssigkeitsbehälter, nennen Sie sie Bottle, und eine andere für eine bewegliche Flasche, nennen Sie sie BottleCarrier.
Das Prinzip der Einzelverantwortung betrifft auch Variablen. Jede Variable sollte nur eine Verantwortung haben, egal ob es sich um eine Variable einer Methode, einer Klasse oder eine andere Art von Variable handelt. Wie bei der Benennung von Klassen ist es einfach einfacher, eine Variable zu benennen, die nur eine Verantwortung hat.
Betrachten Sie die Domäne als eine Ansammlung kleinerer Teile
Gute Architektur geht Hand in Hand mit guten Namen. Es ist einfacher, Dinge zu benennen, wenn man die Probleme versteht, die sie lösen. Eine der Techniken, die hilft, eine bessere Architektur zu bauen, besteht darin, jeden Teil Ihrer Aufgabe in kleine Stücke zu zerlegen. Das macht das Benennen schneller und einfacher.
Denken Sie nur darüber nach, ist es nicht besser, Module oder Objekte zu benennen, wenn Sie wissen, welches ihren Zweck ist? Nehmen wir an, wir müssen ein Auto beschreiben. Es ist schwierig, jede Funktionalität in einer Klasse zu benennen, aber wenn wir es in viele kleinere Teile aufteilen, stellt sich heraus, dass wir Wheel, Tire, steeringWheel Klassen zusammen mit anderen Klassen erstellen können, die allen anderen Teilen gewidmet sind, die ein Auto enthalten kann. Diese kleineren Komponenten sind leicht zu benennen und ihre Zwecke sind leicht zu spezifizieren. Deshalb, wenn Ihre Komponenten schwer zu benennen sind, kann das bedeuten, dass Sie einige Probleme mit der App-Architektur haben.
Zusammenfassung
Jeder gute Name, der einer Variablen, Methode, Objekt oder Klasse gegeben wird, wird sich früher oder später auszahlen. In meinem Artikel habe ich einige einfache Techniken gezeigt, die Ihnen helfen werden, gute Namen zu vergeben:
- Gehen Sie eine Abstraktionsebene höher als der Körper (alle außer Klassennamen)
- Der Name sollte die Verantwortung der Klasse beschreiben
- Respektieren Sie die Einzelverantwortung (eine der SOLID-Regeln)
- Teilen Sie Probleme in kleinere Teile auf
Gutes Benennen muss nicht schwierig sein. Es lohnt sich wirklich, etwas Zeit darauf zu verwenden, Dinge richtig zu benennen. Mit den oben aufgeführten Tipps wird dieser Prozess schneller.
Dieser Artikel wurde von dem Buch „99 Bottles of OOP“, geschrieben von Sandi Metz & Katrina Owen, inspiriert. Ich ermutige Sie, es zu lesen. Neben der Frage, wie man Dinge benennt, werden Sie auch gute Praktiken für die Code-Refaktorisierung lernen.
