スッキリわかる Java入門 - 版の履歴

Y: /* 第１３章：多態性、多様性 */

2019-05-08T02:32:13Z

第１３章：多態性、多様性

← 古い版		2019年5月8日 (水) 11:32時点における版
301行目:		301行目:
	* 常々、正しい継承関係を JVM に教えながら部品作りを進めることが、オブジェクト指向の真髄を最大限に利用してとても効率的なプログラミングをするコツ		* 常々、正しい継承関係を JVM に教えながら部品作りを進めることが、オブジェクト指向の真髄を最大限に利用してとても効率的なプログラミングをするコツ
	* とりあえず、'''十把一絡げで扱いたいグループがある場合'''そのグループ内のインスタンスたちは共通の親クラスから extends されている必要がある		* とりあえず、'''十把一絡げで扱いたいグループがある場合'''そのグループ内のインスタンスたちは共通の親クラスから extends されている必要がある
	* '''オブジェクト指向プログラミングとは'''~~、人が世界を認識（カテゴリー・階層に分けて整理、擬人化など）しているその認識を忠実に~~ JVM にアップロードして（パラレルワールドを創造して）マシンに扱わせようという試み		* '''オブジェクト指向プログラミングとは'''、人が世界を認識（カテゴリー/階層に分けて整理、擬人化など）しているその認識を忠実に JVM にアップロードして（パラレルワールドを創造して）マシンに扱わせようという試み
	* 整理整頓が大好きで得意な人は、オブジェクト指向プログラミングに向いている		* 整理整頓が大好きで得意な人は、オブジェクト指向プログラミングに向いている

Y: /* 第６章 */

2019-05-08T02:11:38Z

第６章

← 古い版		2019年5月8日 (水) 11:11時点における版
99行目:		99行目:
	* '''java.langパッケージ'''は利用頻度がとても多いので import文なしに自動的にインポートされる		* '''java.langパッケージ'''は利用頻度がとても多いので import文なしに自動的にインポートされる
	* '''APIリファレンス'''を把握する必要がある。パッケージ名 → クラス名 → クラスの詳細という手順で調べる		* '''APIリファレンス'''を把握する必要がある。パッケージ名 → クラス名 → クラスの詳細という手順で調べる
	* ただし、80:~~20の法則があるので良書やポケットリファレンスを利用して利用頻度の高いものから重点的に暗記した方が良いだろう~~		* ただし、80:20の法則があるので'''良書やポケットリファレンスを利用して利用頻度の高いものから重点的に暗記した方が良い'''だろう
	* JVM はクラスローダにクラスファイルを指定して必要なクラスファイルを随時読み込んでいく		* JVM はクラスローダにクラスファイルを指定して必要なクラスファイルを随時読み込んでいく
	* クラスローダは部品と部品を結びつけるオブジェクト指向ならではの存在		* クラスローダは部品と部品を結びつけるオブジェクト指向ならではの存在

Y: /* 第５章 */

2019-05-08T02:07:04Z

第５章

← 古い版		2019年5月8日 (水) 11:07時点における版
64行目:		64行目:
	* コードを部品化できるおかげで修正が楽、再利用が可能、といった大きなメリット		* コードを部品化できるおかげで修正が楽、再利用が可能、といった大きなメリット
	* プログラムは必ず mainメソッドから処理される		* プログラムは必ず mainメソッドから処理される
	* ~~メソッドに渡す値のことを「実引数」、受け取る変数のことを「仮引数」と呼ぶ~~		* メソッドに渡す値のことを「実引数」、メソッドから受け取る変数のことを「仮引数」と呼ぶ
	* ローカル変数は基本的にそれが利用されるメソッド内だけで有効		* ローカル変数は基本的にそれが利用されるメソッド内だけで有効
	* return文は値を返すだけでなく、メソッドの終了も行う		* return文は値を返すだけでなく、メソッドの終了も行う

Y: /* 第１６章・付録 */

2019-02-21T01:52:38Z

第１６章・付録

