簡単にとはいきませんが、インタフェース（実際にはインタフェースっぽい実装なきクラスですが）とそのインタフェースの代表的な実装（特性オブジェクト）を用意しておいて、クラスに実装＋内包させるという方法がひとつ思い浮かびます。

また、ただ単に振る舞いが増えるだけだと実用性に限界がありそうですので、既存の振る舞いに変化が加えられると嬉しいのかな、とも思います。ただ、そうすると、「変化させてもいいよ」というポイントを（少なくとも特性オブジェクトには）公開しないといけませんね。

…というのを CakePHP を見ながら考えました。 attach() メソッドの手法なら C/C++ でもやってやれないことはないのか。

仕事のやつなのでダメな例として公開できないのが辛いところですが、趣味のゲーム制作の前で個人的には助かったかもしれません。仕事のノウハウを趣味にフィードバックし、その逆もまたあるというのが今の生活の良いところかもしれません。

タイトルはですね、別に失敗から学ぶのが嫌とかダメというワケではないんです。ただ、当たり前すぎて声高に言うのもどうかと思うのと、逆に成功から学ぶということに目が向かないんじゃないかと思っておった次第なのです。

結果からしてその基本というやつがおろそかだったなぁ、と思ったのが今日です。

Emacs 23.2リリース、入力補完やクラスブラウザなどを備えたプログラミング支援ツール「CEDET」を標準搭載 – SourceForge.JP Magazine : オープンソースの話題満載

CEDET が標準搭載され、配置するだけで次の機能が使えるとのことです。

• Makefile作成ツール
• コンパイラ実行スクリプト
• 入力補完/支援機能
• ヘルプ/リファレンス参照機能
• 自動コード生成
• UMLダイアグラム作成機能

未確認で申し訳ないです。「こういう仕事は IDE でやればいいや」って感じでいつも進めてしまうんです。ただ、 UML ダイアグラム作成機能というのはちと気になります。

前も同じようなこと書いた記憶があるのですが、なんか仕事が増えたんです。ひとつひとつが特に関連あるわけではないのに仕事が舞い降りてくるという不況とは信じられない世界です。ゴールデンウィークが明けたら少しは楽になりそうですが、疲れました…

今日は他人のソースコードを見ていてラッパークラスの意義について考えさせられました。 DB のレコードを UPDATE してるのに影響を与えた行数が取れないというブレイバーメソッドにはちょっと手を入れる必要があるかもしれません。

気分は BUMP OF CHICKEN のホリデイ。前にも書いたような気がしますが…

BUMP OF CHICKEN の楽曲は抽象クラスやインタフェースのような感じがして心に染み入りやすく思います。実装は自分たちでやりたまえ、みたいな。具体的な内容のほうが理解しやすいんですけど、境遇に合わない部分があると iPod と同期する候補から外れちゃったりしますので、ああいう曲のほうが聴いていて元気になれます。

普段、無償版ばっかり使ってるとわからないのですが、 Visual Studio にクラスデザイナという機能があるらしいです。仕事で使えそうなら思い切って用意してもいいなぁ、と思います。

ちょっとでも効率化できるところはしておかないと時間がもったいなく感じます。

クラスの設計中はクラスの性質を考えようかとも思うのですが、あとから見ると「あ、これは指示か」とか思うこともあります。ほとんどの場合、指示と指示を受けての振る舞いが近いのであんまり気にならないのですが、なんだか性質を考えていることになるのか疑問に感じるようになります。

噂によると、メッセージと振る舞いとを別に記述できる言語もあるそうですが、どんなんでしょう。考えようによっては Windows もメッセージを受けて処理を決定するという点では別に記述しているような気もします（やたら入力を拒否する反抗的なテキストボックスとかも作れるみたいです）。

時間があったら調べてみたいと思います。

現在、アニメーションデータを DB から取得してメモリに格納する方向で考えているのですが、キーフレームに設定したイベントハンドラを実行する方法で悩んでいました。

DB から文字列でイベントハンドラの名前を取得しても、 C++ はリフレクションがないのでどうやってメソッドをコールさせればいいのかがネックだったのですが、とりあえず std::map で、文字列とメソッドへのポインタをあらかじめ格納しておく方向になりそうです。

あとは実用に耐える速度にするためのチューンですが、まずはインタフェースだけ決めてその後に考えます。

パフォーマンスまで考慮すると色々考えないといけないことがありまして、インタフェースをこねくり回しているのですが、後輩に「実装を意識させるインタフェースはだめです」との指摘をいただきまして、インタフェースはすっきり落ち着きました。

んー、もうちょいです。

いや、たいした理由はないのですが、インタフェースを実装した抽象クラスを作りたいことがありまして、なるべく簡素な名前にしたいと考えたとき、インタフェースと抽象クラスの名前がバッティングしてしまったためです。

class Device : public Device // ←おうぁぁあ
{
  // 中は抽象クラス
}

命名の善し悪しはあるでしょうが、とりあえず前に進んでよかったよかった。