はらぺこ日誌

C++ で開発する上で、クラスを一つ一つ実装するたびに毎回同じようなことを書かされるのは冗長なので、だいたいこんな感じになるよねという範囲のひな形を生成するスクリプトを perl で記述してみました。

• cppgen.pl

Getopt::Compact モジュールを使用しています。ご利用の際にはそちらも合わせてインストールしてあげてください。
(さらに…)

ライブラリ API の設計手法を学ぼうシリーズの第3弾です。前回の記事はこちら。以下の教材を利用しています。

• C++ APIデザイン
  

今回から第4章に入ります。4章は C++ での実装の話はなく、設計に入るまでの情報の収集や整理 (要するに要件分析)、および様々なレイヤーでの設計に関する議論となっています。プログラミング実習をするような内容でもないので、要点をまとめながら解釈したり考えたりしたことをレポートしたいと思います。

今回はその中でも、 4.1～4.3節の、要件分析までの内容について見ていきます。

大原則

最初のセクションに入る前の書き出しで、以下のように書かれています。これはもう、大原則ですよね… (強調は拙引用者によるものです)。
(さらに…)

ライブラリ API の設計手法を学ぼうシリーズの第2弾です。前回の記事はこちら。以下の教材を利用しています。

• C++ APIデザイン
  

さて、API のラッピングパターンについてはざっと読むだけで終了とし、今回は Observer パターンについてさらってみました。

MVC っぽいことをやってみたい。

本書では、オブザーバーパターンの説明に入る前に、 MVC アーキテクチャについての説明がありました。

シンプルなアプリケーションでは、コントローラはユーザ入力に基づいてモデルへの変更に影響を与え、こうした変更をビューに通信して、UIを更新できるようにする。しかし、実際のアプリケーションでは、通常、水面下のモデルへの追加変更を反映するために、ビューも更新する必要がある。(…中略…)とはいえ、先ほど述べたように、モデルコードはビューコードを静的にバインディングして呼び出すことはできない。そこでオブザーバーが必要になるのだ。

なるほどなるほど。とまぁ、こんな説明の後に Observer パターンの実装例とその説明に入っていくのを見せられたら、そりゃあまぁ、 MVC っぽいことをやってみたい、って普通思いますよね…??

ただ、上記にあるようにモデルがビューを監視できるようにする必要があるという話であるにもかかわらず、多くの MVC フレームワーク実装を見るに、ビューからのメッセージを受け取って何らかの制御を行うコードは通常コントローラに書かれているように見えます。現実的には、ビジネスロジックはフレームワークを差し替えても流用可能であることが望ましく、オブザーバーにするための抽象クラスの継承でさえ避けたいというのが実情なのではないかと思います。
(さらに…)