【effective java】30~37.列挙と注釈
第30条:int定数a)int定数の代わりにenumを用いる欠点
(1)appleをorangeに転送する方法では,エラーは発生しない(2)==オペレータでappleをorangeと比較し,エラーは発生しない(3)int列挙はコンパイル時定数であり,クライアントにコンパイルされ,列挙定数に関連するintが変化するとクライアントは再コンパイルしなければならず,再コンパイルがなければプログラムは実行できるが,動作は決定する.例えばAPPLE_FUJI関連の定数は0ではなく3である.(4)int列挙定数を印刷可能な文字列に翻訳するのが面倒(5)1つのグループのすべてのint列挙定数を遍歴してint列挙グループの大きさを得るには信頼できる方法がなく,APPLEの定数がどれだけあるかを知りたければ,int列挙定数が位置するコードを見る以外に方法はない,APPLE_を観察することに頼る.接頭辞は何個あって、信頼できません
b)列挙:タイプ安全性、使い勝手
第31条:シーケンスシーケンス番号ordinal()の代わりにインスタンスドメインを使用し、多くの人はordinalという方法を使用する必要がなく、これを列挙の値とすることもできない.列挙された一意の値を自分で書いた値でマークするには
第32条:ビットドメインEnumSetの下位層の代わりにEnumSetを用いることはビットベクトルで実現される.
応用シーン:いくつかの仕事の中で、例えば医者、カスタマーサービスは、すべてのスタッフが毎日いるのではなく、一人一人が働く時間が違います.例えば、張三は月曜日と水曜日かもしれません.李四は木曜日と土曜日かもしれません.一人一人が働く時間を与えて、私たちはいくつかの質問に答える必要があります.例えば、いつ一人も来ませんか.いつか少なくとも一人が来ますか?少なくとも二人が来る日はいつですか.会議のために全員が来る日はいつですか.月曜日と火曜日に来る人は誰ですか.コード実装:https://gitee.com/charjay/effective.git
第33条:シーケンスインデックスの代わりにEnumMapを使用するEnumMapが、シーケンスインデックスを通過する配列に匹敵する速度で動作するのは、EnumMapが内部でこの配列を使用しているためである
適用シーン:固体、液体、ガス間の変換コード実装:https://gitee.com/charjay/effective.git
第34条:インタフェースで伸縮可能な列挙列挙タイプをシミュレートすることは拡張不可能であるが、インタフェースタイプは拡張可能である.インタフェースを使用すると、伸縮性のある列挙をシミュレートできます.インタフェースシミュレーションの伸縮可能な列挙の不足:1つの列挙から別の列挙に継承することはできません.そのため、共通の機能の中には、各列挙クラスで重複するものもあります.共通の機能が多い場合は、コードのコピーを回避するために、補助クラスまたは静的補助メソッドにカプセル化します.コード実装:https://gitee.com/charjay/effective.git
第35条:注釈はネーミングモードより優先する例えば:初期JUnitテストフレームワークはユーザーが必ずtestをテスト方法名の先頭とすることを要求して、この時ユーザーのテスト方法名がtestでないと報告が間違って、この時注釈は出てきて、ただ1つの@Test注釈をプラスして、方法名に関わらず
第36条:オーバークラス宣言を上書きするためにOverride注釈を使用したいメソッド宣言ごとにOverride注釈を使用する場合、コンパイラはあなたのために多くのエラーを防止することができます.具体的なクラスでは、抽象メソッド宣言を上書きしたと確信するメソッドを表記する必要はありません(表記も可能です).
第37条:タグインタフェースでタイプを定義本節は主にタグ注釈とタグインタフェースタグインタフェースを比較する:インタフェースにメソッド宣言が含まれていないことを指し、クラスが何らかの属性を持つインタフェースタグ注釈を実現したことを示すだけである:タグ注釈は特殊なタイプの注釈であり、メンバーは含まれていない.タグ注釈の唯一の目的はタグ宣言であるため,この注釈が注釈として存在する理由は十分である.タグ注記が存在するかどうかを決定する最善の方法は、AnnotationPresent()メソッドを使用することであり、このメソッドはAnnotatedElementインタフェースによって定義される.
タグ注記はタグインタフェースよりも使用頻度が高いので、どこが優れているのか見てみましょう.1.タグ注記はデフォルトの方法で1つ以上の注釈タイプ要素を追加し、実用的な注釈タイプにより多くの情報を追加することができます.2.タグ注記はより大きな注釈メカニズムの一部です.これは、プログラミング要素の1つとして注釈をサポートするフレームワークにおいても一貫性があることを意味します.
タグ注釈が削除インタフェースを置き換えることができるようになったとしても、タグインタフェースはタグ注釈に比べて依然としてその利点がある.1.タグインタフェース定義のタイプは、タグクラスのインスタンスによって実現される.タグ注釈はこのようなタイプを定義していません.このタイプでは、タグ注釈を使用して実行時にキャプチャするエラーをコンパイル時にキャプチャできます.2.タグインタフェースはより正確にロックできます.
つまり、タグインタフェースとタグ注釈はそれぞれ役に立ちます.新しい方法では関連付けられないタイプを定義するには、タグインタフェースが最善の選択です.クラスやインタフェースではなくプログラム要素をタグするには、将来タグにより多くの情報を追加する可能性があることを考慮したり、タグが注釈タイプを広く使用しているフレームワークに適していることを考慮したりします.マーク注記は正しい選択です
public static final int APPLE_FUJI = 0;
public static final int APPLE_PIPPIN = 1;
public static final int APPLE_GRANNY_SMITH = 2;
public static final int ORANGE_NAVEL = 0;
public static final int ORANGE_TEMPLE = 1;
public static final int ORANGE_BLOOD = 2;
(1)appleをorangeに転送する方法では,エラーは発生しない(2)==オペレータでappleをorangeと比較し,エラーは発生しない(3)int列挙はコンパイル時定数であり,クライアントにコンパイルされ,列挙定数に関連するintが変化するとクライアントは再コンパイルしなければならず,再コンパイルがなければプログラムは実行できるが,動作は決定する.例えばAPPLE_FUJI関連の定数は0ではなく3である.(4)int列挙定数を印刷可能な文字列に翻訳するのが面倒(5)1つのグループのすべてのint列挙定数を遍歴してint列挙グループの大きさを得るには信頼できる方法がなく,APPLEの定数がどれだけあるかを知りたければ,int列挙定数が位置するコードを見る以外に方法はない,APPLE_を観察することに頼る.接頭辞は何個あって、信頼できません
b)列挙:タイプ安全性、使い勝手
public enum Apple {FUJI, PIPPIN, GRANNY_SMITH}
public enum Orange {NAVEL, TEMPLE, BLOOD}
第31条:シーケンスシーケンス番号ordinal()の代わりにインスタンスドメインを使用し、多くの人はordinalという方法を使用する必要がなく、これを列挙の値とすることもできない.列挙された一意の値を自分で書いた値でマークするには
第32条:ビットドメインEnumSetの下位層の代わりにEnumSetを用いることはビットベクトルで実現される.
応用シーン:いくつかの仕事の中で、例えば医者、カスタマーサービスは、すべてのスタッフが毎日いるのではなく、一人一人が働く時間が違います.例えば、張三は月曜日と水曜日かもしれません.李四は木曜日と土曜日かもしれません.一人一人が働く時間を与えて、私たちはいくつかの質問に答える必要があります.例えば、いつ一人も来ませんか.いつか少なくとも一人が来ますか?少なくとも二人が来る日はいつですか.会議のために全員が来る日はいつですか.月曜日と火曜日に来る人は誰ですか.コード実装:https://gitee.com/charjay/effective.git
第33条:シーケンスインデックスの代わりにEnumMapを使用するEnumMapが、シーケンスインデックスを通過する配列に匹敵する速度で動作するのは、EnumMapが内部でこの配列を使用しているためである
適用シーン:固体、液体、ガス間の変換コード実装:https://gitee.com/charjay/effective.git
第34条:インタフェースで伸縮可能な列挙列挙タイプをシミュレートすることは拡張不可能であるが、インタフェースタイプは拡張可能である.インタフェースを使用すると、伸縮性のある列挙をシミュレートできます.インタフェースシミュレーションの伸縮可能な列挙の不足:1つの列挙から別の列挙に継承することはできません.そのため、共通の機能の中には、各列挙クラスで重複するものもあります.共通の機能が多い場合は、コードのコピーを回避するために、補助クラスまたは静的補助メソッドにカプセル化します.コード実装:https://gitee.com/charjay/effective.git
第35条:注釈はネーミングモードより優先する例えば:初期JUnitテストフレームワークはユーザーが必ずtestをテスト方法名の先頭とすることを要求して、この時ユーザーのテスト方法名がtestでないと報告が間違って、この時注釈は出てきて、ただ1つの@Test注釈をプラスして、方法名に関わらず
第36条:オーバークラス宣言を上書きするためにOverride注釈を使用したいメソッド宣言ごとにOverride注釈を使用する場合、コンパイラはあなたのために多くのエラーを防止することができます.具体的なクラスでは、抽象メソッド宣言を上書きしたと確信するメソッドを表記する必要はありません(表記も可能です).
第37条:タグインタフェースでタイプを定義本節は主にタグ注釈とタグインタフェースタグインタフェースを比較する:インタフェースにメソッド宣言が含まれていないことを指し、クラスが何らかの属性を持つインタフェースタグ注釈を実現したことを示すだけである:タグ注釈は特殊なタイプの注釈であり、メンバーは含まれていない.タグ注釈の唯一の目的はタグ宣言であるため,この注釈が注釈として存在する理由は十分である.タグ注記が存在するかどうかを決定する最善の方法は、AnnotationPresent()メソッドを使用することであり、このメソッドはAnnotatedElementインタフェースによって定義される.
タグ注記はタグインタフェースよりも使用頻度が高いので、どこが優れているのか見てみましょう.1.タグ注記はデフォルトの方法で1つ以上の注釈タイプ要素を追加し、実用的な注釈タイプにより多くの情報を追加することができます.2.タグ注記はより大きな注釈メカニズムの一部です.これは、プログラミング要素の1つとして注釈をサポートするフレームワークにおいても一貫性があることを意味します.
タグ注釈が削除インタフェースを置き換えることができるようになったとしても、タグインタフェースはタグ注釈に比べて依然としてその利点がある.1.タグインタフェース定義のタイプは、タグクラスのインスタンスによって実現される.タグ注釈はこのようなタイプを定義していません.このタイプでは、タグ注釈を使用して実行時にキャプチャするエラーをコンパイル時にキャプチャできます.2.タグインタフェースはより正確にロックできます.
つまり、タグインタフェースとタグ注釈はそれぞれ役に立ちます.新しい方法では関連付けられないタイプを定義するには、タグインタフェースが最善の選択です.クラスやインタフェースではなくプログラム要素をタグするには、将来タグにより多くの情報を追加する可能性があることを考慮したり、タグが注釈タイプを広く使用しているフレームワークに適していることを考慮したりします.マーク注記は正しい選択です