← 古い版		2019年2月21日 (木) 10:52時点における版
370行目:		370行目:
	==第１６章・付録==		==第１６章・付録==
	* 他にも Java では、ファイルの読み書き、インターネットアクセス、データベース操作、ウィンドウアプリケーション開発、スマホアプリケーション開発、* Webアプリケーション開発ができる		* 他にも Java では、ファイルの読み書き、インターネットアクセス、データベース操作、ウィンドウアプリケーション開発、スマホアプリケーション開発、* Webアプリケーション開発ができる
	* ~~誰もが通る道を可能な限り効率よく通り過ぎ、課題やエラーを素早く解決できるプログラマであれたら理想的~~		* 誰もが通る道を'''可能な限り効率よく通り過ぎ、課題やエラーを素早く解決'''できるプログラマであれたら理想的
	* ~~技術の上達のためには沢山のエラーたちに出会い、試行錯誤で解決し、必勝セオリーの引き出しを１つでも多く増やしていくことが不可欠~~		* 技術の上達のためには沢山のエラーたちに出会い、試行錯誤で解決し、'''必勝セオリーの引き出しを１つでも多く増やしていく'''ことが不可欠
	* ~~エラーを素早く解決するコツ１：新しい課題やエラーに直面している時こそ、自分が最も成長している時~~		* '''エラーを素早く解決するコツ１'''：新しい課題やエラーに直面している時こそ、自分が最も成長している時
	* ~~コツ２：エラーメッセージをしっかり読む。意味不明でも飛ばさない~~		* '''コツ２'''：エラーメッセージをしっかり読む。意味不明でも飛ばさない
	* ~~コツ３：原因を理解した上で修正する。なぜ今回のエラーが発生したのかを消化してから次に進む~~		* '''コツ３'''：原因を理解した上で修正する。なぜ今回のエラーが発生したのかを消化してから次に進む
	* ~~コンパイルエラーは上から１つずつ着実に修正していく。最初のエラーが原因で２つ目のエラーが誘発されている可能性もあるから~~		* '''コンパイルエラーは上から１つずつ着実に修正'''していく。最初のエラーが原因で２つ目のエラーが誘発されている可能性もあるから
	* プログラム実行中のエラーはスタックトレースを読みながら修正する。標準API のメソッドにバグがあるとは考えずらい。自分が開発したメソッドからの呼び出しなどにバグがある可能性の方が高い		* プログラム実行中のエラーはスタックトレースを読みながら修正する。'''標準API のメソッドにバグがあるとは考えずらい'''。自分が開発したメソッドからの呼び出しなどにバグがある可能性の方が高い
	* 標準API メソッドの直後に表示されている自分で開発したファイルのエラー該当行が最も怪しむべき箇所		* 標準API メソッドの直後に表示されている自分で開発したファイルのエラー該当行が最も怪しむべき箇所
	* ~~エラーメッセージの原因は『入門』p644 が参考になる~~		* エラーメッセージの'''原因は『入門』p644 が参考'''になる

Y: /* 第１５章：例外 */

2019-02-21T01:51:20Z

第１５章：例外

Y: /* （第３部）第１４章： */

2019-02-21T01:47:48Z

（第３部）第１４章：

