Literate Programming プレファクタリングの本で紹介されていたサイト。言語あるいはソフトウェアで設けられているコーディング規約 (コーディング標準) などがまとめて掲載されています。なぜか Doxygen のマニュアルなんかもある。コーディング標準は知っ…

はてなダイアリー (via 2006-04-06 - カレーなる辛口Javaな転職日記) しかし、APIを決める時はDesign by Contractで考えるのが普通だとわしは思っていたのだが、なんと職場の周りの人間は、ほとんどの人間がこの単語をよく知らないようだ。マジかよ、、、(ﾟД…

SomethingManager - Radium Software Development クラスの名称をなんたら Manager とするのは良くない、という話。以前にも似たような趣旨の話を見かけた記憶があるのですが、どこだったか思い出せません。とにかくまあ、前回読んだ時にも気をつけようと思…

似ているけれど微妙に違う二種類のクラス扱うクラス (ややこしいな) の中で、いま扱っているクラスがどっちなのかいちいち調べて分岐している部分があって、これをひとつにまとめよう、と思ったけどどうも微妙な違いが微妙に邪魔して無理っぽくて落ち込む。…

実装を後から追加していくような仕組みにすれば、多重継承は要らなくなるパターンもあるかな。あとからインターフェイスの変更が行えない場合は、このやり方がよさそうだ。まあ、全てのパターンで最善となるような答えなんてないのだろうし、適材適所で使う…

継承→委譲→多重継承 (Mix-in) と来ましたが、これは結局継承に出戻ってしまったということなのだろうか、と少し悩んでます。インターフェイスの継承と実装の継承を切り分けて考えればいいのかな? インターフェイスの継承には継承 (多重継承) を使って、実装…

結局、さっきの案で実装しました。 GetCapsule メンバ関数はマクロとして define しておいてそれを記述する形にしてみた。 Loki の Visitor のパクり。結局あれを無くす方法も思いついていない以上、この良い解法も簡単には出ないだろう、ということで。今の…

現状こんな感じ。 // Base.h struct IBase { virtual ~Base() {} }; struct IHoge { virtual void hoge() = 0; }; // Impl.h struct BaseImpl : public IBase, public IHoge { virtual void hoge() { /* ... */ } }; // Client.cpp #include "Base.h" void m…

巡りめぐっていま頭の中にある構想を実現するには Capsule パターンがいいのではないか、というところまでたどり着きました。 しかし問題は、 Capsule 型の変数 (ポインタ) を返す f() をどこに置くかだなあ。

アプリケーションの色々な箇所で使用する設定を構造体なりクラスなりにまとめて保持させたときに、設定は常にひとつだけにして、どこかでとある設定に変更が加えられたら別のところで参照している設定にもその変更を反映させたい、とする。こういった時には…

Visitor パターンの欠点というか、面倒な要素のひとつとして、 ConcreteElement の全てに Accept メソッドを用意しなくてはならない、というものがあります。基底クラスでこれをやってしまうと、 Visitor クラスに渡される型が全て基底クラスのものになって…

色々な図形を描画するアプリケーションを開発しているとします。この図形を描画する処理を、まず抽象クラス Shape を用意し、それから実際の描画処理を派生クラスで実装しようと思ったとき、以下のような実装を行いました。 class Shape { public: Shape() {…

VCL のイベントハンドラの仕組みは WindowsAPI をうまくカプセル化していると思うけれど、イベントの中でダウンキャストを要求する設計がなんだか気になる。というか気に入らない。 Visitor パターンを使って、その辺りをスマートに解決できないかな? とふと…