まとめ

オブジェクト指向開発を行う際に大事な事があって。
大事な事からそれなければ必然としてポリモルフィズムは実現できる。
そのために必要な事。
試行錯誤を理論立てて実行すること。
成功はもちろん失敗も予定通りとするココロが大事。
クラスやメソッドの役割分担を行い、
コードの書き直しを恐れずに何度もチャレンジすることが大事。

以下余談

とはいえっても、オブジェクト指向を用いることの目的はあくまで
システム開発の成功にあり、開発速度も速く、保守性にも優れたコードの作成であり、
ポリモルフィズムやインヘリタンスってのは手段にでしかない。
手段を目的とするのは古今東西愚の骨頂な行動である。

UMLモデラーもある一定を超えた人達は盛んに「UMLってば分りやすいっ」ってのを強調するが、
その説明は今のおいらでもさっぱりワカラン言葉遣いなのがいっぱいだ。
さっきリンクした先のもその類。

今回の例題において、サンプル2じゃ足りないからとサンプル3を作ったが、
それでもまだまだ現実には程遠い。
ResultSetだけを返せば便利なわけじゃなく、
存在確認や件数取得、マスタから1件だけ取得したい場合や
JavaBeansのようなEntityに変換したい場合もあるだろう。
.NETならResultSetよりもDataTableやDataSetのがいいかもしれない。
取得結果をそのままGridに張りたい場合や、その他の使い方はまだまだやまほどある。
その中で、なるべく役割を分担し、同一コードが増加する場面をへらし、
誰が作っても似たような構成で構築されるための前提作りはいろいろな要因と部品を必要とする。
ｻﾝﾌﾟﾙ3はまだスタート地点。
その先の要望はまだまだあるってこった。

一つ一つ条件を増やしていき、
構成が崩れないように崩壊しないようにクラスやメソッドを前提を守りながら仕分ける。
その繰り返しが真っ当になされていればサンプル３も、
おいらが現実に生み出したコードになる。
JavaでもC#.NETでもPHPでもVBでも手順の必然性はかわらない。
リフレクション使えたほうが楽。
デリゲート使えたほうが楽。
そーゆー違いがあるくらいで、必要な手順そのものはかわらない。