ブログのデザインを変更しました。
今回はあまり凝ってません。
ま、雰囲気を感じ取っていただければと。
July 30, 2006
MVC に関する疑問
MVC に関する疑問がいくつかある。
ひとつは、Javaサーブレット等におけるMVCについて。
もうひとつは、JavaのSwingの仕組みにおけるMVCについて。
Javaサーブレット等におけるMVCって、あれはちょっと本来のMVCとは違うよね。
本来のMVCってのは、Smalltalk界隈で言われるアレ。「ViewはModelを知っており、Modelの操作はControlerを介して行われる」とかいうやつ。
↓こんな感じ？
JavaサーブレットというかStrutsとかにおけるMVCって、ControlerがViewとModelの仲立ちしてるだけやん。
↓こんな感じ？
ていうか、Webアプリってそもそもアプリケーションとして特殊だよなぁ。
なんでこういうことを考えてるのかっていうと、周りの人の話を聞いてて、MVCに対する考え方が僕とはすこし違うなぁと思ったのがきっかけ。
ま、何が良くて何が悪いとかの問題ではなくて、単に、MVCに関して他人とあきらかに認識のずれがあるんだけど、どのへんがずれてるのかがわかりにくくて気持ち悪いなぁ、という程度のことなんだけど。
MVCはどうでもよく、重要なのは、データーを表示するときの流れとデータを操作するときの流れのそれぞれの方向に関して決めたルールにちゃんと則ってプログラミングしましょうね、ってことか。
参考:
MVC、これでいいのか？
バスケの Smalltalk MVC に対する違和感
Model View Controller - Wikipedia
…
閑話休題。
JavaのSwingにおけるMVCなんだけど、あれのせいでGUIコンポーネントが使いにくくなってる部分があるよなぁ、と最近思う。
Swingのアレも厳密には本来のMVCとは違うみたい。
ま、それはいいんだけど、Swingってどうも直感的じゃない気がする。
ちょっとしたコンポーネントにさえModelってのがいて、データの操作はいちいちそのModelに対して行わないといけないとか。
例えば、テキストフィールドの文字がユーザーの入力により変化したときのイベントをハンドリングしたいときなんか、わざわざそのテキストフィールドのModelに対してリスナーを追加してやらないといけない。
Modelというものがあることで嬉しいこともあるだろうけど、めんどくさいことの方が多いような気もするんだよなぁ。
でもJTableとかは、やっぱModelとViewが分離してた方が良いよなぁ。
ていうかSwingって、「なにか不便なところがあったら自分で拡張してよろしくやってください」的なノリな気がする。
どのコンポーネントも見た感じ完成まであと一歩って感じだし、やっぱそういうことなのかも。
でも、なかなか良く考えて作られていると思う部分も多々ある。
とりあえず、一通りマスターしたい。
UMLに関するメモ
だらだらメモ:
■変なUML
独自に拡張したような感じの、変なUMLを描く人がいる。
そういう人は、「もしかするとこれはUMLじゃ表現できないものかもしれない」ということを考えてみるべきだと思う。
もしくは、まず非UMLな図で表現してみて、それをUMLに落とし込んでいくのが良いやり方かもしれない。
でも人に見せる時は「非UMLな図」の方が伝わったりする。
絵の上手い下手にもよるけど。
■非UML図を描く時の注意点
非UML図を描く時は、混乱を避けるため、UML に見えてしまわないように気をつける。
■UMLよりもわかりやすく、誰にでも理解できるツールがある
「文章」がそれ。
文章でストーリーを書くと、動きをイメージしやすくなる。
…
以下、かなり想像および妄想入ってます:
■UMLが嫌いな理由
おそらく僕はUMLが嫌いなんだと思う。
どこかの誰かが勝手に決めたことに従わなければならないのが我慢ならないんだと思う。
UMLの思想が気に食わない。
広い範囲をカバーしようとしすぎ。欲張りすぎな気がする。
クラス図とシーケンス図以外はほとんどまともに使ったことがない。
クラス図とシーケンス図に関しては「発明しれくれありがとう」と言いたい。
ていうか、元ネタはこれらできる以前にすでにあったのかな。
今のところUMLには、ソースコードを図に置き換えるぐらいの用途でしかその価値を見いだせない。
ソースコードを図で正確に表せるというのは本当に素晴らしいと思う。
例えば、継承関係を表現するのにクラス図の表記法以外のやりかたは思いつかない。
でも逆にUMLは、ソースコードから離れたところではあまり使い物にならない気がする。
いや、使い物にならないというか、使うメリットがない。
UMLを駆使した基本設計書とかあったとしたら、うーん、見たくない。
結局、UMLはプログラマ同士のコミュニケーションにしか使えない。
それに、プログラマ同士のコミュニケーションにおいてもUMLが有効な範囲は限られてくる。
結局、あるクラスの動きを知りたければJavadoc等を読むことになるし、もっと詳細が知りたければソースを読むことになる。
また、クラス図はクラス同士の関連を表すのに便利なんだけど、Eclipse等の高機能なIDEを使えばだいたいの関連はすぐに把握できてしまう。
詳細なクラス図を見れば、クラス同士の関連がソースコードに近いところまでかなり把握できるけど、やっぱそれにも限界があって、その先はソースを見るしかない。
ま、実際にはクラス図だけを見るなんてことはなくて、それを補足するための文章があったり口頭での説明があったりするんだけど、実はその文章なり言葉なりの方が重要だったりする。
クラス図はたんなる補足資料というわけ。
逆に、クラス図だけを見て、言葉による補足なしにその意味をちゃんと理解できるのかなぁ？って思う。
■UMLの良いところ
UMLによって、多くの人が「絵で表現することの重要性」に気づいた。（多分）
■UMLはアーチストには向かない（戯れ言）
えー、僕は自称アーチストなわけですが、そいう人間にとっては、UMLは表現の幅を狭めるだけのものでしかないわけでして。
で、なんと言いましょうか、アーチストは壁をぶち壊すことも時には必要ですし、そのとき、既存の枠組みは単なる足かせでしかないわけでして。
■道具としてのUML
人は道具によって思考が制限される。
なぜなら、ある道具使い始めると、その道具によって表現可能な方向でしか思考を展開できなくなるから。
人はそういった思考パターンに簡単にハマる。
例えば、Java しか知らないプログラマは、Java の流儀でしかプログラムを考えることができないと思う。
それ以外の可能なプログラムというものを知らないから、想像しようがないのだ。
そういう意味で、UMLは人間の思考をすごく制限してしまう道具だと思うのだ。
クラス図に登場するクラスの箱にメソッドやフィールドの情報が大量に書かれているのを見るのが嫌いだ。
絵で表現できることはたくさんある。
確かに標準化や統一性というものは大事だけども、コミュニケーションにおいて一番重要なのは「最短時間で相手に伝わること」だ。
UMLは、ほとんど箱と矢印で成り立っている。
あと、UMLで書くと特徴のない絵になる
正直、どれもぱっと見ただけだと同じに見えてしまう。
色をつけたりすれば良くなるかもしれないけど、変な小細工は混乱の元になりかねない。
July 29, 2006
DI を使い始めると、なんでもかんでもやたらと DI コンテナで管理したくなってくる
想像:
多くの人は、DI を使い始めると、なんでもかんでもやたらと DI コンテナで管理したくなってくる。
そしてやがて、設定ファイルがソースコードよりも長大になる。
…
というのは冗談だけど、どこまでが「設定」として切り出すべき部分なのかという見極めがすごく重要。
こういった能力は DI 以前にも重要だったはずで、DI はそれをやりやすくしてくれるんだよね。
つまり DI は、アーキテクト的な人が今まで苦労していた部分を簡単にしてくれるわけで、基本的には、今までやってこなかったようなことをやる為のものではないはず。
July 27, 2006
DI の設定を XML じゃなくスクリプトでできるようになれば、
DI の設定を XML じゃなくスクリプトでできるようになれば、きっと便利。
アレがスクリプトで書けるようになれば、誰も XML なんて使わなくなるよ、きっと。
Mustang でスクリプトが動かせるようになるみたいだけど、どうなんでしょ。
DI の設定ファイルをせかせかと書いてる人が、あるときはたと気付く。
「XML によるプログラミングのなんと非効率なことか！」と。
ま、しかし、ID コンテナはなかなか便利だと思うし、現状としては一番現実的なソリューションだと思う。
下手に ID コンテナを導入したことによる失敗事例を見てみたいなぁ。
…
話はすごく変わるけど、最近、やたら Java の Swing に詳しくなりつつある。
知れば知るほどおもしろい。
JTable とか、だいぶわかってきた。
いろいろ考えられて作られてるんだなぁ、って思う。
慣れないと使いこなせないけど。
しかし、いつ見ても気持ち悪い Look & Feel だ。
July 25, 2006
Ruby で DI とか、Java のインターフェイスとか、ユーザーインターフェイスとか
メモ:
「Ruby で DI 的なことをやろうとするとこんな感じになりますよ」的なサンプルが見たい。
AOP 的なことも簡単にできるんだよな、確か。
そういえば、ちょっと前に読んだこの記事がいろいろ参考になった。
IBM 境界を越える: Javaモデルを超える型定義戦略 : Java : dW - Japan
ここから先はすごく感覚的な話になるんだけど、なんだか Java って、もう限界にきてるんじゃないかなぁ。
言語的な限界にぶちあたってるんじゃないかなぁ、と漠然と思うわけ。
Mustang でどうなるのかは知らないけど。
Groovy による Rails クローンの Grails とかいうのもあるみたいだけど、どうなんだろう。
参考: 【ハウツー】JavaだってRubyに負けちゃいない - JavaでもRails クイックスタートGrails (MYCOMジャーナル)
確かに、真似すれば同じ物は作れるけど、例えば、Rails が生まれなかったとして、10年待っても Java から Rails 的な物は生まれてこないんじゃないか、とか思う。
言語が違うと、何かを作ろうとするときの考え方がそもそも違ってくるんじゃないかなぁ。
こんなの見つけた。
表紙がイイ。
Second Edition か。
…
できるだけ初めに多くのことを決めておこうとするやり方が、僕はあまり好きになれない。
具体的にどういうことかというと、がっちがちに固められた自社製フレームワークとかが嫌い。
いや、別に初めからがっちがちにするつもりなんてないんだろうけど、かなり才能のある人が作らない限りはフレームワークって自然にがっちがちになっちゃうだろうし、ていうか、そもそも初めからすべてを予測するなんて無理だから、プラグイン的な機能を持たせるとかしたらいいんだろうけど、そのへんをきっちり整備するのはすごくコストがかかるし、そもそもそこまでの物が必要とされているのか？って話もある。
あと、Java のインターフェイスも、初めにちゃんと決めとこうとするやり方のひとつだよね。
Java 界では、インターフェイスによるプログラミングが良いとされている。
ま、あれはあれで便利なんだけど、DI を活用するとインターフェイスが増えまくってうざい。
なんでもかんでも DI で、なにか作るときはとりあえずインターフェイスから作って、とかいうふうになってくるとめんどくさい。
IDE 使わないとやってられない。
インターフェイスの恩恵をうけつつ、その存在を意識しなくてすむようなソリューションはないのか。
DI の話にもどる。
DI を使ったからといって、何かが劇的に良くなるなんてことはないと思う。
DI を使ってもダメなシステムはダメだし、DI を使わなくても良いシステムは良い。多分。
なんかありきたりなことを言ってしまった。
システムには、他にもっと改善すべき所がたくさんある。
特にユーザーインターフェイスとか。
どんなにすごいシステムを作っても、ユーザーインターフェイスがダメだとユーザーに敬遠される。
あ、そうそう。
僕はこれからユーザーインターフェイスの勉強をしていこうと思ってる。
ユーザーインターフェイスデザインの仕事でメシを食っていけるようになることが目標。
いつのまにかユーザーインターフェイスの話になってる。
July 23, 2006
