かにの泡ぶく

_ あ"〜、パニック楽しい。

うん、やはり自営業フリーエンジニアはこうでなくてはいかんな。

_ C++でのクラス間独立性維持の落としどころ。

普通そうだと思うけど、あるシステムを開発する際には、まず、要求仕様を満たすために必要なシステム全体のトポロジーを整理し、モデリングして各オブジェクトを極力抽象化する。このへんは言語非依存。

その後、データ構造設計とビジュアルヒエラルキー、周辺IOを整理し、クラス設計を行なう。

ここまでは良い。

さて、ある程度実装が始まり、システムのパフォーマンスチューニングの段階に入ってくると、高速化を実現するためにはどうしてもクラス間の独立性を捨てねばならない箇所が出てきて、せっかく抽象化したクラス設計内に、突然泥臭い直接参照が発生したりしてしまう。

これはね、個人的には永遠の課題だと思っている。

過去には、関連のありそうなクラス間の通信を調停するための、CArbit classなんてのを作って多重継承させ、メッセージのbroadcast / listen構造を構築してみたり、shared buffer classみたいの作ってメモリマップでダイレクト通信してみたりしたこともあったのだけど、結局見通しが悪くなってしまい、かつ、あまりオーバーヘッド解消にもならなかったりして、いまいちインパクトに欠ける結果に留まっている。

ここ最近では仕方ないので、最後の最後まで抽象化は崩さず、どうしてもどうしようもないときになってから、あっさり直接参照による現世に著しく依存した実装を入れ込むようにしている。

はじめは自分の内で、『美しく抽象化推進者』と『動けばいいじゃん高速実装優先者』の二人が戦っていたのだけど、やってみると、注意深く慎重にモデリング設計されたプロジェクトであれば、チューニングの段階で多少現世に依存した実装が入れ込まれたとしても、全体としてのコードの持つ性質、美しさ・・・しいては見通しの良さ、メンテ性の良さはほとんど失われないということがわかった。

私が歳とって人間丸くなっただけっていう話はぜひ無しという方向で。