デザインパターンっていつ知ること?

『とりあえず勉強しなきゃ』ってことで始めたデザインパターン。

世のプログラマはいつこれを知るんだ?オブジェクト指向開発に携わる場合、これ知らないとどうにもならない気がして来た。なんというか、全てのベースになるっていうか。設計できなきゃプログラマじゃないってのは納得できる話で、そうするとデザイン(設計)パターン知らなきゃプログラマじゃないってことになるのかな。

知らなくてもいいのは十分な経験の元に色々なパターンを知っている人たちだけ。結局入り口付近にいる人たちがオブジェクト指向開発しようと思ったら、各言語のオブジェクト指向と一緒にデザインパターンを学ばないといけない。じゃないと、完全じゃなくてもデザインパターンに従った実装がされているものを触る事すら許されなくなる。知らないで触ると、「物」が破壊される危険性があるみたいだから。

で、デザインパターンを知るべきタイミングがはっきりしないなら(知らずに働き始める事が許されるなら)、フレームワークが重要になる。XML開発者の日でCool URIを自然に作るためにはフレームワークでそれを吸収する必要があるって話を聞いた。フレームワークを用意する事で、実装者に設計の負担をかけないって事だと思う。ただ、フレームワークをいじる場合は結局デザインパターンが重要になるから微妙ではある。

フレームワークには詳細なドキュメントが必要だと思う。なんだったら成果物よりもフレームワークのドキュメントの方が分厚くなるんじゃないかなとか。基礎がしっかりしないと建築物は安定しない。著作権とか拡張性の問題で公開されたフレームワークが問題になる場合、独自フレームワークを用意しないといけないんだけど、この場合ドキュメントを作ったりノウハウを蓄積させるコストが問題になる。RailsでRubyが人気になったのは、ウェブアプリケーション開発者がフレームワークを求めていたって事なんだろうな。

インスタント開発がどうこうとかじゃなくて、保守とか設計コストとかの部分でフレームワークを考えるべきなんだろうな。その辺をクリアすれば自然と開発スピードは速くなる。「10分で○○」にばかり目がいって、フレームワークの選別基準みたいなものがよくわからなくなってた。今もどこを見るべきかとかは分からないんだけど、その辺とか誰か解説してくれてたりするのかな。

『制約』によって、開発レベルを階層化する。開発者レベルに従ってどの階層に関わるかを決める。知らなくても活躍できる部分を作る。そうして経験を積んで階層を上って(下って?)いく。横道から入って来た部分があるから、どうも体系立ててどれをどのタイミングで身に付けていいかが分からない。

生産性とか開発効率とか考えると、オブジェクト指向開発・アジャイル開発ってのは有益で、どうしても必要な能力になってくる。ただ、『制約』が増えれば色々と負担が増える事も事実。開発を助けるために生まれた物が開発者を苦しめるってのは問題で、結果的にそうなるならいいじゃないかってのはどうにかすべきだと思う(コーダー的立場からだけど)。で、負担を減らすためには関わる領域を制限すればいい。なので、体系立ては重要。というわけで、その辺探してみようと。

言語ごとにフレームワークの決定版ができる事も重要かな。そうすれば、色々な知識とかノウハウが集中していい事ありそう。symfonyはRailsをPHPにローカライズしたみたいな感じがあったりする。PHPの場合、Zendが用意するみたいな流れもあって微妙な感じもある。統一されると競争が無くなるみたいな事もあるだろうけど、基礎部分では出来る限り知識を共有した方がいいんじゃないかなと思う。あくまで、コーダーからの意見だけど。ただ、Windowsが人気というか売れてるのは、結局「みんな使ってるから」とか「どこにでもあるから」ってのが一番の理由だろうってことを忘れちゃいけない。言語のユーザ会とか取り締まり元でフレームワークを用意する事は現実的じゃないのかな。

『プログラマ』にとってはどうでもいい事かもしれないけど、『コーダー』的な立場にいる自分にとってはかなり重要な部分。ということで、とりあえずつらつら書いてみた。

###
仕事で問題なく使えるライセンスってどれ?GPLはまずいよね?成果物に影響がないやつか。

プロフィール

このブログ記事について

このページは、koshigoeが2005年11月27日 00:02に書いたブログ記事です。

ひとつ前のブログ記事は「Personalizedなやつのモジュールの表現」です。

次のブログ記事は「スタイルとかパターンって重要」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。