脳log[20131130]

2013年11月30日 (土) [SakuraEditor] 『API design for C++』の日本語版を読み終わった。学ぶところは多いし(特にバージョニング/互換性。ユーザーコードを破壊しない(再コンパイルさせない)ために何ができ何を避けるべきなのか)、何よりばらばらに持っていた知識を APIデザインという一本の筋にそって整理してくれたところに価値を置く。APIなんて利用するだけだからと考えてはいけない。クラスを作成するときには必ずクラスの利用者の――目的やユースケースに従ってブラックボックスを操作する者の――視点が必要になる。APIとはインターフェイスでもあり、public(クラスの外に公開)や protected(派生クラスに公開)のメソッドでもあり、ヘッダファイルにプロトタイプ宣言が置かれた関数でもある。絶対に無関係ではいられない。■テクニックだけでなく新たな視点を与えてくれるという点で『大規模 C++ソフトウェアデザイン』を思い出したし、実際ラコスは何度も引用されていた(※２冊の提供する視点が同じということではない)。あんまり UMLとかを使う方面に深入りしないのも共通で、安心の C++本。■最後の最後に CRTP(Curiously Recurring Template Pattern)が出てきた(これはテクニックね)。静的な(コンパイル時の)ポリモーフィズム。実装を伴うインターフェイスクラスとしてミックスインクラスとも解釈できるとあった。サクラエディタで機能拡張のなれの果てともいえる Viewクラス(といってもヘッダで 31KiBだからかわいいもんか)をどうやって実装できたかという思考実験で、一番に思いつくのがこの CRTP。■Viewの特性や機能(範囲選択できる。選択した範囲に基本的な操作(置き換え/コピー/切取/貼付)ができる。検索できる。文書(文字列/バイト列)を視覚表現に変換できる。色分けできる。ファイルをドロップできる(のはウィンドウクラスかも)。ブックマークできる)をミックスインクラスとして独立して実装する。Viewはこれらのミックスインクラステンプレートを自身をパラメータにインスタンス化し、これを継承する。ミックスインクラスがテンプレートパラメータを通じて Viewの機能にアクセスできるのはもちろん、試したことはないけど、他のミックスインクラスが Viewにもたらす機能に依存して独自の機能を実装することもできるのではないかと思う。■個々の機能を個別のミックスインクラスとして実装する利点は、自身の管理するデータ、依存する機能、それらを組み上げて実現する単一の(またはひとまとまりの)機能にフォーカスできること。■こういう機能拡張のフレームワークはできるだけ早い時期に確立しておきたいものだ(あきらめてら)。■■■どことは書かないけど……ネクスサス７……。「Deffered」も気になってたんだよね。検索したら２番目が目当てのサイトだったんだけど、１番目がまた見事。「Common misspelling of deferred.」Commonでした。そして別のサイトだけど、Deffered、Defferedときてからの Deffred(デフレッド)、Deffered. 正解は出てこない。一貫性もない。この有様では苦労するでしょうな。