← 古い版		2019年2月21日 (木) 10:47時点における版
305行目:		305行目:

	==（第３部）第１４章：==		==（第３部）第１４章：==
	* ~~ここまで学び終えた私たちは、Java の基本的な文法をほぼマスターしています~~		* ここまで学び終えた私たちは、'''Java の基本的な文法をほぼマスター'''しています
	* つまり、基本文法やオブジェクト指向を駆使して作成されている JavaAPI についてもとりあえず理解できる状態		* つまり、基本文法やオブジェクト指向を駆使して作成されている JavaAPI についてもとりあえず理解できる状態
	* ~~ただ、APIリファレンスの内容や書き方は初学者にとって優しいものではない~~		* ただ、APIリファレンスの内容や書き方は'''初学者にとって優しいものではない'''
	* Java ~~で日付を扱うときは基本的に最も利用されている「Date型」を利用する。java~~.util.Dateクラス		* Java で日付を扱うときは基本的に最も利用されている'''「Date型」を利用'''する。java.util.Dateクラス
	* Calendar を利用して「月」情報を取得・設定する場合は「1~12」ではなく「0~11」で指定する		* Calendar を利用して「月」情報を取得・設定する場合は「1~12」ではなく「0~11」で指定する
	* 独自に日時の書式を指定したいのであれば java.text.SimpleDateFormatクラスを利用する		* 独自に日時の書式を指定したいのであれば java.text.SimpleDateFormatクラスを利用する
	* Javaは日付の取り扱いが少し苦手だった。ゆえに、Java8以降からは新しい日付API が追加された		* Javaは日付の取り扱いが少し苦手だった。ゆえに、Java8以降からは新しい日付API が追加された
	* ~~全てのクラスの先祖は「Objectクラス」。Objectクラスには「equals~~()」と「toString()」が定義してある		* '''全てのクラスの先祖は「Objectクラス」'''。Objectクラスには「equals()」と「toString()」が定義してある
	* Objectクラスは全てのクラスの先祖なので「全てのクラス is-a Objectクラス」と言える。つまり、どのクラスもざっくり「Objectクラス」として扱える		* Objectクラスは全てのクラスの先祖なので「全てのクラス is-a Objectクラス」と言える。つまり、どのクラスもざっくり「Objectクラス」として扱える
	* ~~ゆえに、Object型にはどんなインスタンスも割り当てられるし、引数に Object型を指定すればどんな型でも渡せるメソッドが作れる~~		* ゆえに、Object型にはどんなインスタンスも割り当てられるし、'''引数に Object型を指定すれば'''どんな型でも渡せるメソッドが作れる
	* さらに大元の「Objectクラス」で equals と toString が定義されているお陰で、作成したどのクラスでも常に同じ方法で内容を比較したり文字列表示できる		* さらに大元の「Objectクラス」で equals と toString が定義されているお陰で、作成したどのクラスでも常に同じ方法で内容を比較したり文字列表示できる
	* toString()~~メソッドをオーバーライドしておくことで、簡単にインスタンス情報を確認できる。『入門』p547~~		* toString()メソッドをオーバーライドしておくことで、'''簡単にインスタンス情報を確認'''できる。『入門』p547
	* 等値 → メモリアドレスまで一緒（完全に同一の存在）。等価 → メモリアドレスは違うけど内容が一緒		* 等値 → メモリアドレスまで一緒（完全に同一の存在）。等価 → メモリアドレスは違うけど内容が一緒
	* 「==」は等値かどうかを評価する。「.equals」は等価かどうかを評価する		* 「==」は等値かどうかを評価する。「.equals」は等価かどうかを評価する
	* Objectクラスから継承される equals()メソッドはおおむね「等値なら true」になっている。ゆえに、開発者は状況に合わせてオーバーライドする必要がある		* Objectクラスから継承される equals()メソッドはおおむね「等値なら true」になっている。ゆえに、開発者は状況に合わせてオーバーライドする必要がある
	* とりあえず、新しくクラス（部品）を作るとき、toString() と equals() ~~をオーバーライドしてカスタマイズする必要性がないか検討する~~		* とりあえず、新しくクラス（部品）を作るとき、toString() と equals() をオーバーライドしてカスタマイズする'''必要性がないか検討'''する
	* ~~ラッパークラス：基本データ型それぞれ（int~~, double, char, boolean など）に対応させて準備されているクラス		* '''ラッパークラス'''：基本データ型それぞれ（int, double, char, boolean など）に対応させて準備されているクラス
	* ~~ラッパークラスでは、その基本データ型に関する便利なメソッドが提供されている~~		* ラッパークラスでは、その基本データ型に関する'''便利なメソッドが提供'''されている
	* 例えば、Integerクラスには「parseInt() - 文字列の数字を int型に変換」や「toHexString() - 16進数に変換」などがある		* 例えば、Integerクラスには「parseInt() - 文字列の数字を int型に変換」や「toHexString() - 16進数に変換」などがある
	* ~~ラッパークラスはインスタント化しなくても手軽に利用できる~~		* ラッパークラスは'''インスタント化しなくても手軽に利用'''できる
	* 古いバージョンの Java では基本型とラッパークラスの相互変換を手動でする必要があったが、Java5 以降からは型変換は「=」で割り当てが発生した時に自動でやってくれる。『入門』p556		* 古いバージョンの Java では基本型とラッパークラスの相互変換を手動でする必要があったが、Java5 以降からは型変換は「=」で割り当てが発生した時に自動でやってくれる。『入門』p556
	* Java における日付情報は基本的に java.util.Date で扱う		* '''Java における日付情報は基本的に java.util.Date''' で扱う
	* 「年月日時分秒」６つの int値から Dateインスタンスを得るためには Calendarクラスを使う		* 「年月日時分秒」６つの int値から Dateインスタンスを得るためには Calendarクラスを使う
	* Dateインスタンスの内容を好きな書式に整形したい場合は SimpleDateFormatクラスを使う		* Dateインスタンスの内容を好きな書式に整形したい場合は SimpleDateFormatクラスを使う

Y: /* 第１３章：多態性、多様性 */

2019-02-21T01:43:10Z

第１３章：多態性、多様性

← 古い版		2019年2月21日 (木) 10:43時点における版
300行目:		300行目:
	* だから、たとえ楽ができるように思えても is-a の関係にならないのであれば継承（extends や interface）で結びつけてはいけない		* だから、たとえ楽ができるように思えても is-a の関係にならないのであれば継承（extends や interface）で結びつけてはいけない
	* 常々、正しい継承関係を JVM に教えながら部品作りを進めることが、オブジェクト指向の真髄を最大限に利用してとても効率的なプログラミングをするコツ		* 常々、正しい継承関係を JVM に教えながら部品作りを進めることが、オブジェクト指向の真髄を最大限に利用してとても効率的なプログラミングをするコツ
	* ~~とりあえず、十把一絡げで扱いたいグループがある場合そのグループ内のインスタンスたちは共通の親クラスから~~ extends されている必要がある		* とりあえず、'''十把一絡げで扱いたいグループがある場合'''そのグループ内のインスタンスたちは共通の親クラスから extends されている必要がある
	* ~~オブジェクト指向プログラミングとは、人が世界を認識（カテゴリー・階層に分けて整理、擬人化など）しているその認識を忠実に~~ JVM にアップロードして（パラレルワールドを創造して）マシンに扱わせようという試み		* '''オブジェクト指向プログラミングとは'''、人が世界を認識（カテゴリー・階層に分けて整理、擬人化など）しているその認識を忠実に JVM にアップロードして（パラレルワールドを創造して）マシンに扱わせようという試み
	* 整理整頓が大好きで得意な人は、オブジェクト指向プログラミングに向いている		* 整理整頓が大好きで得意な人は、オブジェクト指向プログラミングに向いている

