| 書籍化されたで！ | 監修したで！(｀ω´) | 絶版なってしもた | 大好評発売中です！ | 少し書いたデ！(｀ω´) | これにもな！(｀ω´) | |
|
|
|
|
 |
 |
| YaneuLabs / YaneuraoGameSDK.NET / 掲示板 / やねうらおにメール / twitter / プロフィール |
MS-DOSからWindows3.1に移行したとき、私はプログラミングを投げ出した。ウィンドゥを一つ出すのに100行近くのソースを書かないといけないし、HANDLEやら何やらもうさっぱり意味がわからなかった。「プログラミングとはこれほど難しいものなのか」と思った。
Windows95になって、OpenGLをいじるようになってからもその思いは拭えず、依然、HDCが何かもよくわからないままプログラムを書いていたのをよく覚えている。Windowsのそういった呪縛から逃れるためにDirectXを勉強しはじめ、BM98を作った。当時はオブジェクト指向設計にすらなっておらず、OOPが分からないのでC++を単なるbetter Cとして使っていた。まともなオブジェクト指向設計が出来るようになったのは、そのずっと後になってからである。
そんな暗中模索の状態だったが、「動くプログラム」は書けた。そもそも私は機械語あがり(アセンブラもなしで16進数で入力していた世代)なので、すべてがグローバル変数だろうが、関数という概念すらなかろうが、「動くプログラム」を書く方法は、自分の体が知っていた。だけど、それは我流で旧式の間違ったプログラムなのだと信じていた。「自分はこういうプログラミングしか出来ず、世間のプログラマのレベルに追いついていない」のだと思い込まされていた。
それは半分は当たっているのだけれど、半分は外れていた。OOAやOODを重視し、クラス設計を行なう人が、まともに「動くプログラム」すら書けないことが現実的には多々ある。「動くプログラム」が書けないのでは当然お金はもらえない。そういった業界の不思議に直面して考えが変わった。そもそも現実世界をソースコードにモデリングすることなど出来ないし、そもそもモデリングすることにどのくらい意味があるのだろうかと考えるようになった。
id:akirameiさんは、次のような(皮肉な)例を挙げている。
ナップザック問題を解くのに、ナップザックやら缶詰やらのクラスを作って 「さぁ、モデルは出来た。あとはコードに落とすだけだ」
確かにどこかおかしい。でも、実際、OOPのブームのときには、そう本気で考えている人がたくさん居たし、私もどこかそういうお祭りに踊らされていたのかも知れない。
もしくは両方出来るように努力するとか。
我流で「動くプログラム」を書けるって凄いな。
就職してからだなあ、まともに動くプログラムを書けるようになったのは。
できる。というか、オブジェクト指向でなくとも多かれ少なかれ、これはやっている。
> そもそもモデリングすることにどのくらい意味があるのだろうか
オブジェクト指向の最大のメリットは「わかりやすくなること」だと思うので、それが個人的にわかりにくい、そんなことしなくてもわかると言うのだったら、しなくても問題ない気はする。
ただし、そういう「職人技」を、自分以外のみんなが理解できればだけど。
＃俺って青い？
> そもそもモデリングすることにどのくらい意味があるのだろうか
解きたい問題や作りたいプログラムについて、どのようなデータの塊(クラス)や振る舞い(メソッド)から構成されているか想像もつかないものなら、その問題やプログラムを理解するためにモデリングする意味はあると思います。
ただし、あくまで理解のためなので、ナップザック問題の例えでいえば、モデルを作って問題に対する理解が深まっただけで、問題の解き方が分かったわけではないのです。
本当はコードに落とす前に、問題の解き方を考えないといけないので、「あとはコードに落とすだけだ」というのがおかしいのです。
つまりモデリングで問題を理解したからといって、すぐに解決(プログラミング)できるとは限らないわけで、解決(プログラミング)はまた別の能力だと思います。
ややこしいのは、「モデリング」に「解決方法のモデリング」も含めて言うこともあることでしょうか。世の中にあるモデリングやUMLの本は「問題のモデリング」や「既に分かっている解決方法のモデリング」ばかりで「問題のモデリング」から「解決方法のモデリング」をどう作るか書いてる本はほとんどない気がします・・・。
モデルには２種類、分析モデルと設計モデルがあって、
> 問題やプログラムを理解するためにモデリングする
これは分析モデル、
> 解決方法のモデリング
これは設計モデルなんじゃないだろうか。
ウィンドウ出すのが面倒でプログラム渋ったり、何でもクラス病にかかったり、単一関数嫌い病になったりと、色々発病して動くプログラムが書けなくなりました。
今は昔より知識、経験ともに増えたはずなんですが、なんか扱いにくいんですよね。
このエントリーを見て昔のスタイルに戻そうか検討してみようと思います。
きっかけを与えてくれてありがとうございます。
「オブジェクト指向は現実世界をそのまま表現できる」なんて売り文句は大嘘ですね。そもそも「表現」に「そのまま」はあり得ないので。
そのままではなく「現実世界を適切に抽象化して表現できる」が正解かと。「現実世界を表現すること」自体が悪いのではないと思います。
＃どこが青いか突っ込んでくださると幸い
私はOOPの「最大のメリット」は再生産性にあると信じてはいるのですけども、ただmix-inやAOPやmetaprogramming,etc..を使わないようなpureなOOPだけではまともな再生産性のあるmoduleが作成できないこともあるので、pureでないOOPにおけるOOPの役割について議論したりしないといけないと思うんですけれど、(普通にOOPの役割を議論してしまうとpureなOOPとpureでないOOPをまぜこぜになって)議論のfocusがあやふやになってしまうんですよね。
少し気になりましたので、突っ込みを入れますと、
＞「現実世界を適切に抽象化して表現できる」
「適切に」はちょっと言い過ぎですね。「他の表現手法より強力で汎用的な表現手法として広く認められている」のがオブジェクト指向かと。
# もしかしたら認めてない人の方が多いかもしれませんが・・・
UML図にもオブジェクト指向以外の考え方から取り入れた図(ユースケース図やステートチャート図など)もありますすし、「適切に」抽象化するためにはオブジェクト指向以外の表現手法を取り入れた方が良い場合もあるはずです。聴いた話だと、通信プロトコルみたいな状態遷移が複雑なものの設計には、オブジェクト指向の考え方はあまり役に立たないとか。
現実的には、やねうらおさんのおっしゃるように、OOPの再生産性を利用するためにオブジェクト指向を使って分析・設計・プログラミングするということの方が多いのかもしれません。
ちょっと言葉がまずくて伝わらなかったぽい。「オブジェクト指向なら適切に抽象化できる」って言いたかったんではなくて、うーん…「適切に抽象化すればオブジェクト指向が適用できる」とでも言うのかな。とにかく「そっくりそのまま再現」はできないよね、てこと。
その場合、「一体、オブジェクト指向では何が再利用できるのか」ってのからして、自分の中で決着がついていない。
いやー、対象領域によっては、むちゃくちゃでかいんですけど..(´ω`)
たとえばC++でfunctorを使ってinliningしないとまともなパフォーマンスが出せない画像処理(e.g. http://www.sun-inet.or.jp/%7Eyaneurao/intensive/diw2.html)があったとして、このとき、templateが無ければライブラリとしての機能要件を満たせないのです。C言語でこれと同じことをするのは不可能ですし、pureなOOPだけでこれと同じことをするのも不可能です。
つまり、この画像転送処理は、OOPがtemplate機能と組み合わさって初めて達成できることです。
同様に、moduleのような機能体の集合を用意したいと考えるとき、クラスに分断的にinjectionしなければ書けないことがあって(たとえば、デザパタのvisitorパターン)、これを実現するためにはAOPか言語がそれに近い機能を持つ必要があります。(このへん議論が長くなるので割愛)
mix-inについては近々「mix-in in C#“2.0”」という記事を書くので、今回は割愛。
つプリプロセッサ
おっしゃりたいことは分かりました。どうやら微妙な表現に突っ込んでしまったようですね。
確かに「オブジェクト指向だとどう抽象化して表現できるか」を短く言うのは難しいですね。ちょっと苦しいですが「オブジェクトとその間の関係で表現できる」とか「オブジェクト指向言語に適した形で表現できる」とかでしょうか・・・
そのように対象を限定してしまうと、そもそも OOP が向かない分野ってのもあるわけで…例の画像処理だと、全体に占めるオプションの割合が pure OOP より多くなってませんか？ そういう分野だと、そもそも pure OOP の方がオプションになってしまっていて、OOP の議論のネタとしては適さないような…
pure OOP とオプション付 OOP のどちらの話をしているのかを明確にするのは賛成ですが、まず pure OOP について議論して、ベースを作らないと、オプション付 OOP の話はできないですよね。