Winアプリさらにその後と、ライブラリの方針

こんな感じで標準コントロールは置けるようになった。
コンボボックスだけは置けるだけで機能はからっぽ。
ソースは長くなってきてしまったので割愛。

グループボックス内のラジオボタンも、グループボックスをサブクラス化して親ウィンドウにクリックメッセージを流すようにしたから、フォーム上で受け取れるようになった。
WS_GROUPスタイルは気持ち悪いので使いたくない。

このようなものを作っていて、世の中のライブラリにはその設計方針がいくつかある、ということを考えていた。
具体的にはこんな感じ。
(a) とにかく多機能、できないことは無い
(b) 多機能であり、内部情報・設定を公開し、自由に設定して使える
(c) シンプルに手段だけを提供
(d) 機能を絞って使いやすさを追求

(a)のライブラリは機能が多く、やりたいことはほぼできるが、それを探すのが大変。使っていればよく使う機能とかも見えてきて使えるようになるタイプ。例えばRubyの標準ライブラリや、Miyakoみたいな感じ。
よく使う機能とそうじゃない機能が同列に並んでいるとどれを使えばいいのかわからなくなるから、そのあたりを工夫すると使い始めがグッと楽になる。
(b)は設定による挙動を理解できればかなり自由度が高い。DirectXなんかは構造体や引数がアホみたいに多く、どれをどう設定すればどのように動くのかが把握できない。
ゲームとかと同じで、何をどうすればどうなるのかが理解できてくるとヤバいぐらい楽しくなる。(a)と比べるとユーザーの理解を求めるかわりに自由度を提供しているといえる。
(c)は例えばRubyのWin32APIみたいな感じ。仕組みだけ提供されていて、その先の仕様を理解しないと使えない。この手のものは「あること」が大切だ。
(d)は一長一短。DXRubyがこのタイプ。DirectXを扱うといいつつ、そのほとんどの機能は使えない。その代わり、ターゲットとしている使い方に限定して、非常に簡単なアクセス方法を提供する。
内部で難しいことをしていたとしても、その仕組みは内部だけで使い、外に公開はしない。見える部分が簡単であれば、使い方は簡単なのだ。

ありがちなのは「メモ帳がこんなに簡単に作れます」みたいなチュートリアルを用意して、メモ帳以外はどう作ればいいのかわからない、というもの。
MFCがそんなんだった。
簡単な部分があっても、難しい部分が存在していては、それは使いこなすのが難しいライブラリになる。
全てが簡単ではじめて、簡単なライブラリになりえるのではないか。
たとえそれが、あまりにも機能が少なかったとしても。

Winアプリ簡単ライブラリ(仮名)は、現時点ではコントロールのメッセージはほとんど扱わない。
例えばボタンはクリックだけ。提供する機能は移動・サイズ変更・キャプション変更・enable・visibleぐらい。
メッセージを色々扱えばそりゃあ色んなことができるだろうが、使わない機能をてんこ盛りにしたところで意味は無い。
そういうシンプルなものは、とりあえず使うには楽だし、導入にはよい。
DXRubyもターゲットはゲーム開発初心者。とりあえず作ってみて感覚を身に付けるのにはよい。
もっとすごいことがやりたければ、もっと高機能なライブラリに乗り換えたり、C++などでDirectXを直接いじるようにすればいい。
そう考えると機能を詰め込みすぎたかもしれない。
どうも俺は(d)なタイプのライブラリを作るのが好みのようだ。