Joel on Softwareで紹介されていたGUIライブラリも考察する

何回もJoel on Software
http://www.amazon.co.jp/exec/obidos/ASIN/4274066304/studiokingyo-22
を元ネタにしていろんな事を書いてきているが、今回もそれだ。
Joel on Softwareには今まで私がプログラミングしていく上で悩んできた事の殆どすべてを一刀両断している点がすばらしい。
偶然にもJoel氏が経験してきた事としてアドバイスしている点が私が悩んでいた点と一致するのが自分が思っているより多い所に少々驚いている。
プログラミングしていく上で通る道なのだろうか?
さて、そうだとしたら今回もそれも通る道の一つである「最強のGUIライブラリ」という漠然とした、
しかしながら多数のプラットフォームでGUIAPIを叩いた者であれば願ってやまない概念であるマルチプラットフォームGUIライブラリである。
今まで

最強のGUIライブラリを再考する

にて多数のライブラリを紹介し、チュートリアルソースコードを見て*1の私なりの感想を述べたのだが私は未だに「最強のGUIライブラリ」と言える物に出会った覚えが無い。


さて、そんな所にJoel on Softwareの「第27章 プログラミングにおけるロード・パーマストン問題について」にて
以下の三つが紹介されていた。

この中でどのライブラリが「最強のGUIライブラリ」かどうかはJoel on Softwareでは語られていない。
各ライブラリを1-2年、必死になって使ってようやく本当のメリット、デメリット、そしてこの体験による公理を知る事になるのでは との見解が示されている。
これに則った場合、私は安直に「これが最強のGUIライブラリだ!」という事は出来ない。


今まで、私が
Fox-toolkit http://www.fox-toolkit.org
を贔屓してきたのだが、私が使っていた当時、ドラックアンドドロップが実装されていない点に失望してしまい、FreeBSDLinuxでソフトウェアを動かす機会が(そして機械が・・・)無いという理由も後押しし、それ以降はもっぱらgoogle:WTLに走っている。
最終的に

に惹かれ、今、C++にてGUIを使うプログラムを組む場合はgoogle:WTLを使っている。


今、考えてみると先のことまで見越してGUIライブラリを選り好みする事はソフトウェアを完成させるという目的を達成する事において愚かなプロセスだったのではという見方が強い。
しっかりと他のOSやGUIライブラリを使用するという事を念頭においてソフトウェアのビジネスロジックを設計すれば既存のGUIライブラリにソフトウェアのビジネスロジックを埋没しないように組む事*2も可能ではないかとも感じるのだ。
素直にMFCでも*3使って迎合していればソフトウェアのビジネスロジックに時間をかけることができ、いろんな意味で貢献できたのではないかとも考えてしまう。


今後、以上のような方針でソフトウェアを組んでいく予定だ。


今まで、「最強のGUIライブラリ」という幻想に取り付かれ様々なGUIライブラリのソースコードを読み、ある程度の設計や構造を理解したという経験はこの問題に取り組んで得た唯一の良い結果なのかもしれない。

最後に断っておくが
「最強のGUIライブラリ」という命題について考える事をあきらめてはいない。
ソフトウェアを完成させるという目的を達成させる事を最優先事項とした場合、ビジネスロジックを書き下す事を最優先にするべきだと提案する次第だ。
そのロジック自体を十分なテストも行っていないうちにGUIライブラリを選り好みし時間を浪費する事は非効率的であるのではないかとの見解をここに記す。

*1:設計などの細かい点までは見ていない

*2:例えばMFCのOnPaint()内に直接コード書き下さずに別のファイルに記述してある関数を呼び出すなど

*3:今の時代であればC#.NET frameworkあたり