The King's Museum

ソフトウェアエンジニアのブログ。

Java

【Effective Java】項目17:継承のための設計および文書化する、でなければ継承を禁止する

継承させることを意図するクラスを作成するときは、継承のために設計し、文書化する。 そうでない場合には継承させないようにする。 自己利用(self-use)の文書化 クラスはオーバーライド可能なメソッドの自己利用を文書化する必要がある。 個々の public …

【Effective Java】項目16:継承よりコンポジションを選ぶ

継承よりもコンポジションを選ぶべきである。 継承の利用 継承はコードを再利用するための一般的な手法だが、常に最適なものとは限らない。 継承を安全に利用することができるのは以下の場合である。 スーパークラスもサブクラスも特定のパッケージ配下にあ…

【Effective Java】項目15:可変性を最小限にする

クラスの可変性は最小限にするべきである。 不変クラス 不変クラスとは、そのインスタンスを変更できないという性質をもつクラス。 インスタンスが生成された時点ですべての情報を持っていて、インスタンスの生存期間中はそれらの情報が変化しないことが保証…

【Effective Java】項目14:public のクラスでは、public のフィールドではなく、アクセッサーメソッドを使う

クラスがパッケージの外からアクセス可能ならば(public ならば)、ゲッターとセッターを提供するべき。 public なクラスがデータフィールドを公開すると、その内部的な表現を永久に変更できなくなる。 一方、クラスがパッケージプライベート・private のネ…

【Effective Java】項目13:クラスとメンバーへのアクセス可能性を最小限にする

ここから第4章「クラスとインターフェス」。 クラスとインタフェースは Java の中心に位置し、抽象化の基本となる要素。 この章では、クラス・インタフェースが利用可能で、頑強で、柔軟になるような指針を議論する。 最初の項目は情報隠蔽・カプセル化に関…

【Effective Java】項目12:Comparable の実装を検討する

Comparable インタフェースの compareTo を実装するとインスタンスが順序を持つようになる。 第3章で議論した他のメソッドとは異なり、compareTo メソッドは Object では宣言されていない。 ただし、Comparable を実装すると、多くの一般的なアルゴリズムや…

【Effective Java】項目11:clone を注意してオーバーライドする

本項目では正しく機能する clone メソッドを、どのように、いつ実装するかを議論する。 Cloneable インタフェース Cloneable インタフェースはオブジェクトが複製を許可していることを示す。 ただし、Cloneable インタフェース自体は空のインタフェースであ…

【Effective Java】項目10:toString を常にオーバーライドする

toString をオーバライドして意味のある文字列を返すようにする。 toString のオーバーライド java.lang.Object は toString() を実装しているが、ユーザーにとってよい情報を返すわけではない。 Object obj = new Object(); // 「クラス名@ハッシュコード値…

【Effective Java】項目9:equals をオーバーライドする時は、常に hashCode をオーバーライドする

equals をオーバーライドする時は、hashCode メソッドを必ずオーバーライドしなければならない。 オーバーライドしない場合、Object.hashCode の一般契約を破ることになり、HashMap、HashSet、HashTable など、hashCode の一般契約に基づくコレクションが適…

【Effective Java】項目8:equals をオーバーライドするときは一般契約に従う

第3章『すべてのオブジェクトに共通のメソッド』に入る。 第3章は、Object.equals()、Object.hashCode()、Object.toString()、Object.clone() について、いつ、どのようにオーバーライドするかを説明する。 finalize も同様のものだが、すでに項目7で議論…

【Effective Java】項目7:ファイナライザを避ける

Java のファイナライザは予想不可能で、危険であり、一般的には使う必要はない。 C++ プログラマは Java のファイナライザを C++ のデストラクタと対応付けて考えてしまいがちだが、それは大きな間違いである。 C++ のデストラクタはコンストラクタに対応す…

【Effective Java】項目6:廃れたオブジェクト参照を取り除く

メモリリークを回避するため廃れたオブジェクトの参照は取り除かなければならない。 C や C++ から、ガーベージコレクション(GC)を持つ言語に切り替えると、メモリ管理について考える必要がないように感じることがあるが、それは間違いだ。 次のスタック実…

【Effective Java】項目5:不必要なオブジェクトの生成を避ける

機能的に同じオブジェクトを、必要になるごとに再生成するのは避ける。 よくない例 極端にだめな例としては以下の様なコードがある。 // だめな例 String s = new String("stringee"); "stringee" 自身が String オブジェクトであり、String コンストラクタ…

【Effective Java】項目4:private のコンストラクタでインスタンス化不可能を強制する

static のメソッドと static なフィールドだけからなるクラスを書く場合は private コンストラクタでインスタンス化不可能をクライアントに強制するべきである。 static ユティリティクラス そのようなクラスは悪く評価されていることもあるが、java.lang.Ma…

【Effective Java】項目3:private のコンストラクタか enum 型でシングルトン特性を強制する

シングルトンは、手短にいえば厳密に一度しかインスタンスが生成されないクラス。 ただし、クラスをシングルトンにするとデメリットも多々あるため本当に必要な場合のみ行うこと。 伝統的なシングルトン実装 Java の リリース 1.5 より前はシングルトンを実…

【Effective Java】項目2:数多くのコンストラクタパラメータに直面した時にはビルダーを検討する

多くのオプションパラメータを持つオブジェクトを生成する場合はビルダーパターンを利用することを検討する。 テレスコーピングパターン 多くのオプションパラメータが存在するとき、伝統的にはテレスコーピングコンストラクタと呼ばれるパターンが利用され…

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

追記:2018年2月16日 Effective Java 3rd Edition を踏まえて内容をアップデートした記事を書きました。 こちらをご覧ください。 www.thekingsmuseum.info オブジェクトを生成するため、public コンストラクタの代わりに static ファクトリーメソッドを提供…

【Effective Java】第1章:はじめに

追記:2018年1月21日 Effective Java 3rd Edition を踏まえて内容をアップデートした記事を書きました。 こちらをご覧ください。 www.thekingsmuseum.info 第一章は前置き話がメイン。 第1章:はじめに この本の特徴は多くのデザインパターンとイディオムを…

(c) The King's Museum