1. クラス名の最初の文字は大文字にする必要があります。フィールド、メソッド、オブジェクト (ハンドル) の最初の文字は小文字にする必要があります。すべての識別子と同様に、その中に含まれるすべての単語が近くに配置され、間にある単語の最初の文字が大文字になる必要があります。例えば：
次のようにコードをコピーします: ThisIsAClassName
このメソッドまたはフィールド名
定数初期化文字が定義に出現する場合は、静的な最終基本型識別子のすべての文字を大文字にします。これにより、それらはコンパイル時定数としてマークされます。
Java パッケージは特殊なケースで、中間語も含めてすべて小文字です。 com、org、net、edu などのドメイン名拡張子の名前はすべて小文字にする必要があります (これは Java 1.1 と Java 1.2 の違いの 1 つでもあります)。
2. 一般的に使用するクラスを作成する場合は、「古典的な形式」を採用し、次の要素の定義を含めてください。
次のようにコードをコピーします。
等しい()
ハッシュコード()
toString()
clone()（Cloneableの実装）
シリアル化可能を実装する
3. 作成するクラスごとに、そのクラスをテストするためのコードを含む main() を配置することを検討してください。プロジェクトのクラスを使用する場合、テスト コードを削除する必要はありません。何らかの変更が加えられた場合でも、簡単にテストに戻ることができます。このコードは、クラスの使用方法の例としても機能します。
4. メソッドは、不連続なクラス インターフェイス部分の記述と実装に使用できる、短い機能単位に設計される必要があります。理想的には、アプローチは簡潔で要点を絞ったものである必要があります。長さが長い場合は、何らかの方法で短い部分に分割することを検討してください。これにより、クラス内でのコードの再利用も容易になります (メソッドが非常に大きくなければならない場合もありますが、それでも同じことだけを行う必要があります)。
5. クラスを設計するときは、クライアント プログラマの立場に立ってください (クラスの使用方法が明確である必要があります)。次に、コードを管理する人の立場になって考えてみましょう (どのような変更が行われる可能性があるかを予測し、変更を簡素化する方法を検討します)。
6. 授業はできるだけ短く簡潔にし、特定の問題のみを解決します。クラス設計に関するいくつかの提案を次に示します。
1. 複雑な switch ステートメント: 「ポリモーフィック」メカニズムの使用を検討してください。
2. 多数のメソッドには、大きく異なるタイプの操作が含まれています。複数のクラスを使用してそれらを個別に実装することを検討してください。
3. 多くのメンバー変数は非常に異なる特性を持っています。複数のクラスの使用を検討してください。
7. すべてをできるだけ「プライベート」にしてください。ライブラリの一部（メソッド、クラス、フィールドなど）を「パブリック」にして、決して取り出せないようにすることができます。無理に実行すると、他の人の既存のコードが破壊され、書き直して設計する必要が生じる可能性があります。公開しなければならないものだけを公開する場合は、それ以外は自由に変更できます。マルチスレッド環境では、プライバシーが特に重要な要素になります。非同期使用から保護できるのはプライベート フィールドのみです。
8.「巨大物体症候群」に注意してください。逐次プログラミングの考え方には慣れていて、OOP 分野には慣れていない一部の初心者は、最初に逐次実行プログラムを作成してから、それを 1 つまたは 2 つの巨大なオブジェクトに埋め込むことを好むことがよくあります。プログラミング原則によれば、オブジェクトはアプリケーションそのものではなく、アプリケーションの概念を表現する必要があります。
9. 見苦しいプログラミングを行う必要がある場合は、少なくともコードをクラス内に置く必要があります。
10. クラスが非常に緊密に統合されていることがわかった場合は、コーディングとメンテナンス作業を改善するために内部クラスを使用するかどうかを検討する必要があります (第 14 章、セクション 14.1.2 の「内部クラスによるコードの改善」を参照)。
11. できるだけ慎重にコメントを追加し、javadoc コメント ドキュメント構文を使用して独自のプログラム ドキュメントを生成します。
12. 「マジック ナンバー」の使用は避けてください。これらの数字はコードに適合させるのが困難です。将来これを変更する必要がある場合は、間違いなく悪夢になるでしょう。「100」が「配列サイズ」を指しているのか、それとも「まったく別のもの」を指しているのかがわからないからです。したがって、定数を作成し、説得力のある説明的な名前を付け、プログラム全体で定数識別子を使用する必要があります。これにより、プログラムの理解と保守が容易になります。
13. ビルダーと例外に関して言えば、通常、オブジェクトの作成が失敗した原因となったビルダーでキャッチされた例外を再スローする必要があります。こうすることで、呼び出し元はオブジェクトが正しく作成されたと盲目的に考え続けることがなくなります。
14. クライアント プログラマがオブジェクトの使用を終了した後、クラスでクリーンアップ作業が必要な場合は、明確に定義されたメソッドにクリーンアップ コードを配置し、使用方法を明確に示す cleanup() のような名前を使用することを検討してください。さらに、ブール値フラグをクラス内に配置して、オブジェクトがクリアされたかどうかを示すことができます。クラスの Finalize() メソッドで、オブジェクトがクリアされていること、および RuntimeException を継承するクラスが (まだ破棄されていない場合は) 破棄されていることを確認して、プログラミング エラーを示していることを確認します。このような解決策を講じる前に、finalize() がシステム上で動作することを確認してください (この動作を確認するには、System.runFinalizersOnExit(true) を呼び出す必要がある場合があります)。
15. 特定のスコープで、オブジェクトをクリアする必要がある場合 (ガベージ コレクション メカニズムによって処理されない場合)、次の方法を使用してください: 成功した場合は、オブジェクトを初期化し、直ちに、finally 句を含む try ブロックに入ってクリーンアップ作業を開始します。 。
16. 初期化プロセス中に Finalize() をオーバーライド (キャンセル) する必要がある場合は、忘れずに super.finalize() を呼び出してください (Object が直接のスーパー クラスに属している場合、これは必要ありません)。 Finalize() をオーバーライドするプロセスでは、基底クラスのコンポーネントが必要なときに有効であることを保証するために、super.finalize() の呼び出しは最初のアクションではなく最後のアクションである必要があります。
17. 固定サイズのオブジェクト コレクションを作成する場合は、それらを配列に転送します (特に、このコレクションをメソッドから返す予定の場合)。このようにして、コンパイル時に配列型をチェックする利点を享受できます。さらに、配列の受信者は、オブジェクトを使用するためにオブジェクトを配列に「キャスト」する必要がない場合があります。
18. 抽象クラスの代わりにインターフェイスを使用するようにしてください。何かが基底クラスになることが分かっている場合、最初の選択肢はそれをインターフェースに変えることです。メソッド定義またはメンバー変数を使用する必要がある場合にのみ、抽象クラスに変換する必要があります。インターフェイスは基本的にクライアントが何をしたいのかを記述しますが、クラスは特定の実装の詳細に特化します（またはそれを可能にします）。
19. ビルダー内では、オブジェクトを正しい状態にするために必要な作業のみを実行します。他のメソッドの呼び出しは可能な限り避けてください。これらのメソッドは他のメソッドによってオーバーライドまたはキャンセルされ、ビルド プロセス中に予期しない結果が生じる可能性があります (詳細については第 7 章を参照)。
20. オブジェクトは単にデータを保持するだけでなく、その動作も明確に定義されている必要があります。
21. 既存のクラスをベースにして新しいクラスを作成する場合は、まず「新規」または「作成」を選択してください。この問題は、独自の設計要件を継承する必要がある場合にのみ考慮してください。新規作成が許可されている場所で継承を使用すると、設計全体が不必要に複雑になります。
22. 継承とメソッド カバレッジを使用して動作の違いを表現し、フィールドを使用して状態の違いを表現します。非常に極端な例は、さまざまなクラスからの継承を通じて色を表現することですが、これは絶対に避けるべきであり、「color」フィールドを直接使用します。
23. プログラミング時のトラブルを避けるために、クラスパスが指す場所で、それぞれの名前が 1 つのクラスのみに対応していることを確認してください。そうしないと、コンパイラが最初に同じ名前の別のクラスを見つけて、エラー メッセージを報告する可能性があります。クラス パスの問題が発生したと思われる場合は、クラス パスの各開始点で同じ名前の .class ファイルを検索してみてください。
24. Java 1.1 AWT でイベント「アダプター」を使用する場合、特にトラップに遭遇しやすくなります。アダプター メソッドがオーバーライドされ、スペル メソッドが特に特殊でない場合、最終的な結果は、既存のメソッドをオーバーライドするのではなく、新しいメソッドを追加することになります。ただし、これは完全に合法であるため、コンパイラやランタイム システムからエラー メッセージは表示されませんが、コードが正しく動作しないだけです。
25. 合理的な設計ソリューションを使用して、「疑似機能」を排除します。つまり、クラスのオブジェクトを 1 つだけ作成する必要がある場合は、事前にアプリケーションに限定せず、「そのうちの 1 つだけを生成する」というコメントを追加します。 「唯一の子」フォームにカプセル化することを検討してください。独自のオブジェクトの作成に使用されるメイン プログラムに散在するコードが多数ある場合は、このコードをカプセル化する創造的なソリューションを採用することを検討してください。
26. 「分析による麻痺」に注意してください。何はともあれ、プロジェクト全体の状況を事前に把握し、詳細を検討する必要があることを忘れないでください。全体的な状況を把握しているため、不明な要素をすぐに認識でき、詳細を検討するときに「行き詰まった論理」に陥るのを防ぐことができます。
27. 「時期尚早な最適化」に注意してください。最初に実行し、後で高速化することを考えますが、最適化する必要がある場合、およびコードの一部にパフォーマンスのボトルネックがあることが判明した場合にのみ最適化してください。ボトルネックを分析するために専用のツールを使用しない限り、おそらく時間を無駄にしていることになります。パフォーマンス向上の暗黙のコストは、コードの理解と保守が困難になることです。
28. コードを書く時間よりも、コードを読む時間の方がずっと長いということを覚えておいてください。明確な設計によりプログラムは理解しやすくなりますが、多くの場合、コメント、丁寧な説明、およびいくつかの例が非常に貴重です。それらは、あなた自身にとっても、あなたをフォローする人々にとっても、非常に重要です。まだこれに疑問がある場合は、オンラインの Java ドキュメントで有益な情報を見つけようとしてイライラすることを想像してみてください。そうすれば、納得できるかもしれません。
29. 優れた分析、設計、または実装を行ったと思う場合は、考え方の視点を少し変えてください。社外の人、必ずしも専門家ではなく、社内の他の部門の人々を招待してみてください。まったく新鮮な目であなたの仕事を見て、あなたが気づかなかった問題を彼らが見つけられるかどうかを確認してもらいます。この方法を採用すると、多くの場合、修正に最適な段階でいくつかの重要な問題を特定でき、製品のリリース後に問題解決に伴う金銭とエネルギーの損失を回避できます。
30. 優れたデザインは最大の利益をもたらします。つまり、特定の問題に対する最適な解決策を見つけるには、多くの場合、長い時間がかかります。しかし、一度適切な方法を見つければ、今後の仕事はずっと楽になり、何時間も、何日も、あるいは何か月も苦痛に耐える必要はなくなります。私たちの懸命な努力は、最大の報酬（たとえ計り知れないものであっても）をもたらします。苦労した分、最終的には素晴らしい設計図が得られ、成功したときのスリルも刺激的です。仕事を急いでやり遂げたいという誘惑に抵抗してください。多くの場合、努力する価値はありません。