プログラミング一般

Effective Java 第 3 版の個人的メモ

1. 項目 57 ローカル変数のスコープを最小限にする
2. 項目 58 従来の for ループより for-each ループを選ぶ
3. 項目 59 ライブラリを知り、ライブラリを使う
4. 項目 60 正確な答えが必要ならば、float と double を避ける
5. 項目 61 ボクシングされたプリミティブ型（boxed primitive）より、プリミティブ型（primitive）を選択すべし
6. 項目 62 他の型が適切な場所では、文字列を避ける
7. 項目 63 文字列結合のパフォーマンスに用心する
8. 項目 64 インタフェースでオブジェクトを参照する
9. 項目 65 リフレクションよりもインタフェースを選ぶ
10. 項目 66 ネイティブメソッドを注意して使う
11. 項目 67 注意して最適化する
12. 項目 68 一般的に受け入れられている命名規約を守る
13. 参考URL

1. 項目 57 ローカル変数のスコープを最小限にする

1.1. 結論

• ローカル変数は初めて使用される時に宣言しましょう
  • かなり前段階で宣言されていると、その時点から変更されているかを確認する必要があるから
• （ほとんど）全てのローカル変数の宣言時には初期化しましょう
  • 初期化するための情報がない段階で、宣言すべきではないから
• メソッドを小さくして焦点をはっきりさせましょう
  • 1つのメソッド内で2つの処理があれば、1つ目の処理用のローカル変数が2つ目の処理にも使われているかもしれないので、これを防ぐために 1メソッド:1処理 としましょう。

1.2. サンプル

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// 良い例
for (Element e : c) {
  doSomething(e);
}

// 悪い例
Iterator<Element> i = c.iterator();
While (i.hasNext()) {
  doSomething(i.next());
}
...
Iterator<Element> i2 = c2.iterator();
While (i.hasNext()) { // バグ(iではなく、i2が正しい。)
  doSomething(i2.next());
}

1.3. ポイント

• 使用される直前に、ローカル変数を初期化して宣言しましょう
• 1メソッド:1処理としましょう

備考：while文ではなくfor文を好んで使いましょう。

メソッド

Effective Java 第 3 版の個人的メモ

1. 項目 49 パラメータの正当性を検査する
2. 項目 50 必要な場合、防御的にコピーする
3. 項目 51 メソッドのシグネチャを注意深く設計する
4. 項目 52 オーバーロードを注意して使う
5. 項目 53 可変長引数を注意して使う
6. 項目 54 null ではなく、空コレクションか空配列を返す
7. 項目 55 オプショナルを注意して返す
8. 項目 56 すべての公開 API 要素に対してドキュメントコメントを書く
9. 参考URL

1. 項目 49 パラメータの正当性を検査する

1.1. 結論

• 入力値のチェックをしましょう
• Javadocに入力値の説明と例外の説明は記入しましょう

1.2. 良い例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

	/**
	 * 値が(this mod m)であるBigIntegerを返します。
	 * このメソッドは、remainderメソッドとは異なり、
   * 常に負でないBigIntegerを返します。
	 * 
	 * @param m 正でなければならない
	 * @return this mod m.
	 * @throws ArithmetricException m <= 0の場合.
	 */
	public BigInteger mod(BigInteger m) {
		if(m.signum() <= 0) {
			throw new ArithmeticException("Modulus <= 0: " + m);
		}
		// 計算を行う
	}

最初に入力値チェックをすることで、以下を防げる。

ラムダ式とストリーム

Effective Java 第 3 版の個人的メモ

1. 項目 42 匿名クラスよりもラムダ式を選ぶ
2. 項目 43 ラムダよりもメソッド参照を選ぶ
3. 項目 44 標準の関数型インタフェースを使う
4. 項目 45 ストリームを注意して使う
5. 項目 46 ストリームで副作用のない関数を選ぶ
6. 項目 47 戻り値型として Stream よりも Collection を選ぶ
7. 項目 48 ストリームを並列化するときは注意を払う
8. 参考 URL

Effective Java 3rd 勉強会(11/29)

日時: 2019/11/29 14:00-14:45 参加者(敬称略): 則兼、岩崎、倉元
以下、内容。

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の権限を与えてください。