enum とアノテーション

Effective Java 第 3 版の個人的メモ

1. 項目 34 int 定数の代わりに enum を使う
2. 項目 35 序数の代わりにインスタンスフィールドを使う
3. 項目 36 ビットフィールドの代わりに EnumSet を使う
4. 項目 37 序数インデックスの代わりに EnumMap を使う
5. 項目 38 拡張可能な enum をインタフェースで模倣する
6. 項目 39 命名パターンよりアノテーションを選ぶ
7. 項目 40 常に Override アノテーションを使う
8. 項目 41 型を定義するためにマーカーインタフェースを使う

1. 項目 34 int 定数の代わりに enum を使う

1.1. 結論

• int enumパターン(int定数)は使わないでおきましょう。
• enumを使いましょう。
  • 単に定数として使う。
  • 定数に対するメソッドが必要であれば、定数固有メソッド
  • 複数の定数に対して共通のメソッドが必要であれば、戦略enumパターン

1.2. int enumパターンの欠点

以下の欠点がある。

ジェネリクス

Effective Java 第 3 版の個人的メモ

1. 項目 26 原型を使わない
2. 項目 27 無検査警告を取り除く
3. 項目 28 配列よりリストを選ぶ
4. 項目 29 ジェネリック型を使う
5. 項目 30 ジェネリックメソッドを使う
6. 項目 31 API の柔軟性向上のために境界ワイルドカードを使う
7. 項目 32 ジェネリックと可変長引数を注意して組み合わせる
8. 項目 33 型安全な異種コンテナを検討する
9. 参考 URL

1. 項目 26 原型を使わない

• Java 1.4 までジェネリクスがなかった。
• Java 5 でジェネリクスが登場した。

1.1. 結論

ジェネリクスの型パラメータが指定できるときは必ず指定しましょう。

クラスとインタフェース

Effective Java 第 3 版の個人的メモ

1. 項目 15 クラスとメンバーへのアクセス可能性を最小限にする
2. 項目 16 public のクラスでは、public のフィールドではなく、アクセッサーメソッドを使う
3. 項目 17 可変性を最小限にする
4. 項目 18 継承よりコンポジションを選ぶ
5. 項目 19 継承のために設計および文書化する、でなければ継承を禁止する
6. 項目 20 抽象クラスよりインタフェースを選ぶ
7. 項目 21 将来のためにインタフェースを選ぶ
8. 項目 22 型を定義するためだけにインタフェースを使う
9. 項目 23 タグ付クラスよりクラス階層を選ぶ
10. 項目 24 非 static のメンバークラスより static のメンバークラスを選ぶ
11. 項目 25 ソースファイルを単一のトップレベルのクラスに限定する
12. 参考 URL

1. 項目 15 クラスとメンバーへのアクセス可能性を最小限にする

1.1. 結論

• 常にアクセス可能性をできる限り小さくするべき
• public のクラスは public のフィールドを持つべきではない
• public static final のフィールドが配列の場合、その配列の内部も不変であることを保証するべき

1.2. 常にアクセス可能性をできる限り小さくするべき

情報秘匿(カプセル化)をすると以下の利点が得られるから。

少しずつ便利だなぁと思ったものを追記していきます。

複数人でのドキュメント管理

結論

複数人でのドキュメント管理になると、このご時世 Git を使うのが基本かと思います。 (ファイルサーバなどは前のバージョンが管理しづらい。)

すべてのオブジェクトに共通のメソッド

Effective Java 第 3 版の個人的メモ

1. 項目 10 equals の override は一般契約（general contracts）に従うべし
2. 項目 11 equals をオーバーライドする場合は hashcode もオーバーライドせよ
3. 項目 12 常に toString をオーバーライドせよ
4. 項目 13 clone をオーバーライドするときは注意せよ
5. 項目 14 Comparable を実装することを考慮せよ

1. 項目 10 equals の override は一般契約（general contracts）に従うべし

1.1. どういう時にオーバーライドする必要があるのか？

クラスが単なるオブジェクトの同一性とは異なる論理的等価性という概念を持っていて、他のインスタンスと比較する必要があるとき

オブジェクトの生成と消滅

Effective Java 第 3 版の個人的メモ

1. 項目 1 コンストラクタの代わりに static ファクトリーメソッドを検討する
2. 項目 2 数多くのコンストラクタパラメータに直面した時にはビルダーパターンを検討する。
3. 項目 3 private のコンストラクタか enum 型でシングルトン特性を強制する
4. 項目 4 private のコンストラクタでインスタンス化不可能を強制する
5. 項目 5 資源を直接結び付けるよりも依存性注入を選ぶ
6. 項目 6 不必要なオブジェクトの生成を避ける
7. 項目 7 廃れたオブジェクト参照を取り除く
8. 項目 8 finalizer と cleaner の使用は避けるべし
9. 項目 9 try-finally よりも try-with-resources を使うべし

1. 項目 1 コンストラクタの代わりに static ファクトリーメソッドを検討する

1.1. 結論

コンストラクタの代わりに static ファクトリーメソッドを使用すると様々なメリットがある。 そのメリットが必要ない時はコンストラクタを使用すればよい。

AWS CodeBuild から Mattermost へ通知させる機会があったので、その方法についての備忘録として残しておきます。

AWS CodeBuild の環境変数 MattermostWebhookURL にMattermostのIncomming Webhook URLを保持しておきます。また、IAM から CodeBuild のロールに AmazonSSMReadOnlyAccessの権限を与えてください。

AWS CodeBuild と SonarCloud を連携させる機会があったので、その方法についての備忘録として残しておきます。

AWS CodeBuild の環境変数 SonarCloudAccessToken に SonarCloud のアクセストークンを保持しておきます。

SonarCloud のアクセストークンの発行は、SonarCloud のサイトで ユーザーアイコン > Settings > Personal access token から出来ます。

先日、Architecting on AWS に参加したので、参加メモを載せておきます。

クラウド繋がりということで、Cloud Native Tokyo 2019 で紹介されていたTrail Mapも載せておきます。

初めての技術系ブログです。

ご不明な点がありましたら、お気軽にコメント欄へ記入ください。

初回は「ドメイン X のサイトから、異なるドメイン Y の BASIC 認証つきのサイトにアクセスできるのか 」について検証した結果を書きたいと思います。 検証結果としては、