Y: /* 第１２章：共通部品や仕様の作り方 - abstract / interface */

2019-02-21T01:08:37Z

第１２章：共通部品や仕様の作り方 - abstract / interface

← 古い版		2019年2月21日 (木) 10:08時点における版
266行目:		266行目:
	* 複数ステップの正しい継承がなされている場合、継承ツリーを上へたどっていくと次のような現象が起こる。『入門』の p474 を参照		* 複数ステップの正しい継承がなされている場合、継承ツリーを上へたどっていくと次のような現象が起こる。『入門』の p474 を参照
	* 継承ツリーを上へ辿るということは「'''どんどん汎化していく'''」と言うこと		* 継承ツリーを上へ辿るということは「'''どんどん汎化していく'''」と言うこと
	'''もはや「仕様書」レベル'''に抽象度が高くなった抽象クラスは「'''インターフェース'''」になる		* '''もはや「仕様書」レベル'''に抽象度が高くなった抽象クラスは「'''インターフェース'''」になる
	* '''インターフェースになる基本条件'''：全てが抽象メソッド && （フィールドがあるなら定数のみ）		* '''インターフェースになる基本条件'''：全てが抽象メソッド && （フィールドがあるなら定数のみ）
	* インターフェース内のフィールドは全て public static final となり、メソッドは全て public abstract となる。これらは省略可。Java8 からはデフォルト指定ができる		* インターフェース内のフィールドは全て public static final となり、メソッドは全て public abstract となる。これらは省略可。Java8 からはデフォルト指定ができる

Y: /* 第１２章：共通部品や仕様の作り方 - abstract / interface */

2019-02-21T01:07:38Z

第１２章：共通部品や仕様の作り方 - abstract / interface

