[Effective Java Distilled]Item 4は、プライベートな構造方法によって、インスタンス化できない性質を強化する
2850 ワード
Effective Java Distilledについて:
『Effective Java』という本を2回近く断続的に読みましたが、内容が深く、エンジニアリングコードの品質向上にも役立ちました.私はゆっくりと1つのシリーズを整理するつもりで、なぜEffective Java Distilledと命名するのか、本の精華をできるだけ整理して、復習して使うのに便利で、結局自分の記憶力もとても限られていて、多くのものはいつも忘れて、一言で言えば、この本に対するいくつかの読書ノートでしょう.文章の中の内容はきっと原文に忠実で、いくつかのItemsに対して、いくつかの内容を追加するかもしれませんが、追加した内容は私が明記します.同時に、このシリーズの文章が皆さんに役に立つことを望んでいます.質問やアドバイスがあれば、メッセージをお願いします.ありがとうございます.
この文書の概要:
クラスをインスタンス化する必要はありません注意事項
このItemは、すべてのItemの中で最もコンテンツが少ないかもしれません.しかし、日常的な符号化でよく使われるいくつかのテクニックもカバーされています.ツールクラスを作成するときに使用します.
インスタンス化する必要のないクラス
一言で言えば、静的ツールメソッドを提供するために完全に使用されるタイプであり、インスタンス化する必要はありません.JDKにはいくつかの典型がある.たとえばjava.util.Arrays,java.util.Colections,java.lang.Mathです.これらのクラスの宣言方法は、次のとおりです.
以上のコードフラグメントはすべてJDKソースから抜粋されています.これらはいずれもプライベート構造法を用いており,このプライベート構造法の内部には論理がないことが分かった.これは、コンパイラがタイプをコンパイルするときにデフォルトの非パラメトリックコンストラクションメソッドを生成しないようにするためです.つまり、クラスにコンストラクションメソッドが提供されていない場合、コンパイラはデフォルトのコンストラクションメソッドを生成します.コンパイラは、コンストラクション・メソッド(アクセス・レベルは任意)が提供されると、デフォルトのコンストラクション・メソッドを提供しません.
また、上記のMathクラスの宣言方式はCollectionsやArraysクラスとは少し異なり、Mathクラスの宣言にはfinalキーワードが使われていますが、このキーワードには特別な意味があるのでしょうか.『Thinking in Java』のReusing Classes章のThe final keyword小節では、finalキーワードの各シーンでの意味について説明しています.finalがclassを修飾するために使用される場合、classはサブクラスを持つことができないことを示します.finalに修飾されたタイプでは、布団類を書き直すことはできないので、すべての方法はfinalです.
したがって、本明細書で論じるこのシナリオでは、タイプに一意のプライベート構造方法が提供されている以上、このタイプは、サブクラスの構造方法が明示的または暗黙的に親を使用する非プライベート構造方法を必要とするため、サブクラスを所有できないことを意味する.したがって、このシーンではfinalを使用するか使用しないかで、発生する効果は同じです.
だから、なぜMathクラスの声明がfinalキーワードで修飾されているのか、ArraysとCollectionsにはないのか、誰もがコードの習慣や考え方が違うのではないかと思いますが...Mathクラスの作者はJoseph D.Darcyで、後の2つのクラスの2人の作者Joshua BlochとNeal Gafterで、彼らは面白い「Java Puzzzlers」を合わせています.同時にJoshua Bloch本人は『Effective Java』の作者である.
注意事項
タイプをインスタンス化できないように、このタイプを抽象クラスとして宣言するのは正しくありません.抽象クラスの本意はクラスに継承されるためであり,サブクラスを作成したインスタンスは抽象クラスの構造方法を呼び出すため,抽象クラス自体は間接的にインスタンス化される.
プライベート・コンストラクション・メソッドに加えて、Effective Java Item 4のコード・セグメントを参照する1行のコードをこのコンストラクション・メソッドに追加することもできます.
すなわち、断言クラス異常を投げ出すことによって、このタイプでプライベート構造メソッドが意図的に呼び出されることを防止することができる.同時に,この方法は反射に対してプライベート構造方法を呼び出すこともできる.
say no
.このテクニックは
Item3
,単例クラスの実装についても有用である.
『Effective Java』という本を2回近く断続的に読みましたが、内容が深く、エンジニアリングコードの品質向上にも役立ちました.私はゆっくりと1つのシリーズを整理するつもりで、なぜEffective Java Distilledと命名するのか、本の精華をできるだけ整理して、復習して使うのに便利で、結局自分の記憶力もとても限られていて、多くのものはいつも忘れて、一言で言えば、この本に対するいくつかの読書ノートでしょう.文章の中の内容はきっと原文に忠実で、いくつかのItemsに対して、いくつかの内容を追加するかもしれませんが、追加した内容は私が明記します.同時に、このシリーズの文章が皆さんに役に立つことを望んでいます.質問やアドバイスがあれば、メッセージをお願いします.ありがとうございます.
この文書の概要:
クラスをインスタンス化する必要はありません注意事項
このItemは、すべてのItemの中で最もコンテンツが少ないかもしれません.しかし、日常的な符号化でよく使われるいくつかのテクニックもカバーされています.ツールクラスを作成するときに使用します.
インスタンス化する必要のないクラス
一言で言えば、静的ツールメソッドを提供するために完全に使用されるタイプであり、インスタンス化する必要はありません.JDKにはいくつかの典型がある.たとえばjava.util.Arrays,java.util.Colections,java.lang.Mathです.これらのクラスの宣言方法は、次のとおりです.
public class Arrays {
// Suppresses default constructor, ensuring non-instantiability.
private Arrays() {
}
…
}
public class Collections {
// Suppresses default constructor, ensuring non-instantiability.
private Collections() {
}
…
}
public final class Math {
/**
* Don't let anyone instantiate this class.
*/
private Math() {}
…
}
以上のコードフラグメントはすべてJDKソースから抜粋されています.これらはいずれもプライベート構造法を用いており,このプライベート構造法の内部には論理がないことが分かった.これは、コンパイラがタイプをコンパイルするときにデフォルトの非パラメトリックコンストラクションメソッドを生成しないようにするためです.つまり、クラスにコンストラクションメソッドが提供されていない場合、コンパイラはデフォルトのコンストラクションメソッドを生成します.コンパイラは、コンストラクション・メソッド(アクセス・レベルは任意)が提供されると、デフォルトのコンストラクション・メソッドを提供しません.
また、上記のMathクラスの宣言方式はCollectionsやArraysクラスとは少し異なり、Mathクラスの宣言にはfinalキーワードが使われていますが、このキーワードには特別な意味があるのでしょうか.『Thinking in Java』のReusing Classes章のThe final keyword小節では、finalキーワードの各シーンでの意味について説明しています.finalがclassを修飾するために使用される場合、classはサブクラスを持つことができないことを示します.finalに修飾されたタイプでは、布団類を書き直すことはできないので、すべての方法はfinalです.
したがって、本明細書で論じるこのシナリオでは、タイプに一意のプライベート構造方法が提供されている以上、このタイプは、サブクラスの構造方法が明示的または暗黙的に親を使用する非プライベート構造方法を必要とするため、サブクラスを所有できないことを意味する.したがって、このシーンではfinalを使用するか使用しないかで、発生する効果は同じです.
だから、なぜMathクラスの声明がfinalキーワードで修飾されているのか、ArraysとCollectionsにはないのか、誰もがコードの習慣や考え方が違うのではないかと思いますが...Mathクラスの作者はJoseph D.Darcyで、後の2つのクラスの2人の作者Joshua BlochとNeal Gafterで、彼らは面白い「Java Puzzzlers」を合わせています.同時にJoshua Bloch本人は『Effective Java』の作者である.
注意事項
タイプをインスタンス化できないように、このタイプを抽象クラスとして宣言するのは正しくありません.抽象クラスの本意はクラスに継承されるためであり,サブクラスを作成したインスタンスは抽象クラスの構造方法を呼び出すため,抽象クラス自体は間接的にインスタンス化される.
プライベート・コンストラクション・メソッドに加えて、Effective Java Item 4のコード・セグメントを参照する1行のコードをこのコンストラクション・メソッドに追加することもできます.
// Noninstantiable utility class
public class UtilityClass {
// Suppress default constructor for noninstantiability
private UtilityClass() {
throw new AssertionError();
}
... // Remainder omitted
}
すなわち、断言クラス異常を投げ出すことによって、このタイプでプライベート構造メソッドが意図的に呼び出されることを防止することができる.同時に,この方法は反射に対してプライベート構造方法を呼び出すこともできる.
say no
.このテクニックは
Item3
,単例クラスの実装についても有用である.