| At line 4 changed one line |
| !「privateメソッドに渡すパラメータをひとかたまり(データ構造)とするクラスを見逃している。」 |
| *privateメソッドに渡すパラメータをひとかたまり(データ構造)とするクラスを見逃している |
| At line 65 changed one line |
| !privateメソッドを作りたくなった時はクラスを見逃している |
| *privateメソッドを作りたくなった時はクラスを見逃している |
| At line 68 changed one line |
| !そのパラメータをひとかたまり(データ構造)とするクラスを作るべき |
| *そのパラメータをひとかたまり(データ構造)とするクラスを作るべき |
| At line 71 changed 3 lines |
| *姓 |
| *名 |
| を持つ「__氏名クラス__」を作るべきです。そしてそのクラスに__委譲__するのです。\\ |
| #姓 |
| #名 |
| を持つ__氏名クラス__を作るべきです。そしてそのクラスに__委譲__するのです。\\ |
| At line 78 changed one line |
| パラメータの無い、つまり__共通関数ですらないprivateメソッド__がなぜ必要なのでしょうか? 彼らの答えは「可読性をあげるため長いコードを分割するんだ。」なのですが、私に言わせると「ちゃんちゃら可笑しいw」です。\\ |
| パラメータの無い、つまり__共通関数ですらないprivateメソッド__がなぜ必要なのでしょうか? 彼らの答えは「可読性をあげるため長いコードを分割するんだ。」なのですが、これは全くの誤りであると私は考えます。\\ |
| At line 130 changed one line |
| 正しいクラスを定義した結果、それでもメソッドの記述が長くなる場合、例えば属性が100個ぐらいあって一つの処理が長くなる場合、それはそれで正しいのです。意味も無く分割する必要は無いというのが私の考えです。 |
| 正しいクラスを定義した結果それでもメソッドの記述が長くなる場合、例えば属性が100個ぐらいあって一つの処理が長くなる場合、それはそれで正しいのです。意味も無く分割する必要は無いというのが私の考えです。 |
| At line 136 changed 2 lines |
| !フィールドを隠蔽するためにメソッドが口を開けている |
| ということです。つまり公開されないメソッドはこの原則に反するのです。__privateによって隠蔽するべきなのはフィールドであってメソッドではない__という原則がこの図からも解ります。\\ |
| *フィールドを隠蔽するためにメソッドが口を開けている(公開されている) |
| ということです。つまり公開されないメソッドはこの原則に反するのです。 |
| *privateによって隠蔽すべきなのはフィールド(属性)であってメソッドではない |
| という原則がこの図からも解ります。\\ |
| At line 170 changed 2 lines |
| private String yuubinBangou = ""; |
| private String jyuusho = ""; |
| private String yuubinBangou = ""; // 郵便番号 |
| private String jyuusho = ""; // 住所 |
| At line 180 changed one line |
| StringUtility#getFullName()メソッドの機能は、「1つめのパラメータと2つめのパラメータを2個のスペースを挟んで連結する」というものです。上記のように、「事務所クラスの宛先を返すメソッド」にこの機能がたまたま使えたとすれば使われる可能性を排除できません。\\ |
| StringUtility#getFullName()メソッドの機能は、「1つめのパラメータと2つめのパラメータを2個のスペースを挟んで連結する」というものです。上記のように、「事務所クラスの宛先を返すメソッド」にこの機能がたまたま使えたとすれば使われてしまう可能性を排除できません。\\ |
| At line 187 changed one line |
| この場合の変更箇所はStringUtility.getFullName()メソッドのみではなく、それを呼び出している全メソッドが対象となります(当然ですが)。その際、「従業員クラスの宛先を返すメソッド」も該当しますが、事務所クラスは「ミドルネーム」を持たないため破綻してしまいます。別の関数を新たに作る必要が出てきます。\\ |
| この場合の変更箇所はStringUtility.getFullName()メソッドのみではなく、それを呼び出している全メソッドが対象となります(当然ですが)。その際、「従業員クラスの宛先を返すメソッド」も該当しますが、事務所クラスは「ミドルネーム」を持たないため破綻してしまいます。別の関数を新たに作る必要が出て来るのです。高い保守性とこれでは言えません。\\ |
| At line 189 changed one line |
| 一方で、「氏名クラス」を利用している場合はどうでしょう?\\ |
| 一方で、「氏名クラス」を利用している場合はどうでしょうか。\\ |
| At line 191 changed one line |
| なぜならば、ユーティリティクラスの目的は「処理」、つまり |
| なぜならば、ユーティリティクラスの目的は「処理」つまり |
| At line 193 changed 2 lines |
| という機能を提供することですが、氏名クラスの目的は、 |
| *氏名となるデータを保持すること |
| という__機能を提供すること__ですが、氏名クラスの目的は、 |
| *氏名を構成する属性(データ構造)を保持すること |
| At line 196 changed one line |
| \\ |
| [name2.png]\\ |
| 氏名クラスを利用している場合、__氏名を返す()__メソッドを呼び出している側の修正は必要ありません。このことがシステムの保守性をいかに高くするかを是非理解して下さい。\\ |
| At line 198 removed one line |
| [name2.png] |
| At line 267 changed one line |
| この場合のprivateメソッドは、汎用的なデータ構造を持つクラスを継承するならば必要なくなります。上の例ではArrayListクラスです。ですが、汎用的に出来ているクラスの継承においては、そのクラスのデータ構造を熟知していないと思わぬ副作用に出くわすデメリットもあるため、privateメソッド利用とのデメリットをよく検討した上で選ぶようにしてください。\\ |
| この場合のprivateメソッドは、汎用的なデータ構造を持つクラスを継承するならば必要なくなります。上の例ではArrayListクラスです。ですが、汎用的に出来ているクラスの継承においては、そのクラスのデータ構造を熟知していないと思わぬ副作用に出くわすデメリットもあるため、privateメソッド利用とのデメリットをよく検討した上で選ぶようにして下さい。\\ |
| At line 279 changed one line |
| オブジェクト指向の出発点は「1ヶ所直せば皆直る」です。難しいことは置いておいても、これを目指して皆さんも設計・実装してみてください。そうすれば、オブジェクト指向の核心がきっと見えてきます。\\ |
| オブジェクト指向の出発点は「1ヶ所直せば皆直る」です。難しいことは置いておいても、これを目指して皆さんも設計・実装してみて下さい。そうすれば、オブジェクト指向の核心がきっと見えてきます。\\ |
| \\ |
| 次: [どのメソッドをどのクラスで実装すべきか] |
