最近思うこと…そして実行していること。。。(オソッ！)

インターフェースの大事さです。インターフェースといっても「public interface XXXX {}」では無くて、メソッドのことです。う〜ん、少し語弊がありますね…うまく言えないなぁ〜(xx)

文章が下手なので実際の例をだしてお話します。最近、このNotesDBに「EzDao/SQLラッパークラス」で皆さんに質問させていただいたと思います。その時はまだ実際にはクラス(JAVAソース)は作成していなかったんですけど、皆さんにどれが良い？って質問するために利用方法を記述していたと思います。

こんな感じで…
【利用例】- 動的SQLの場合(S2JDBC風)
List list = dao.select("SELECT * FROM XXXXX /*CONDITION_BRGIN*/ WHERE ... /*CONDITION_END*/ ORDER BY 項目名１ ASC").where("項目名１", QL.LIKE, value1).and("項目名２", QL.EQ, value2).find();

この時に、初めて思ったのは(ここが題名のオソッ！の場所)、「利用し易い&可読性の高いソースを作成する」には、実装する前に擬似ソース(利用例)を記述してみるってことです。不思議と(当たり前？ ^^;)に、”利用しやすいか”、”しづらいか”が、この時に認識できます。また、副産物として、設計から漏れた内容を見つける事も出来てしまうのです。
↑これが大事！TDDにもつながりますが、実装完了後の機能追加（リファクタリング）は、時間の制約もあり、”無理クリ”対応することが多いのです。。。

そのため、「利用しづらい&可読性の低いソース」ができあがってしまう。という負のロジックが完成します。そうならない人は「超・ウルトラ・スパー・クリエター」なのです。日本にもTAKUSAN実在します。

おそらく皆さんも(俺だけかも…><)、何らかの機能を実装する場合(特に周りの人に利用される機能を実装する場合)は、こんな機能を満たすクラスを作成する！っていう青写真(があると思います。そして、それを元に設計を行なうでしょう。。。しかし設計書に全てがオコセルわけではないのです。(実際ムリ。だって全記述できたら、それがプログラムだから...)

なので、いざ実装してみると「設計(書)」や「思い」とは異なって分かりづらい(易しくない:NOT EASY)なクラスが出来上がってしまったりするのです。

何故でしょうか？
当たり前…だって実装が完了するまで、そのクラスを誰も利用していないんだもん(^^;)
利用し易いか機能が足りているかなんて分からない(分かっていたら設計に記述しちゃうでしょ…事実上ムリだけど）

この問題を解決する方法が、実装前の「擬似利用ソース」と実装と平行して行なう「ＴＤＤ(開発)」なのです。
あったりめージャン！バーカ！って思ったあなた … 自信もって良し！あなたは良いクリエターです(^^)v … (出来てなかった俺が、えらそーに言っちゃいます)
そうでなかった方は、だまされたと思ってやってみて下さい。
絶対、今までよりも早く良いソース(クラス)が出来上がります。マジで、ホントに...
注意：難しいとこですが、全てのクラスの実装を対象としているわけではありませんが、始めは”ためし”でやってみてください。慣れてくると、要・不要がわかってくると思います。