麻疹とでざぱた。

設計

読書会の後の飲み会の席でid:muimyさんと、話をしていたのですが、
デザインパターンはある意味では麻疹みたいなもんじゃないかと思います。


人によってどう発症するかは違うと思いますが、僕の場合を例にとって傾向と対策をつらつらと書いてみます。

初期学習期

最初に僕が読んだのは、もちろんGOF本です。
でも、正直言って、全体的に何の事やらサッパリ分りませんでした。
特に振る舞い系のパターンが分りずらかったように思います。
また、その頃はJavaで普段コーディングしていた為か、
文中でのサンプルコードがC++中心だったのも辛かったように思います。
設計と実装を切り離して捉える事など、夢にも思わなかった頃でもあります。


最初に理解したのは、その特徴的な実装が分り易いSingletonだったと思います。
FactoryMethodも直感的に理解できたパターンでした。
TemplateMethodは当時使っていたフレームワークの中心となるパターンであった為、
実装だけは即座に理解できたと思います。

半年以上かけてGOF本を読み終え、ネットで色々なドキュメントを読み漁り始め、
最初の病的な時期を迎えます。


初期学習期のでざぱた病患者は、傍目には熱心に勉強している人にしか見えません。
また、特に周りに対して何の影響も与えない為、無害です。


この時期にデザインパターンに対する正しい認識を持った人に出会えるか、
更に、同じ様な視点で議論できる相手が居るかによって、
この後の病的な発症をある程度抑えられる時期だと思います。
僕の周りには、そういう人は殆ど居ませんでした。
この後、僕は危険かつ迷惑極まりない時期を迎える事になります。

実装乱用期

デザインパターンの理解共に、実装継承に対する理解も深まっていったように思います。
interfaceがJavaに存在する事の価値や意味を理解したのは、更に先の事です。


この時期の特徴は、兎に角実装系のパターンに傾倒する事です。
J2EEコアパターン病は、実装に寄ったパターンが多い為、
恐らくこの時期に発症すると思われます。
単純にコードの総量を減らす事だけが、パターンを採用する上での基準になります。
継承によって見た目のコードが減る事に、妙な喜びを感じる時期でもありました。
可読性やメンテナンス性の低下なんてへっちゃらでした。実に迷惑な話ですが…。
パターンの名前を使ったコミュニケーションに対する異常なまでの憧れを抱いたのもこの時期です。


この時期の患者を見つけたら、徹底的に叩きましょう。はっきり言って迷惑です。
プロジェクトの中でも、中の上程度の生産性を出せる為、
それなりに任される事も多くなるのでほおっておくと、傷口は広がる一方です。
パターンを適用する事の目的とトレードオフを理解していない事が多いので
簡単に論破できる筈です。
中途半端なコードを量産するのを即座に止めさせましょう。
実装中心のパターンに浸かっているうちは大局が見えていません。
実装依存な世界から開放されると更に伸びる可能性があるです。
そんな彼をプロジェクトにおける病原体のままにしておくのは勿体無いのです。


J2EEパターンのみならず、より多くのパターンを理解し使いこなす事こそが、
至上であると勘違いした僕は、更にマニアックなパターンの世界に傾倒していきました。

パターンカルト期

この時期にハマり込んでいたのが、Portland Pattern Repositoryです。
パターンの世界では、恐らく少し違う向きを向いているストリームラインオブジェクトモデリングに出会ったのもこの時期だったと思います。
未だに全てを理解しきれていないソフトウェアアーキテクチャに初めて手を出した時期でもあります。


この頃は、毎月数冊のパターンに関連する本を読んでいました。
パターンによって得られる事ではなく、本を読む事自体が目的化していたのです。
書いたコードの量と書籍による理論によって武装された僕の論理は、
僕の身近に居る人間には最早止める事の出来ない所まできていたと思います。
只、ここまでくると実務でやたらパターンを使いまくるような事はなくなっていったように思います。
まぁ、任される範囲が広くなり過ぎて個々の部分に拘ってる場合じゃなかった…と言う話もありますが…。


こんな状況の僕に降りかかってきた災い…、それが、例のフレームワークです。
まぁ、未だに不幸をバラ撒いているようですが…。
rodも叩き放題叩いているJava BluePrints for the Enterpriseをより複雑怪奇にしたようなクラス図を見た時、初めは唖然としました。
そのフレームワークをカスタマイズする為、僕は最初の数ヶ月間プロジェクトに参加しました、
生産性と品質に対して何の寄与もしないどころか、
足を引っ張るだけのフレームワークにハメられた僕は別な何かが見える様になったと思います。
概念は確かに素晴らしいかもしれません、でもそれだけでは動くモノは作れません。
明らかに論理や設計自体が目的化しているのです。
まぁ、コンサルで飯を食ってる人達が作ったものだと言う事を考えると、
やり方として中々上手いなぁ…とは思いますが……。
僕も、立場が違えば寧ろ嬉々としてそれに没頭できると思います。ハイ。


でも、僕に与えられているミッションは違います。
動くシステムを作る上で必要な実装面における基盤を整備する事です。
それと、火を噴かないように周りを教育(洗脳？)する事です。
噴いてしまった火は当然消さねばなりません。


それに気付いた時、パターンに対する熱狂はどこへやら消えてしまいました。

最後に。

初学者が効率良く設計や実装の能力を高める為の手段として、パターンは優れていると思います。
又、パターンを使いこなす事が高い生産性や品質に繋がる事を否定する気もありません。
パターンをキチンと理解出来る人にしか得られない何かがあるのは間違い無いと思います。


デモネ。使イ過ギハ良ク無イデス。


フレームワーク内でパターンを使う事で、品質や生産性が高まるのであれば使うべきです。
でも、業務アプリケーションを実装する上で、
その内容全てを高い精度で理解しなければ得られない品質や生産性には、疑問があります。
少量のAPI、例えばパッケージを例に取ると

に対する相応の理解だけで、業務アプリを実装出来ないようなフレームワークとは
あまりお付き合いしたくありません。


はっきり言って、業務アプリは、関数だけあれば作れます。間違い無い。
継承すらイラナイかもしれない。と思う今日この頃。


オブジェクト指向は、秘術なのです。