← 古い版		2019年2月21日 (木) 10:07時点における版
243行目:		243行目:

	==第１２章：共通部品や仕様の作り方 - abstract / interface==		==第１２章：共通部品や仕様の作り方 - abstract / interface==
	* ~~継承に備わっている機能を駆使すれば長きにわたって利用しやすい（されやすい）親クラスを作成できる~~		* 継承に備わっている機能を駆使すれば'''長きにわたって利用しやすい（されやすい）親クラス'''を作成できる
	* 継承に備わっている機能とは「抽象クラス」やより上位の抽象クラスである「インターフェース」		* 継承に備わっている機能とは「抽象クラス」やより上位の抽象クラスである「インターフェース」
	* ~~抽象クラスを利用する上で大切な視点は「将来的に利用されることを想定して使いやすいように」開発しておくこと~~		* 抽象クラスを利用する上で大切な視点は「'''将来的に利用されることを想定して使いやすいように'''」開発しておくこと
	* ~~そもそも将来を見越して親クラスの開発をしていると幾つかの決定的な不都合が出てくる。~~		* そもそも'''将来を見越して親クラスの開発'''をしていると幾つかの決定的な不都合が出てくる
	* 詳細を決定できないメソッドが出てくる。かと言ってそのメソッドを省略すると以下２点の心配事が出てくる		* 詳細を決定できないメソッドが出てくる。かと言ってそのメソッドを省略すると以下２点の心配事が出てくる
	* オーバーライドのし忘れに繋がる（第１の心配）		* オーバーライドのし忘れに繋がる（第１の心配）
	* 「何もしない」ためのメソッドと区別できない（第２の心配）		* 「何もしない」ためのメソッドと区別できない（第２の心配）
	* そもそも、現実世界との不整合も起きるし、将来の利用者が誤用してしまう危険性がある		* そもそも、現実世界との不整合も起きるし、将来の利用者が誤用してしまう危険性がある
	* ~~そもそも「クラス」には２つの利用用途がある：1~~. インスタンス生成用クラス、2. 部品用クラス		* そもそも'''「クラス」には２つの利用用途'''がある：1. インスタンス生成用クラス、2. 部品用クラス
	* ゆえに、未来の開発者が間違って new してしまう危険性がある（第３の心配事）		* ゆえに、未来の開発者が間違って new してしまう危険性がある（第３の心配事）
	* 抽象クラス（親）は「継承の材料」として開発されているにも関わらず、それが new されると不完全インスタンスが生まれてしまう		* 抽象クラス（親）は「継承の材料」として開発されているにも関わらず、それが new されると不完全インスタンスが生まれてしまう
	* 一部でも未完成部分が残っている設計図から、インスタンス（実体）を生み出してはいけない		* 一部でも未完成部分が残っている設計図から、インスタンス（実体）を生み出してはいけない
	* Java ~~では、抽象クラスは~~ new ~~によるインスタンス化が禁止されている。不完全インスタンスが誕生することを未然に防止~~		* Java では、'''抽象クラスは new によるインスタンス化が禁止'''されている。不完全インスタンスが誕生することを未然に防止
	* ~~抽象クラス：みんなに継承されて利用される部品専用のクラス。抽象メソッドが含まれると自動的に抽象クラス扱い~~		* '''抽象クラス'''：みんなに継承されて利用される'''部品専用のクラス'''。抽象メソッドが含まれると自動的に抽象クラス扱い
	* ゆえに、宣言時に abstract を付けて抽象クラスであることをを明示しないとコンパイルエラー		* ゆえに、宣言時に abstract を付けて抽象クラスであることをを明示しないとコンパイルエラー
	* ~~抽象メソッド：メソッドに~~ abstract を付けて「;」で閉じる。{} がなくても良い。		* '''抽象メソッド'''：メソッドに abstract を付けて「;」で閉じる。{} がなくても良い。
	* 抽象クラス（インターフェース）を作るということは「これは部品なんだから該当箇所を必ずオーバーライドして使ってね」ということ。オーバーライドの強制		* 抽象クラス（インターフェース）を作るということは「これは部品なんだから該当箇所を'''必ずオーバーライドして使ってね'''」ということ。オーバーライドの強制
	* 抽象クラス（部品）単体ではインスタンス化できない（実体になれない）。必ずオーバーライドによって具現化される必要がある		* 抽象クラス（部品）単体ではインスタンス化できない（実体になれない）。必ずオーバーライドによって具現化される必要がある
	* 曖昧な設計図からは実体を創造できない		* '''曖昧な設計図からは実体を創造できない'''
	* 抽象クラスを継承した子クラスは、内部に抽象メソッドを含んでいるため、そのメソッドを自分内でオーバーライド（具体化）しないとそもそもインスタンス化できない		* 抽象クラスを継承した子クラスは、内部に抽象メソッドを含んでいるため、そのメソッドを自分内で'''オーバーライド（具体化）しないとそもそもインスタンス化できない'''
	* ~~オブジェクト指向における整理された部品作りの良い概念テンプレートは『入門』の~~ p470,471 を参照		* オブジェクト指向における整理された部品作りの良い概念テンプレートは'''『入門』の p470,471 を参照'''
	* 複数ステップの正しい継承がなされている場合、継承ツリーを上へたどっていくと次のような現象が起こる。『入門』の p474 を参照		* 複数ステップの正しい継承がなされている場合、継承ツリーを上へたどっていくと次のような現象が起こる。『入門』の p474 を参照
	* ~~継承ツリーを上へ辿るということは「どんどん汎化していく」と言うこと~~		* 継承ツリーを上へ辿るということは「'''どんどん汎化していく'''」と言うこと
	~~もはや「仕様書」レベルに抽象度が高くなった抽象クラスは「インターフェース」になる~~		'''もはや「仕様書」レベル'''に抽象度が高くなった抽象クラスは「'''インターフェース'''」になる
	* ~~インターフェースになる基本条件：全てが抽象メソッド~~ && （フィールドがあるなら定数のみ）		* '''インターフェースになる基本条件'''：全てが抽象メソッド && （フィールドがあるなら定数のみ）
	* インターフェース内のフィールドは全て public static final となり、メソッドは全て public abstract となる。これらは省略可。Java8 からはデフォルト指定ができる		* インターフェース内のフィールドは全て public static final となり、メソッドは全て public abstract となる。これらは省略可。Java8 からはデフォルト指定ができる
	* そのままの抽象クラス表記でも良いが interface に置き換えても良い。public interface ClassName { ...		* そのままの抽象クラス表記でも良いが interface に置き換えても良い。public interface ClassName { ...
276行目:		276行目:
	* インターフェースを使うと、少なくともそのインターフェースが定めたメソッドは持っていることが保証される		* インターフェースを使うと、少なくともそのインターフェースが定めたメソッドは持っていることが保証される
	* 継承にインターフェースを複数使ってもメソッドの衝突が起きないのでインターフェースを使った多重継承は認められている。『入門』の p483,484 を参照		* 継承にインターフェースを複数使ってもメソッドの衝突が起きないのでインターフェースを使った多重継承は認められている。『入門』の p483,484 を参照
	* ~~インターフェースを使った多重継承：public~~ class SpecialName implements Hero, Princess, Character { ...		* '''インターフェースを使った多重継承'''：public class SpecialName implements Hero, Princess, Character { ...
	* ちなみに、（継承ではなくて）インターフェースを拡張するときは extends を使う		* ちなみに、（継承ではなくて）インターフェースを拡張するときは extends を使う
	* 以上のように、抽象クラス（インターフェース）は、プログラムを部品化して使いまわしたり拡張したりするときに不整合や不具合が発生しないようにするための事前の予防策		* 以上のように、抽象クラス（インターフェース）は、プログラムを部品化して使いまわしたり拡張したりするときに不整合や不具合が発生しないようにするための事前の予防策
	* 抽象クラスは、複数人で大規模なプログラミングに明け暮れてきたプログラマの天才たちが編み出した苦肉の策		* 抽象クラスは、複数人で大規模なプログラミングに明け暮れてきたプログラマの天才たちが編み出した苦肉の策
	* オブジェクト指向プログラミングでは、実世界の的確な把握かつ、仮想世界への再現力が重要となる		* オブジェクト指向プログラミングでは、実世界の的確な把握かつ、仮想世界への再現力が重要となる
	* とりあえず、現実世界を的確に把握して、設計図を書いて、それからそれをインターフェース（仕様書）や抽象クラス（共通部品）に落とし込んで、親クラス → 子クラスへと実体を作り込んでいく		* '''とりあえず'''、現実世界を的確に把握して、設計図を書いて、それからそれをインターフェース（仕様書）や抽象クラス（共通部品）に落とし込んで、親クラス → 子クラスへと実体を作り込んでいく
	* 最終の子クラス（完成品）には fainal を付けるか？		* 最終の子クラス（完成品）には fainal を付けるか？
	* ~~どんどん、オーバーライド（概念に肉付け）していく感じ~~		* どんどん、オーバーライド（'''概念に肉付け'''）していく感じ
	* ~~とりあえず、自分の作っているクラスが「継承で使う共通部品」であるなら~~ abstract をつける		* とりあえず、'''自分の作っているクラスが「継承で使う共通部品」であるなら abstract''' をつける

	==第１３章：多態性、多様性==		==第１３章：多態性、多様性==

Y: /* 第１１章：継承 - extends */

2019-02-21T01:04:13Z

第１１章：継承 - extends

← 古い版		2019年2月21日 (木) 10:04時点における版
222行目:		222行目:
	==第１１章：継承 - extends==		==第１１章：継承 - extends==
	* extends を使うことによって、元となるクラスの「差分」だけを記述して新たなクラスを作れる		* extends を使うことによって、元となるクラスの「差分」だけを記述して新たなクラスを作れる
	* ~~継承関係：スーパークラス（親クラス：抽象的）←~~ サブクラス（子クラス：具体的）		* '''継承関係'''：スーパークラス（親クラス：抽象的）← サブクラス（子クラス：具体的）
	* Java では、複数のクラスを親として１つの子クラスを作ること（多重継承）はできない		* Java では、複数のクラスを親として１つの子クラスを作ること（多重継承）はできない
	* ~~もちろん、親クラスで既に定義されているメソッド名を新しく定義し直すこともできる（オーバーライド）~~		* もちろん、親クラスで既に定義されているメソッド名を新しく定義し直すこともできる（'''オーバーライド'''）
	* final ~~が付けられれているクラスは継承に使えない~~		* final が付けられれているクラスは'''継承に使えない'''
	* final ~~が付けられているメソッドは子クラスでオーバーライドできない~~		* final が付けられているメソッドは子クラスで'''オーバーライドできない'''
	* ~~継承によって作られた子クラスは、内部に親クラスを含む二重構造になっている~~		* 継承によって作られた子クラスは、'''内部に親クラスを含む二重構造'''になっている
	* super.フィールド名、super.メソッド名() で親クラスのメンバにアクセスできる		* super.フィールド名、super.メソッド名() で親クラスのメンバにアクセスできる
	* ちなみに祖父母クラスまで継承することはできるが、メンバへのアクセスは super を利用した親クラスまでしか届かない		* ちなみに祖父母クラスまで継承することはできるが、メンバへのアクセスは super を利用した親クラスまでしか届かない
234行目:		234行目:
	* 親クラスと子クラスのコンストラクタの引数に食い違いがあるとインスタンスを作れない状況になることも		* 親クラスと子クラスのコンストラクタの引数に食い違いがあるとインスタンスを作れない状況になることも
	* 子クラスのコンストラクタの一行目で親クラスのコンストラクタへ渡す引数を定義できる。super(apple);		* 子クラスのコンストラクタの一行目で親クラスのコンストラクタへ渡す引数を定義できる。super(apple);
	* 継承 is-a ~~の原則：継承が正しく使われているかどうかは「子クラス~~ is a ~~親クラス」の是非で確認できる~~		* '''継承 is-a の原則'''：継承が正しく使われているかどうかは「'''子クラス is a 親クラス'''」の是非で確認できる
	* is-a の原則を無視すると、将来的に現実世界との矛盾が生じたり、多態性を利用できなくなったりする		* is-a の原則を無視すると、将来的に現実世界との矛盾が生じたり、多態性を利用できなくなったりする
	* is-a の関係で結ばれていると、親クラスになればなるほど汎化していき、子クラスになればなるほど特化していく（例：car ← bus）		* is-a の関係で結ばれていると、親クラスになればなるほど汎化していき、子クラスになればなるほど特化していく（例：car ← bus）
	* ~~特化していくということは定義するフィールドやメソッドがマニアックに（詳細に）なっていくということ~~		* '''特化していく'''ということは定義するフィールドやメソッドが'''マニアック'''に（詳細に）なっていくということ
	* ~~汎化していくということは定義するフィールドやメソッドが汎用的に（大雑把）なっていくということ~~		* '''汎化していく'''ということは定義するフィールドやメソッドが'''汎用的'''に（大雑把）なっていくということ
	* 「継承」はコードの重複記述を減らすだけでなく、２つのクラスの特化・汎化の関係を JVM に伝える目的もある		* 「継承」はコードの重複記述を減らすだけでなく、２つのクラスの特化・汎化の関係を JVM に伝える目的もある
	* ~~とりあえず、extends~~ するときは is-a の原則を絶対に成り立たせる		* とりあえず、'''extends するときは is-a の原則を絶対に成り立たせる'''

	==第１２章：共通部品や仕様の作り方 - abstract / interface==		==第１２章：共通部品や仕様の作り方 - abstract / interface==

← 古い版		2019年2月21日 (木) 10:51時点における版
332行目:		332行目:
	==第１５章：例外==		==第１５章：例外==
	* 不具合対策こそがプログラマの腕の見せ所。あらゆる可能性を想定して事前に手を打っておくのが例外処理		* 不具合対策こそがプログラマの腕の見せ所。あらゆる可能性を想定して事前に手を打っておくのが例外処理
	* ~~考えられる不具合は、文法エラー、実行時エラー、論理エラー。「実行時エラー」は例外処理で対処する~~		* 考えられる不具合は、文法エラー、実行時エラー、論理エラー。'''「実行時エラー」は例外処理で対処'''する
	* 文法エラーと論理エラーは開発者の過失。開発時にテストをしっかり行ってデバッグすれば良い		* 文法エラーと論理エラーは開発者の過失。開発時にテストをしっかり行ってデバッグすれば良い
	* 実行時エラーのことを「例外」と言う：パソコンのメモリ不足、ファイルが見つからない、null を利用しようとしたなど		* 実行時エラーのことを「例外」と言う：パソコンのメモリ不足、ファイルが見つからない、null を利用しようとしたなど
339行目:		339行目:
	* この点、Java では例外管理は JVM と協働で行う。プログラマは例外が発生しそうな箇所を try-catch文で囲んで例外が発生した時の処理を書いておくことができる		* この点、Java では例外管理は JVM と協働で行う。プログラマは例外が発生しそうな箇所を try-catch文で囲んで例外が発生した時の処理を書いておくことができる
	* tryブロックは JVMに「この部分では例外的な状況が発生する可能性があるから検出を試みながら実行しろ」と言っている感じ		* tryブロックは JVMに「この部分では例外的な状況が発生する可能性があるから検出を試みながら実行しろ」と言っている感じ
	* ~~例外クラス：Java~~ では、発生した例外に応じて適切な処理ができるようにそれぞれの例外的状況に応じたクラスが複数用意されている		* '''例外クラス'''：Java では、発生した例外に応じて適切な処理ができるようにそれぞれの例外的状況に応じたクラスが複数用意されている
	* 例外クラスは、Throwable ← Exception ← Exception系例外（catch すべき）、Throwable ← Error ← Error系例外という継承関係になっている		* 例外クラスは、Throwable ← Exception ← Exception系例外（catch すべき）、Throwable ← Error ← Error系例外という継承関係になっている
	* ~~Error系例外：メモリ不足やファイル自体が壊れている、など。そもそも、このような状況をキャッチしても打つ手がないためキャッチする必要はない~~		* '''Error系例外'''：メモリ不足やファイル自体が壊れている、など。そもそも、このような状況をキャッチしても打つ手がないため'''キャッチする必要はない'''
	* Exception系例外：ファイルに書き込みできない、ネットワークに接続できない、など。その発生を十分に想定して対処を考える必要がある。例外処理が必須		* '''Exception系例外'''：ファイルに書き込みできない、ネットワークに接続できない、など。その発生を十分に想定して対処を考える必要がある。'''例外処理が必須'''
	* ~~RuntimeException系例外：いちいち想定しているとキリがない。対処するかどうかは任意~~		* '''RuntimeException系例外'''：いちいち想定しているとキリがない。対処するかどうかは任意
	* Java では、Exception系の例外が発生しそうなコマンドを使う場合、try-~~catch文を書いて例外処理を書いておかないとコンパイルエラーになる。サボれない~~		* Java では、Exception系の例外が発生しそうなコマンドを使う場合、try-catch文を書いて例外処理を書いておかないとコンパイルエラーになる。'''サボれない'''
	* ~~コンパイル時にその是非がチェックされるために、Exception系のエラーは「チェック例外」と呼ばれる~~		* コンパイル時にその是非がチェックされるために、Exception系のエラーは「'''チェック例外'''」と呼ばれる
	* JavaAPI のクラスには利用すると何らかなの例外を発生させる可能性があるメソッドが数多くある。利用する時はキャッチすべき例外の有無をリファレンスで確認する必要がある		* JavaAPI のクラスには利用すると何らかなの例外を発生させる可能性があるメソッドが数多くある。利用する時はキャッチすべき'''例外の有無をリファレンスで確認する必要'''がある
	* Exception系例外が発生する可能性がある場合、引数リストの後に「throw 例外クラス名」と表記される		* Exception系例外が発生する可能性がある場合、引数リストの後に「throw 例外クラス名」と表記される
	* 例外的状況の詳細情報が詰め込まれた IOExceptionインスタンスを catch文で指定された変数 e に割り当てたりする		* 例外的状況の詳細情報が詰め込まれた IOExceptionインスタンスを catch文で指定された変数 e に割り当てたりする
	* catchブロック内では、この変数 e に格納された詳細情報を取り出して適切なエラー処理を行うことができる		* catchブロック内では、この変数 e に格納された詳細情報を取り出して適切なエラー処理を行うことができる
	* 例外インスタンスで共通して利用できるメソッドには「getMessage() - エラーメッセージ表示」や「printStackTrace() - トレース文の表示」などがある		* 例外インスタンスで共通して利用できるメソッドには「getMessage() - エラーメッセージ表示」や「printStackTrace() - トレース文の表示」などがある
	* 例外が発生しても try-~~catch文でキャッチ並びに適切に処理されない場合、JVM はプログラムを強制終了してスタックトレース内容を画面に表示する~~		* 例外が発生しても try-catch文でキャッチ並びに適切に処理されない場合、'''JVM はプログラムを強制終了'''してスタックトレース内容を画面に表示する
	* catchブロックを複数記述できる。処理内容が同じ場合は catch(IOException \| NullPointException e) のように記述もできる		* catchブロックを複数記述できる。処理内容が同じ場合は catch(IOException \| NullPointException e) のように記述もできる
	* ~~例外クラスの抽象クラスを利用すれば、ざっくりと捉えた例外処理もできる。親：Exception~~ ← 子：Exception系例外		* 例外クラスの抽象クラスを利用すれば、'''ざっくりと捉えた例外処理も'''できる。親：Exception ← 子：Exception系例外
	* fw.close() のような後片付け処理は必ず実行させる必要があるので try-catch-finallyブロック内に必ず記述		* fw.close() のような後片付け処理は必ず実行させる必要があるので try-catch-finallyブロック内に必ず記述
	* finally を使うべき状況：ファイル・データベース接続・ネットワーク接続など、後片付け処理		* finally を使うべき状況：ファイル・データベース接続・ネットワーク接続など、後片付け処理
	* Java7 ~~以降からは、try 直後の丸カッコ内にファイルオープンやデータベース接続の処理を書いておくと、使い終わった時点で~~ JVM が自動的に閉じてくれる		* Java7 以降からは、'''try 直後の丸カッコ内にファイルオープンやデータベース接続の処理を書いておく'''と、使い終わった時点で JVM が自動的に閉じてくれる
	* Exception系例外（チェック例外）は基本的にtry-catch文による対処が必須だが、メソッド宣言時に throw ~~を付けると例外処理を呼び出し元に投げることができる�（自分はしなくて済む）~~		* Exception系例外（チェック例外）は基本的にtry-catch文による対処が必須だが、メソッド宣言時に throw を付けると例外処理を呼び出し元に投げることができる（自分はしなくて済む）
	* 例外throw元「私はメソッド内でチェック例外が発生しても処理しませんが、throw先が処理してくれます」		* 例外throw元「私はメソッド内でチェック例外が発生しても処理しませんが、throw先が処理してくれます」
	* 例外throw先「このメソッドは例外を throw しているから、例外処理はこちら側でしておかないとな」		* 例外throw先「このメソッドは例外を throw しているから、例外処理はこちら側でしておかないとな」
	* ~~メソッドを作るときは「チェック例外をどう処理するか」について方針を以下の２つから選ぶ必要がある~~		* メソッドを作るときは「チェック例外をどう処理するか」について'''方針を以下の２つから選ぶ必要'''がある
	* 1. チェック例外は呼び出される側で処理し完結させておく。2. 呼び出す側で処理する		* 1. チェック例外は呼び出される側で処理し完結させておく。2. 呼び出す側で処理する
	* 空の catch文は作らない（例外のもみ消し）。よほどの理由がある時はコメントに理由を残しておく		* 空の catch文は作らない（例外のもみ消し）。よほどの理由がある時はコメントに理由を残しておく
	* 「throw new 例外クラス名（"（エラーメッセージ）")~~」など、例外インスタンスを作成すれば好きな場所で意図的に例外を発生させることもできる~~		* 「throw new 例外クラス名（"（エラーメッセージ）")」など、'''例外インスタンスを作成すれば好きな場所で意図的に例外を発生'''させることもできる
	* 好きな場所で意図的に例外を発生させるこの throw と、親に例外処理を丸投げする throw ~~は種類が別なので注意する~~		* 好きな場所で意図的に例外を発生させるこの throw と、親に例外処理を丸投げする throw は'''種類が別なので注意'''する
	* 例外クラスも結局は抽象クラス（共有部品）の１つに変わりないので、親メソッドを extends ~~してオリジナルの例外クラスを作成できる~~		* 例外クラスも結局は抽象クラス（共有部品）の１つに変わりないので、親メソッドを '''extends してオリジナルの例外クラスを作成'''できる
	* 高技術さえあれば、徹夜２週間続けての開発で５００万が発想できる業界らしい		* 高技術さえあれば、徹夜２週間続けての開発で５００万が発想できる業界らしい