meg_nakagamiの日記スマートフォン用の表示で見るmeg_nakagamiの日記この広告は、90日以上更新していないブログに表示しています。いう値が書いてあって、それを読み出して拡張機能の有無を変更しなければいけないとします。取ってくるものとします。いうのを何も考えないプログラマがこういうのを作るとこんなかんじでしょうかね。ここで拡張機能をなんとかする。}とりあえずこれで問題はないかもしれません。これだとおそらく半年ぐらいたってから、『EnableExtentionの設定が効かない』といって問題になります。書かれていたりします。これを『そんな想定外の値を書くほうが悪い』とか、わけがわからないことをプログラマが本当に言い出すからたちが悪いです。誰が悪い、とかじゃなくて、現に問題が発生しているのだから、それはプログラマが責をおうべきです。私に言わせりゃ『そんなことすら想定しないオマエがわるい。』ちょっと考えてこうするとします。クラスがあるものとします。問題はなくなります、が、どう考えてもソースコードの可読性は落ちました。一見して何をやっているかがわからない。いうクラスがある想定だったり、一度変数に入れているからまだいいほうです。)こういう人がプロジェクト内に一定以上いたり、ごく一部でもその人がよくわからない政治的な力を持っていたりすると『細やかな考慮を行うとソースコードの可読性が落ちる』というイメージが浸透してしまいます。何も考えていないわけですから、それを表立って言うことはないのですけど、漠然としたイメージって大きいです。ライブラリ作成者としては、世の中の大半のプログラマがこういうコードを書いてしまうことや、それによって問題が発生してしまうことは現に予測可能なわけで、誰が悪い、とかじゃなくて、それはライブラリ作成者が責をおうべきで、そんなことすら想定しないライブラリ作成者がわるい。弄れないとして)一旦クラスに*1入れて、そういう関数を作りましょう。}比較的わかりやすいです。読みとるもの』としては考慮が甘いです。FASLE(FALSEの間違い)だったらどうしましょう?真じゃなかったら偽、で問題ないでしょうか?偽じゃなかったら真としたい設定もあるはずです。すると、こうなります。};で、ここで『デフォルト値』という概念が出てきたしまったので、考慮すべきことがちょっと増えます。プログラマが値を取ってくるたびにデフォルト値を意識しないといけないようにすると、それを間違える可能性があります。←第二引数を忘れてる。}これを回避するためには、『デフォルト値のマップ』みたいなものをもたせて、正規の方法で取れなかったらそっちから取ってくるようにして、プログラムの初期化時にデフォルト値のマップに一通り値を入れておく、とか。プロパティーのキーの方を何らかのオブジェクトにしてしまって、それ自体がデフォルト値を知っているようにする、とか。厳密に設定させたいのなら起動時に一通り設定をナメて、想定外のものだったら例外吐いて落とすような機構を作ってしまってもいいかもしれません。その場合その『想定』をなんらかの言語で表現しなくてはいけない煩雑さが出てきますし、予め用意したキーしか使えないことになります。それは『厳密にする』という意思決定から来るトレードオフなわけですけど、それが良い場合もあるし、悪い場合もある。一時期の『何でもXMLで設定すりゃいい』って言うような風潮は、このトレードオフをちゃんと意識して決定しているとは言いがたいものでしたね。人間って極端に走りがちで、こういう問題を発見すると『○○を導入してその問題をすべて潰そう』とか、やっちゃいがちで、一時期のJavaコミュニティのXML偏重とかはその最たるものだったと思うんですけど、変な話なんですが、こういうのってどんな機構を導入しても『考えなくていい』ということにはならないんです。何が最適か、ということはそのプロジェクトやモジュールの性質によって違う*2。いうトレードオフを考えないで『○○を使ってるから○○は全部OK』とかやるのは問題を先送りするだけです。(それでも何も対策しないよりは100倍マシなんですけど)考えなくてはいけないことがあるならばそれは考えなくてはいけない。上手に考えることで、特定の領域においてはそのことを忘れていいようにプログラムを持っていくことは可能で、ライブラリを作る人はそれを目指していくべきなんじゃないかなって思います。