Document Actions
暴いておやりよＯＯバッキー[3]
筆者が非オブジェクトな時代から今まで経験した、オブジェクト指向での自らの失敗を取り上げてＯＯバッキ－に断罪させるコーナーです。
登場人物
ＯＯバッキー: 性格が悪い子猫。オブジェクト指向の勘違いを指摘していじめるのが何より好き。 Ｕ君: ＯＯバッキーの飼い主。いつもＯＯバッキーにいじめられている。気が弱い。オブジェクト指向の初心者。
- ＯＯバッキー:
- ニャー！俺ＯＯバッキー。オブジェクト指向の勘違いを探しにやってきた子猫なんだ。勘違い野郎はどこにいるのかニャー。
- Ｕ君:
- ＯＯバッキ－。今度僕が考えた構造でものっすごくコード量が減って、重複が少なくなったんだ。
public class CreateCatalogCommand {
public void execute(){
:
}
protected Catalog doServiceMethod() throws ApException{
:
SessionBeanのカタログ生成のサービスを呼ぶロジック
:
}
}
public class UpdateCatalogCommand extends CreateCatalogCommand {
protected Catalog doServiceMethod() throws ApException {
：
SessionBeanのカタログ更新のサービスを呼ぶロジック
：
}
}
- Ｕ君:
- 僕は気づいたんだけど、このカタログの更新と、新規作成でやってることは、SessionBeanの更新メソッドか、生成メソッドを使うかというだけで、画面からカタログの項目をとってきて、 カタログオブジェクトにセットすることや、サービスから帰ってきたカタログオブジェクトを再度画面に渡すこととか、他はみんないっしょなんだ。だから、更新はCreateCatalogCommandを 継承してdoServiceMethod()を上書きするだけで出来ちゃうんだよ。
- ＯＯバッキー:
- にゃ～。（ため息）
- Ｕ君:
- え？
- ＯＯバッキー:
- オブジェクト指向の３大基礎のうちのもっとも理解しやすい「継承」すら理解していないようだニャー。
- Ｕ君:
- どこが！継承使ってるじゃないバリバリに。重複もないよ。
- ＯＯバッキー:
- じゃ継承ってどういうことだニャー？
- Ｕ君:
- 差分コーディングだろ？ＡクラスとＢクラスがあって、Ａクラスのメソッドと違う部分と追加部分だけＢに書けばいいんでしょ？
- ＯＯバッキー:
- にゃ～。（ため息）それだったら、継承は機能が同じだったら継承するのかにゃ？オブジェクト指向は「オブジェクト（もの）」 が同じだから継承するんだニャ。たとえば「商品」を継承した「一般商品」と「特売品」はどちらも「商品」だから「商品」を 継承している（性質を引き継いでいる）んだニャー。機能が同じだからじゃないんだニャ。ご主人様はここでも非オブジェクトだニャ。
- Ｕ君:
- ハイハイ。どうせ僕は非オブジェクトですよ。なんかよく意味わからんけど。
- ＯＯバッキー:
最近は外国ではスクイークとやらで、子供でもオブジェクト指向やってるらしいニャー。ご主人様は、猫の俺様と子供以下だニャ～。
ご主人様の例では、図でいくとこうなるニャ。
- ＯＯバッキー:
- この例ではたまたまやっていることが同じなだけであって、どう考えても「カタログの更新」は「カタログの登録」じゃないニャー。さっきの 商品の例だと「一般商品」も「特売品」も「商品」だニャ。だからやるとしてもせめてこんな風にするとまだましだニャ。
- ＯＯバッキー:
これだったら「カタログを更新する命令」も「カタログを登録する命令」も「カタログを操作の命令」といえるので、継承として考えられん事もないニャ。
「機能が同じ」だから「継承」すると、スーパークラスがぶくぶくに膨れて、ほとんど共通関数の塊みたいな「何でもクラス」になって、 それを修正するととんでもなく影響範囲が大になったりするニャー。
Javaとかでコーディングするときは、頭の中や紙でモデルみたいなものがあってそれをJavaに置き換えるイメージでやったほうがいいんじゃないかニャー。
- Ｕ君:
- なるほど。僕もこんな感じで努力していたら、○ーチンファウラーみたいになれるかなぁ。
- ＯＯバッキー:
- 努力じゃなくて、単なる無駄だニャ。今のままじゃ、180年以上はかかるんじゃないかニャー。（きっぱり）
こうして今夜もＯＯバッキーはオブジェクター志望Ｕ君を夢から現実に引き戻すのであった。
暴いておやり、ねぇ子猫。僕の育てたＯＯバッキー。おなかつつけば語りだす真実を・・・。
- ＯＯバッキーその3