1. Der erste Buchstabe des Klassennamens sollte großgeschrieben werden. Der erste Buchstabe von Feldern, Methoden und Objekten (Handles) sollte ein Kleinbuchstabe sein. Wie bei allen Bezeichnern sollten alle darin enthaltenen Wörter nahe beieinander stehen, wobei der erste Buchstabe des dazwischen liegenden Wortes groß geschrieben werden sollte. Zum Beispiel:
Kopieren Sie den Code wie folgt: ThisIsAClassName
thisIsMethodOrFieldName
Wenn in der Definition ein konstantes Initialisierungszeichen vorkommt, schreiben Sie alle Buchstaben im statischen endgültigen Basistypbezeichner groß. Dadurch werden sie als Konstanten zur Kompilierungszeit markiert.
Java-Pakete sind ein Sonderfall: Sie sind alle in Kleinbuchstaben geschrieben, sogar die Mittelwörter. Bei Domänennamenerweiterungen wie com, org, net oder edu usw. sollten alle in Kleinbuchstaben geschrieben werden (dies ist auch einer der Unterschiede zwischen Java 1.1 und Java 1.2).
2. Wenn Sie eine Klasse für den allgemeinen Gebrauch erstellen, übernehmen Sie bitte die „klassische Form“ und fügen Sie Definitionen der folgenden Elemente hinzu:
Kopieren Sie den Codecode wie folgt:
gleich()
hashCode()
toString()
clone() (Cloneable implementieren)
Serialisierbar implementieren
3. Erwägen Sie für jede von Ihnen erstellte Klasse die Platzierung eines main(), das den Code zum Testen dieser Klasse enthält. Um Klassen aus einem Projekt zu verwenden, müssen wir den Testcode nicht löschen. Bei Änderungen jeglicher Art kann problemlos zum Testen zurückgekehrt werden. Der Code dient auch als Beispiel für die Verwendung von Klassen.
4. Die Methode sollte als kurze, funktionale Einheit konzipiert werden, die zur Beschreibung und Implementierung eines diskontinuierlichen Klassenschnittstellenteils verwendet werden kann. Idealerweise sollte der Ansatz prägnant und auf den Punkt gebracht werden. Wenn die Länge groß ist, sollten Sie erwägen, sie auf irgendeine Weise in kürzere Stücke zu unterteilen. Dies erleichtert auch die Wiederverwendung von Code innerhalb einer Klasse (manchmal müssen Methoden sehr groß sein, sollten aber trotzdem nur das Gleiche tun).
5. Versetzen Sie sich beim Entwerfen einer Klasse bitte in die Lage des Client-Programmierers (die Methode zur Verwendung der Klasse sollte sehr klar sein). Versetzen Sie sich dann in die Lage der Person, die den Code verwaltet (überlegen Sie, welche Änderungen voraussichtlich vorgenommen werden, und überlegen Sie, wie Sie diese einfacher gestalten können).
6. Gestalten Sie den Unterricht so kurz und prägnant wie möglich und lösen Sie nur ein bestimmtes Problem. Hier einige Vorschläge für die Klassengestaltung:
1. Eine komplexe Switch-Anweisung: Erwägen Sie die Verwendung des „polymorphen“ Mechanismus
2. Bei einer großen Anzahl von Methoden handelt es sich um Operationen mit sehr unterschiedlichen Typen. Erwägen Sie die Verwendung mehrerer Klassen, um sie separat zu implementieren.
3. Viele Mitgliedsvariablen haben sehr unterschiedliche Eigenschaften: Erwägen Sie die Verwendung mehrerer Klassen
7. Machen Sie alles so „privat“ wie möglich. Sie können einen Teil der Bibliothek „öffentlich“ machen (eine Methode, eine Klasse, ein Feld usw.), sodass er niemals entfernt werden kann. Wenn Sie es erzwingen, kann es den vorhandenen Code anderer Leute zerstören und sie dazu zwingen, ihn neu zu schreiben und zu entwerfen. Wenn Sie nur das veröffentlichen, was Sie veröffentlichen müssen, können Sie jederzeit alles andere ändern. In Multithread-Umgebungen ist der Datenschutz ein besonders wichtiger Faktor. Nur private Felder können vor unsynchronisierter Nutzung geschützt werden.
8. Seien Sie vorsichtig beim „Riesenobjekt-Syndrom“. Einige Anfänger, die an sequentielles Programmierdenken gewöhnt sind und neu im OOP-Bereich sind, möchten oft zuerst ein sequentielles Ausführungsprogramm schreiben und es dann in ein oder zwei große Objekte einbetten. Gemäß den Programmierprinzipien sollten Objekte das Konzept der Anwendung ausdrücken, nicht die Anwendung selbst.
9. Wenn Sie unansehnliche Programmierungen durchführen müssen, sollten Sie den Code zumindest in eine Klasse einfügen.
10. Immer wenn Sie feststellen, dass Klassen sehr eng integriert sind, müssen Sie überlegen, ob Sie interne Klassen verwenden sollten, um die Codierungs- und Wartungsarbeiten zu verbessern (siehe „Code mit internen Klassen verbessern“ in Kapitel 14, Abschnitt 14.1.2).
11. Fügen Sie Kommentare so sorgfältig wie möglich hinzu und verwenden Sie die Javadoc-Kommentardokumentsyntax, um Ihre eigene Programmdokumentation zu erstellen.
12. Vermeiden Sie die Verwendung „magischer Zahlen“. Diese Zahlen lassen sich nur schwer in den Code einfügen. Wenn Sie es in Zukunft ändern müssen, wird es zweifellos zu einem Albtraum, da Sie keine Ahnung haben, ob sich „100“ auf „Array-Größe“ oder „etwas ganz anderes“ bezieht. Deshalb sollten wir eine Konstante erstellen, ihr einen überzeugenden und beschreibenden Namen geben und im gesamten Programm Konstantenbezeichner verwenden. Dies erleichtert das Verständnis und die Wartung des Programms.
13. Wenn es um Builder und Ausnahmen geht, möchten Sie normalerweise jede im Builder abgefangene Ausnahme erneut auslösen, wenn sie dazu geführt hat, dass die Erstellung dieses Objekts fehlschlägt. Auf diese Weise wird der Aufrufer nicht weiterhin blind denken, dass das Objekt korrekt erstellt wurde.
14. Wenn Ihre Klasse nach der Verwendung des Objekts durch den Client-Programmierer Aufräumarbeiten erfordert, sollten Sie in Erwägung ziehen, den Bereinigungscode in einer klar definierten Methode zu platzieren und einen Namen wie „cleanup()“ zu verwenden, um Ihre Verwendung klar anzugeben. Darüber hinaus kann innerhalb der Klasse ein boolesches Flag platziert werden, um anzuzeigen, ob das Objekt gelöscht wurde. Stellen Sie in der finalize()-Methode der Klasse sicher, dass das Objekt gelöscht wurde und dass eine Klasse, die von RuntimeException erbt, verworfen wurde (sofern dies nicht bereits geschehen ist), was auf einen Programmierfehler hinweist. Bevor Sie eine solche Lösung wählen, stellen Sie sicher, dass finalize() auf Ihrem System funktioniert (möglicherweise müssen Sie System.runFinalizersOnExit(true) aufrufen, um dieses Verhalten sicherzustellen).
15. Wenn in einem bestimmten Bereich ein Objekt gelöscht werden muss (nicht vom Garbage-Collection-Mechanismus verarbeitet), verwenden Sie bitte die folgende Methode: Initialisieren Sie das Objekt. Geben Sie bei Erfolg sofort einen Try-Block mit einer Final-Klausel ein, um die Bereinigungsarbeit zu starten .
16. Wenn Sie finalize() während des Initialisierungsprozesses überschreiben (abbrechen) müssen, denken Sie bitte daran, super.finalize() aufzurufen (wenn Object zu unserer direkten Superklasse gehört, ist dies nicht erforderlich). Beim Überschreiben von finalize() sollte der Aufruf von super.finalize() die letzte und nicht die erste Aktion sein, um sicherzustellen, dass die Basisklassenkomponenten bei Bedarf noch gültig sind.
17. Wenn Sie Objektsammlungen fester Größe erstellen, übertragen Sie diese in ein Array (insbesondere, wenn Sie planen, diese Sammlung von einer Methode zurückzugeben). Auf diese Weise können wir die Vorteile der Array-Typprüfung zur Kompilierungszeit nutzen. Darüber hinaus muss der Empfänger des Arrays das Objekt möglicherweise nicht in das Array „umwandeln“, um es zu verwenden.
18. Versuchen Sie, Schnittstellen anstelle abstrakter Klassen zu verwenden. Wenn Sie wissen, dass etwas eine Basisklasse sein wird, sollte Ihre erste Option darin bestehen, es in eine Schnittstelle umzuwandeln. Nur wenn Sie Methodendefinitionen oder Mitgliedsvariablen verwenden müssen, müssen Sie diese in eine abstrakte Klasse umwandeln. Eine Schnittstelle beschreibt grundsätzlich, was der Client tun möchte, während eine Klasse bestimmten Implementierungsdetails gewidmet ist (oder diese zulässt).
19. Führen Sie im Inneren des Builders nur die Arbeiten aus, die erforderlich sind, um das Objekt in den richtigen Zustand zu versetzen. Vermeiden Sie nach Möglichkeit den Aufruf anderer Methoden, da diese Methoden möglicherweise von anderen überschrieben oder abgebrochen werden und während des Erstellungsprozesses zu unvorhersehbaren Ergebnissen führen (Einzelheiten finden Sie in Kapitel 7).
20. Objekte sollten nicht nur einige Daten enthalten; ihr Verhalten sollte auch klar definiert sein.
21. Wenn Sie eine neue Klasse auf Basis einer bestehenden Klasse erstellen, wählen Sie bitte zunächst „Neu“ oder „Erstellen“. Dieses Problem sollte nur berücksichtigt werden, wenn Ihre eigenen Designanforderungen übernommen werden müssen. Wenn die Vererbung dort eingesetzt wird, wo Neuschöpfung zulässig ist, wird das gesamte Design unnötig komplex.
22. Verwenden Sie Vererbung und Methodenabdeckung, um den Unterschied zwischen Verhaltensweisen auszudrücken, und verwenden Sie Felder, um den Unterschied zwischen Zuständen auszudrücken. Ein sehr extremes Beispiel ist die Darstellung von Farben durch Vererbung aus verschiedenen Klassen, was unbedingt vermieden werden sollte: Verwenden Sie direkt ein „Farb“-Feld.
23. Um Probleme beim Programmieren zu vermeiden, stellen Sie bitte sicher, dass jeder Name nur einer Klasse entspricht, auf die Ihr Klassenpfad verweist. Andernfalls könnte der Compiler zunächst eine andere Klasse mit demselben Namen finden und eine Fehlermeldung ausgeben. Wenn Sie vermuten, dass Sie auf ein Klassenpfadproblem gestoßen sind, versuchen Sie bitte, an jedem Startpunkt des Klassenpfads nach einer .class-Datei mit demselben Namen zu suchen.
24. Bei der Verwendung von Ereignis-„Adaptern“ in Java 1.1 AWT kann es besonders leicht zu einer Falle kommen. Wenn eine Adaptermethode überschrieben wird und die Schreibweise nicht besonders spezifisch ist, besteht das Endergebnis darin, eine neue Methode hinzuzufügen, anstatt die vorhandene Methode zu überschreiben. Da dies jedoch völlig legal ist, erhalten Sie keine Fehlermeldungen vom Compiler oder Laufzeitsystem, sondern Ihr Code verhält sich lediglich falsch.
25. Verwenden Sie vernünftige Designlösungen, um „Pseudofunktionen“ zu eliminieren. Das heißt, wenn Sie nur ein Objekt der Klasse erstellen müssen, beschränken Sie sich nicht im Voraus auf die Anwendung und fügen Sie einen Kommentar „Generiere nur eines davon“ hinzu. Bitte denken Sie darüber nach, es in eine „nur untergeordnete“ Form zu kapseln. Wenn Sie im Hauptprogramm viel verstreuten Code haben, der zum Erstellen Ihrer eigenen Objekte verwendet wird, sollten Sie eine kreative Lösung in Betracht ziehen, um diesen Code zu kapseln.
26. Seien Sie vorsichtig bei „Lähmung durch Analyse“. Denken Sie daran, egal was passiert, Sie müssen den Status des gesamten Projekts im Voraus verstehen und dann die Details prüfen. Da Sie die Gesamtsituation überblicken, können Sie unbekannte Faktoren schnell erkennen und verhindern, dass Sie bei der Betrachtung von Details in „tote Logik“ verfallen.
27. Seien Sie vorsichtig bei „vorzeitiger Optimierung“. Lassen Sie es zuerst laufen, denken Sie darüber nach, es später schneller zu machen, aber optimieren Sie es nur, wenn es nötig ist und wenn nachgewiesen ist, dass es in einem Teil des Codes einen Leistungsengpass gibt. Wenn Sie keine speziellen Tools zur Analyse von Engpässen verwenden, verschwenden Sie wahrscheinlich Ihre Zeit. Der implizite Preis von Leistungsverbesserungen besteht darin, dass Ihr Code schwerer zu verstehen und schwieriger zu warten ist.
28. Denken Sie daran, dass Sie viel mehr Zeit damit verbringen, Code zu lesen, als ihn zu schreiben. Ein klares Design führt zu einem leicht verständlichen Programm, aber Kommentare, sorgfältige Erklärungen und ein paar Beispiele sind oft von unschätzbarem Wert. Sie sind sehr wichtig, sowohl für Sie selbst als auch für diejenigen, die Ihnen folgen. Wenn Sie immer noch daran zweifeln, stellen Sie sich vor, wie frustriert Sie sind, wenn Sie versuchen, in der Online-Java-Dokumentation nützliche Informationen zu finden, und Sie werden vielleicht überzeugt sein.
29. Wenn Sie der Meinung sind, dass Sie eine gute Analyse, ein gutes Design oder eine gute Implementierung durchgeführt haben, ändern Sie bitte leicht Ihre Denkperspektive. Versuchen Sie, einige Außenstehende einzuladen, nicht unbedingt Experten, sondern Leute aus anderen Teilen des Unternehmens. Bitten Sie sie, Ihre Arbeit mit völlig neuen Augen zu betrachten und zu sehen, ob sie Probleme erkennen können, für die Sie blind waren. Durch die Anwendung dieser Methode können wir häufig einige Schlüsselprobleme in der Phase identifizieren, die am besten für Änderungen geeignet ist, und den Geld- und Energieverlust vermeiden, der durch die Lösung von Problemen nach der Veröffentlichung des Produkts entsteht.
30. Gutes Design kann den größten Nutzen bringen. Kurz gesagt, es dauert oft lange, die am besten geeignete Lösung für ein bestimmtes Problem zu finden. Aber sobald Sie die richtige Methode gefunden haben, wird Ihre zukünftige Arbeit viel einfacher sein und Sie müssen nicht Stunden, Tage oder Monate schmerzhaften Kampfes ertragen. Unsere harte Arbeit wird die größten (sogar unermesslichen) Belohnungen bringen. Und weil ich mir viel Mühe gegeben habe, habe ich endlich einen hervorragenden Designplan bekommen, und auch der Nervenkitzel des Erfolgs ist aufregend. Widerstehen Sie der Versuchung, die Arbeit zu überstürzen, da sich die Mühe oft nicht lohnt.