あおいろ日記

　最近blogの再構築が重かったので軽量化に色々PHP化しました。
　なので一応リダイレクタは仕込んだ物の、ファイルの拡張子が変わっていて以前のURIではアクセス出来ないページが出来てる可能性があります。
　お手数ですが、アクセス出来ないページを見つけたら報告よろしくお願いします。

　長月のサイトではアクセスログを取ってます。サーバにデフォルトで残る物だけではなく、長月自作のＣＧＩを使って独自に取ってる物もあります。
　そのログを見てて気付いたんですが、最近当blogの駄文カテへのアクセスが多い。
　何故だろう？　と考えてみたんですが、アクセスしてきてる人たちがユタさんとこから来てる事が多いんで、もしかしてＳＳとか期待されてますか？　とか思う訳です。
　一応当サイトはプログラミング系なんで、やるかもしれない物のSSはメインになりえません、それでも期待されてるならとか思わない事もないんで、一つ質問してみたいと思います。

　貴方は駄文カテゴリに何を期待してますか？
　答えはコメントでお願いします。

　いやもう大変でした。
　メッセンジャーのログ側が改行を <br /> に変換してくれてないので、何とかして改行を <br /> に変換しないと変な表示になる問題がありまして。
　昨日エントリを書いた時点では <pre> タグで囲んで誤魔化してたんですが、何か納得行かないので何とかしようと試みてみました。
　とりあえずは XPath 関数を調べてみて translate 関数が使えるかも？　とやってみるも、第二引数と第三引数の扱いを勘違いしていて実は使えない関数だと発覚。
　仕方がないのでスクリプトでやるかとちょちょいと JavaScript を書き書き。しかし <xsl:value-of> タグはタグの位置に対応するテキストノードをべたっと展開するので改行が邪魔。これも上手く行きません。
　次の手をと <xsl:template> タグを用いて再帰的に substring-after 関数と concat 関数に突っ込む事で何とかしようと試みるも、<xsl:variable> は変数が const、これも断念。
　ひたすら悩んだ結果 translate 関数と JavaScript を組み合わせる事にしました。詰まり改行を translate 関数で他の文字に変換、その文字を <br />\n に再変換です。異様にアドホックで気に入らない解決策ですが仕方ありません。特殊文字代わりとして出現頻度の低そうな半角鍵括弧でも使っときませう。
　しかしこれも問題あり。 JavaScript で定義した関数の呼び出し側でシングルクォートを使っている為、対象のテキスト内にシングルクォートがあるとそのシングルクォートが引数括りの終わりと認識されてそのテキストが表示されません。なんてこった、ここまで来て……orz
　まあでも、さっきと同じ方法でいけるだろと translate 関数の引数にシングルクォートの実体参照を追加、特殊文字代わりに半角鍵括弧の残りを使えばいいかとやってみる物の。実体参照部分が普通のシングルクォート扱いで translate 関数の引数が不正に。ぽまいクォートの実体参照ってクォート内でも同種のクォート使える様に定義されてるんちゃうんかいと、どないせーっちゅうねんヽ(｀Д´)ノ
　仕方がないので気持ち悪い物の JavaScript で定義した関数を呼び出す側で引数を括ってるクォートをダブルクォートにする事で凌ぎました。引数で渡してる <xsl:value-of> でもダブルクォート使ってていやんなんですが(´・ω・`)
　多分対象テキスト内にダブルクォートがあるとおかしな動作をする事でしょう……orz
　でも良いんです、長月の場合 ＭＳＮ でのチャットでは顔文字の関係でシングルクォートは頻出する物のダブルクォートはあんまり出てこないですから(´・ω・`)
　すでにアドホックだし今更気にしないことにします。

　何やらＭＳＮメッセンジャーのログが見づらくて気に入らなかったのでXSLを何も知らずにぶっつけで編集。
　メッセンジャーの画面と互換に改造。
　でもよーわからんですよ。変数とか。
　@が頭についてるのって何？　クラス名か id 名かなんかですか？　教えてエロい人。

　既に昨夜の話になる訳ですが、２ｃｈ棋院に行って一番弟子なけどと久しぶりに打ちました。
　物凄く久しぶり、ちょっと調べてみたら昨年十月以来の様です。
　半年振りだし、当時と比べるとＫＧＳランクで１０ランク上げてるので随分強くなってます。こっちの弱体化も含めると結構三子ぐらいでもいいぐらいなんじゃないの？　と思ってました。
　しかしランク通り五子で挑んで来やがります。かといって師匠として石を減らすのはかっこ悪い。簡単に負けるのもかっこ悪い。これは気合を入れないといけません。
　そんな訳で異様に気合を入れて打ったおかげか右下で難解定石が発生したり割と波乱含みだった訳ですが、何とか半目勝たせてもらいました。いえ半目はちょびっと狙ったんですけども。
　それにしてもなけど強くなりました。後半年もすれば追いつかれるでしょう。師匠は今怠けてるから今のうちにがんがれ（´∀｀）
　ＳＧＦはこちら：http://kgs.kiseido.com/games/2005/4/26/aoitan-nakedjazz.sgf

　で、前振りよりかなり短い本題です。上記対局のおかげでやっと８ｋ？　まで持ち直しました。おそらくここらで打ち止めです。今の長月では１０ｋでも良い位ですから。ま、確定してないしもうちょっとがんばってみますかね。

　いやぁもうね、なんて言うか、危ないです。
　なんかねぇ、こう、危険です。
　以前書いた通り何やら痛い文章を書いてるわけですが、ここへ来て危険度が指数関数的に増してる気がします。
　正直これが長月のメンタルの深い所の現れだとしたら確実に危険人物です。三年以内に誰か殺します。
　しかし長月の中の人はこんなのじゃない！　と言い切る根拠は無いですし。むしろああ、そうかもなんて思える辺りとっても危険です。
　いやもう自分の事ながら人間って怖いですね。

　何の因果か知り合ったユタさんと相リン決定。
　しかもＳＳ貰えるとか。とりあえずうちからはリンク完了。
　そのうちSSが届いたらページ作ってうｐします。

　月見館：http://www.eonet.ne.jp/~yuta-page/

　今日はなにやら書いてました。ぷるぐらむももちろんですがそうでない文章も。
　問題はぷるぐらむではない文章の方で。これがなにやら物凄く女々しい文章。
　ああ、長月はこんなメンタルの人なんだと他人事のように思いましたとさ(´・ω・`)

　例えばこんなの。
　　　ほら、もう私騙されてる。騙されても良いなんて思ってる。信じたい。信じていいの？
　とか
　　「良いよ、私を壊せるのは貴女だけ。私を壊していいのは貴女だけ。どうせいつか壊れるのなら、貴女が壊して」
　とか
　　　これは契約。これで私は貴女の物。貴女は私を飼う義務があるの。
　みたいな。
　ぽまい一体どうなのさそれ……orz

　まあ、それはそれで長月の一部って事で受け入れようと思います(´・ω・`)

　久しぶりにＫＧＳへ、そして碁を打つ。
　どうも１０ｋぐらいがいいところっぽい。
　まあランク確定してないからわかんないけど。

　最近本読んでばっかりで書いてなかったＣ＋＋で遊ぶ。
　何を作ろうと言うこともないのでテンプレート周りの挙動チェックしたりで遊び倒し。
　ずっと Modern C++ Design が手元にあった一日でした（´∀｀）

　うわー、グラボかよ……
　ふと「代わりのグラフィックスカード用意しなくてもオンボードチップあるじゃん」と気づいて実験開始。見事起動。AGPスロットかカードが悪いの確定。
　なんにしても出費が痛いことになりそうですorz

　メインマシン様が起動しません。
　CMOSクリアしてもBIOSすら出てこない有様。メモリも挿すスロット変えてみたものの変わらず。明日AGP周り確かめてみようかなと。
　てなわけでしばらく日記とかの簡単な文章で済む更新のみになりそうディス……orz

　仕事中に右手人差し指の先を切り、さらに右手中指の爪が割れて先の方が五分の一ほど剥がれかけな長月です。皆様はご健勝でしょうか？　長月は本人も仮想世界への代理人も割と不健康な感じです。皆様はご自愛ください。
　さて、キーボードが少し打ちづらいながらも基本的に左利き寄りの両利きの為割と生活には支障ないのでいつも通りエントリは追加される訳です。今日はもうそろそろ見てる方々も飽きてきたであろう GoF本 第４章から Decorator パターンです。

　Decorator パターンはオブジェクトに動的に責任を追加するパターンです。ロジックとしては前回取り上げた Composite パターンと似ています。Composite パターンは、コンテナとプリミティブなクラスを同じクラス階層に置く事でツリー状にお互いを包含する構造を作り出し、部分と全体に差を無くすパターンでした。Decorator パターンの場合も、Composite パターンでも行われた様に、全体を俯瞰する為のルートクラスを用意し、Decorator に当たるサブクラスではルートクラスのオブジェクトへの参照を持つ事で連鎖します。Composite パターンとの違いはルートクラスのインターフェイスが最大化しない事ですかね。

　Decorator パターンは、個々のオブジェクトに責任を追加し、且つ他のオブジェクトへの影響を最小化すべき時。責任の追加に加えて、責任の削除が出来るべき時。サブクラス化による責任追加が現実的ではない時。等に利用されます。

　Decorator パターンは継承を用いた拡張よりも柔軟です。また、クラス階層の上位のクラスが、所謂「スーパーマンクラス」になる事を防ぎます。
　しかし、ある Decorator クラスが装飾しているクラスはその Decorator クラスと同一ではないので、同一性に期待したコーディングが出来ない。非常に似通った小さなクラスが氾濫する。と言う欠点も持ちます。

　前述の通り Decorator パターンは Composite パターンと似通っています。構造を良く見てみれば内部に持つオブジェクトが一つに制限された Composite パターンに見えます。しかし Decorator パターンはオブジェクトの集約を目的としている訳ではありません。Decorator パターンはオブジェクトに責任を追加します。

　長月は Decorator パターンを余り使った事がないんですよね。もしかしたらやってるかもしれませんが、意識して使った事って少ないです。なんと言うか、動的に責任を追加する場面が余りないというか。そんなトリックが必要になるほど複雑な物を作ってないというか。そもそも殆どプログラム書いてな……げふっ（吐血
　まあそんな訳で今回はここまで、次回はおそらく長月の理解度が本書中一番低い Facade パターンをお送りします。

　今日は構造に関するパターンの三つ目、Composite パターンをお送りします。
　Composite パターンは複数のオブジェクトを合成します。また、合成されたまとめオブジェクトを一様に扱えるのが特徴です。
　プリミティブなオブジェクトを組み合わせる事で複雑なオブジェクトを構成する事はままあると思います。しかし、その時にそれらのオブジェクトを一様に扱う事に困難を覚えた事はありませんか？　例えば、プリミティブなオブジェクトをまとめて扱う方法としてコンテナへの格納は一手でしょう。しかし、プリミティブなオブジェクトとプリミティブなオブジェクトを集めたコンテナは別物です。いくつかのオブジェクトをまとめた物と、単一のオブジェクトを区別なく扱う。それが Composite パターンの提供する合成です。

　Composite パターンでは、プリミティブなクラスとコンテナクラスを同じクラス階層に置きます。詰まり一つの抽象クラスがコンテナでも、プリミティブなクラスでもあるのです。
　例として ＧＵＩ コンポーネントを考えてみましょう。GUI コンポーネントには、Button や Label、Inputbox の様なプリミティブなコンポーネントや、Window や Panel 等の、他のコンポーネントを内包するコンポーネントが考えられます。Window クラスや Panel クラスは他のコンポーネントオブジェクトを内包するコンポーネントなので ContainerComponent から派生します。Button クラスや Label クラスはプリミティブなコンポーネントなので PrimitiveComponent から派生します。さて、これらを統一的に扱うにはどうしますか？　ContainerComponent と PrimitiveComponent に共通の親クラス Component があれば良いですよね。これで Composite パターンの言う形になりました。これは ContainerComponent をノード、PrimitiveComponent をリーフとしたツリー構造と言えます。Composite パターンは、再帰的に複合オブジェクトを構成していくパターンなのです。

　Composite パターンでは、その構成要素であるノードに当たるクラスも、リーフに当たるクラスも区別しません。その特徴によってクライアント側のコードはノードであるかリーフであるかを意識せずにコーディング出来るようになります。また、部分と全体に区別の無い構造なので、柔軟な構成の変更が出来ます。
　しかし、設計を過度に一般化するというデメリットも持ちます。

　実装の面で言えば、Composite パターンは、その構造上ツリー構造の持つメリットデメリットを同じように持つようです。また、ルートに当たるクラスは自らの子孫であるクラスのインターフェイスをほぼ全て持つことになります。これはインターフェイスの最大化と呼ばれる好ましくない設計の一つです。

　Composite パターンは Decorator パターンと共に良く使用されます。この場合、Decorator パターンは Composite パターン側のインターフェイスに合わせる必要があり、若干割を食うようです。
　Composite パターンを用いた構造では、内部の操作に Iterator パターンが良く用いられます。

　Composite パターンは割と良く使われているはずです。なんと言うか、オブジェクト指向の本を読むと必ずこういった感じの設計について書かれてますし。文中で挙げたコンポーネントクラスの様に、素直に考えれば Composite パターンになる場合も多いからです。
　しかしそれだけに、経験だけで書いている方も多いのではないでしょうか？　Composite パターンが持つメリットデメリットを再確認する為にも一度勉強しなおしてみるのも一手ですよ。
　では今回はここまで、次回は Decorator パターンをお送りします。

　構造に関するパターンの二つ目は、前回も書いた通り Bridge パターンです。
　Bridge パターンは Handle/Body とも呼ばれ、割と良く使われているパターンだと思います。Bridge パターンはパブリックなクラスの定義と実装を分離し、それらを独立に変更できるようにしたパターンです。

　実装の分離と言うと pimpl イディオムを思い出しますね。あれも Bridge パターンの一形態だと思います。しかし Bridge パターンでは、実装の分離に関する思惑が pimpl イディオムとは違います。Bridge パターンは、実装上の汎化関係にあるクラスの関係を意味上の汎化関係を分離します。一般的に汎化関係は抽象クラスと継承を用いて表現されますが、クラス階層の中に実装上の汎化関係と意味上の汎化関係が混在すると、それぞれを独立に変更する事が困難になります。
　そんな場合、Bridge パターンを用いて実装と意味の階層を分離します。クライアントが参照する物は意味の階層、意味の階層の中で実装上必要とする物は実装の階層で定義する事で、クラス階層単位でのインターフェイスと実装の分離を実現します。

　Bridge パターンは抽出されたクラスとその実装を分離し、実装を動的に選択したり交換したりしなければならない場合、抽出されたクラスとその実装を両方ともサブクラス化によって拡張可能にする場合、抽出されたクラスの実装が変更によってクライアントに影響を与えるべきではない時、Ｃ＋＋のような言語で実装を隠蔽したい時、複数のオブジェクト間でクライアントから隠蔽した状態で実装を共有したい場合等に使用されます。
　Ｃ＋＋のような言語で実装を隠蔽するというのはまさに pimpl イディオムですね。一番良く使われる Bridge パターンではないでしょうか。

　Bridge パターンと Adapter パターンはクラス同士を繋ぐという関係では同じです。しかし Adapter パターンは既にあるクラス等、設計後に適用される事が多いのに対し、Bridge パターンは抽出されたクラスと実装を分離する為に、言い換えれば外部に向けた設計と実装を分離する為に、設計の早期に適用されます。

　長月は割と最近まで Bridge パターンを軽視していました。Bridge パターンというより pimpl イディオムですね。Exceptional C++ を読んでからは考えを改めたのですが、実装の隠蔽以外の意味で使用する Bridge パターンも馬鹿に出来ませんね。解っているつもりでやっぱり「ああなるほど」と思う所もいくつかありました。いや、本は読むものです。
　では今回はここまで､次回は Composite パターンをお送りします。

　iframe タグの削除は MovableType じゃなくてノートン先生が原因と判明。
　最近のノートン先生って面倒なんですね。正直長月にはバージョン5.0相当のアンチビだけで十分なんですが(´・ω・`)

　なんか知らないけどアマゾンの広告フレームのタグが削除される。
　昨日まで有効だった物がいきなりダメってのも良く解らない話(´・ω・`)
　だれか Movable Type 詳しい人心当たりあったら教えてくだちぃ。

　今回から数回は構造に関するパターンのカタログです。今回は Adapter パターンを取り上げます。
　Adapter はあるクラスのインターフェイスを別のインターフェイスに変換します。変換と言うとなんだか齟齬があるように感じますね。なんと言うか、所謂ラッパクラスです。

　あるコードの中でクラス Hoge のオブジェクトが使われていた時。何らかの理由で関連性の無い Piyo を同じコードで使いたくなる事があったとします。その時、Hoge と Piyo のインターフェイスがたまたま一致していればコードの修正量は少なくて済みますが、そう言う事は稀で、どうしても Piyo のインターフェイスに合わせて修正する必要が出てきます。Adapter は、Piyo をラッピングしてインターフェイスを合わせる事で、そのジレンマを解消します。長月が実際に遭遇した例で言えば長月の書いた画像クラス AILImage を、とあるライブラリの DIBBitmap 操作関数に渡す為に AILImg2DIBWrapper クラスでラップして渡した事があります。その時は Adapter パターンとか意識してなかったんですが今考えると Adapter パターンですね。これはオブジェクトに対する Adapter パターンと呼ばれます。
　また、上記の例では AILImg2DIBWrappter の中に AILImage のインスタンスを持ち、転送関数で処理を委譲していましたが、向こうのライブラリで用意されている DIBBitmap クラスのインターフェイスと、AILImage の実装を多重継承した AILImg2DIBAdapter も考えられます。DIBBitmap クラスからの継承が必要な場面ではこちらを選ぶべきでしょう。こちらはクラスに対する Adapter パターンと呼ばれます。

　Adapter は再利用したいクラスが望んだインターフェイスを持たない場合や、既存の複数のサブクラスを利用したいが、さらにサブクラス化してインターフェイスを合わせる事が現実的ではない場合、等に活躍します。

　クラスに対する Adapter では、Adapter クラスが再利用されるクラスのサブクラスになる為、メンバ関数をオーバーライド出来ます。その代わり、クラス階層を見たとき、Adapter クラスが再利用されるクラスの下に来るので、再利用されるクラスとそのサブクラス全てを適合させたい場合にはクラスに対する Adapter では上手く行かないという事になります。
　オブジェクトに対する Adapter では、クラスに対する Adapter でのジレンマである、複数のサブクラスを賄う Adapter の構築が可能です。しかし、クラスに対する Adapter と違い、再利用されるクラスのメンバ関数をオーバーライドする事は出来ません。これを実現するには、再利用されるクラスのサブクラスを定義し、そのサブクラスで任意のオーバーライドを行い、サブクラスに対する Adapter を定義する事で実現できますが、余計な間接性を持たせる事にもなります。

　オブジェクトに対する Adapter パターンは Bridge パターンと良く似た構造を持ちます。しかし、Adapter が外部表現 (インターフェイス) に重点を置くのに対して、Bridge は内部表現 (実装) に重点を置きます。また、何らかのオブジェクトをラップする事に関して Adapter パターンは Decorator パターンと似ています。しかし Adapter がインターフェイスを変更するのに対して、Decorator ではインターフェイスを変更せずに機能を追加します。その結果、Decorator の方が透過性が高く、再帰的なオブジェクト構造の構築を可能としています。そして Proxy パターンも再利用されるクラスを自らの背後に隠す点では同じですが、Proxy はインターフェイスを変更しません。

　長月的に Adapter はとても便利です。特にジェネリックスプログラミングで威力を発揮すると思います。ジェネリックスプログラミングでは、ジェネリック関数の内部で特定のインターフェイスを必要とする事が多く、ジェネリック関数に放り込みたいクラスが必要なインターフェイスを持っていない事があります。そう言った時 Adapter はとても重宝します。
　個人的に便利な物が多い構造に関するパターン、次回取り上げるのは Bridge パターンです。所謂ハンドル-ボディイディオムって奴ですね。pimpl イディオムも Bridge パターンと言えますね。Ｃ＋＋に於ける pimpl にはソースファイルの依存性軽減とか Bridge パターン本来の目的とは違う物も含まれるので Bridge パターンそのものとは言えないかも知れませんけどね。
　では、今回はここまで。(=ﾟωﾟ)ﾉｼ

　GoF本も割と久方ぶりに読んでる訳ですが、今読むと前よりちょっと理解できる感じです。一応腕上がってるんですかね？
　今回からは第４章に入ります。第４章は構造に関するパターンが詳解されています。構造に関するパターンの要点は二つ。オブジェクトやクラスを合成する事、まとめられたクラスやオブジェクト群がむやみに強く結合しない事です。「分割し、統治せよ」をオブジェクト指向の世界で如何に実現するか、その妙技を集めた章と言えます。
　いくつかのオブジェクトやクラスを合成したいと言う要求は良く発生します。また、それを前提として書かれるクラスやオブジェクトも多いでしょう。しかし、オブジェクトを合成するだけでは不満なのです。複数のオブジェクトやクラスを持ちつつも、それぞれの依存度を最小化したいのです。影響を局所化出来てこそ大きな構造には価値があります。
　本章では上記の様な要求に対する解が七つ詳解されています。その七つのパターンを列挙しておきます。

• Adapterパターン
• Bridgeパターン
• Compositeパターン
• Decoratorパターン
• Facadeパターン
• Flyweightパターン
• Proxyパターン

　構造に関するパターンはそれぞれいくらかの関連を持ちます。設計の軸になる部分で良く使用されたりするので、これらのパターンの複合的な物になる事が多いようです。それらの関連については本章の最後で語られます。本blogでも、最後に取り上げる予定の Proxy パターンのエントリかまとめのエントリで書く予定です。

　個人的に本章は割と好きです。いろいろなロジックに触れるのが楽しいのです。その意味で第５章の振る舞いに関するパターンも面白いトリックが満載で好きです。本章のパターンは割とどっしりとした印象で、第５章のパターンは派手な印象ですね。ぱっと見て効果が実感しやすい第５章のパターンも良いですが、最終的な開発コスト等、地味ながらも重要な部分で威力を発揮する本章のパターンも長月の脳の肉欲を大きく満足させます。
　ただ、これらのパターンは選択が重要になりますので、本章は特に精読して各パターンをしっかり把握しておきましょう。

　さて、今回は第３章最後のパターン、Singleton です。なんと言うかみんな知ってそうですが……
　Singleton はアプリケーション中にあるクラスのインスタンスが一つしか存在しない事と容易なアクセスを保証するパターンです。複数の選択肢はあれど、同時に一つしか存在してはいけない場合に威力を発揮します。グローバル変数のアクセシビリティにインスタンス数の制限を加えた物と言えます。

　Singleton はその簡単な構造とは裏腹に、インスタンスへのアクセスを制限したりコントロールしやすい、制限を掛ける数が任意に調整でき、状態を持て、Ｃ＋＋等の静的メンバ関数の仮想化を許さない言語でも仮想関数を扱える等から、クラスメソッドだけのクラスを使うより柔軟性がある。と言うメリットがあります。

　今までに挙げてきた複合オブジェクトの生成に関わるパターン、Abstract Factory や Builder、Prototype 等はアプリケーション内で複数必要となる事が少なく、高いアクセシビリティを必要とするので、Singleton を用いて実装される事が多いでしょう。それで無くとも Singleton は割と便利なので使用する機会は多いと思います。しかし、Singleton は拡張されたグローバル変数なので、グローバル変数が持つ欠点は多くの場合 Singleton にも当てはまります。

　さて、今回まで何度かに渡って生成に関するパターンを扱いましたが、これらはシステムの構成に柔軟性を与える為の物です。Factory Method に代表されるサブクラス化や、Abstract Factory や Builder、Prototype が威力を発揮するオブジェクトコンポジション、これらは柔軟性を高める為の方法論です。それらを上手く使いこなしたアプリケーションに現れるオブジェクト生成の為の設計パターン、それが第３章で詳解されているデザインパターンなのです。
　デザインパターンは若干の複雑度と引き換えに柔軟性をもたらします。パターンの選択肢が増えれば増えるほど設計は洗練されるでしょう。この機にデザインパターンを勉強してみるのは如何でしょうか？

　今回は第３章に於ける複合オブジェクトの生成に柔軟性を持たせる為のパターンについての最後の項です。今回は Prototype パターンについてをお送りします。
　Prototype は生成するオブジェクトを雛型から複製する事で賄うパターンです。ですので、クライアントクラスでは生成過程で各部品の生成を各部品のプロトタイプオブジェクトが持つ複製メソッドに委譲します。詰まり、プロトタイプオブジェクトに生成を依頼するクライアントクラス側で適宜プロトタイプオブジェクトを挿げ替えれば様々な組み合わせの複合オブジェクトを生成する事が出来ます。

　Prototype は、インスタンシエートされるクラスがどの様に構成されるかが静的に決定しない場合、詰まり実行時に決定される場合の動的構成や、何らかのクラスに於てインスタンスの取り得る状態が少ない場合に、あらかじめ雛型を用意しておく事でインスタンシエートの手間を省く等の用途で使用されます。

　Prototype パターンも、Abstract Factory パターンや Builder パターンと同じく生成プロセスから生成の詳細を分離します。しかし他の生成に関するパターンよりも実行時の動作に重点を置いている為、他のパターンよりも柔軟性が高く、生成するオブジェクトの追加や削除が容易です。また、柔軟性が高い為、値や構造の組み換えによってオブジェクトの仕様を変更できます。
　構成の柔軟性に於て高いアドバンテージを持つのに対して、実装の面ではいくらかの不利な点を持ちます。Prototype はオブジェクトの複製によってインスタンスを生成するので、Prototype を適用するクラスには複製関数が必須となります。また、複製に掛かるコストが高い場合にも適さないでしょう。ただし、複製のコストは COW (Copy On Write) な実装をする事で軽減できます。しかしそれもまた複雑度を上げるので一つのトレードオフでしょう。

　Prototype は Abstract Factory の実装としても使えます。Abstract Factory に雛型の集合を持たせ、オブジェクトの生成は雛型の複製で行うのです。また、Composite パターンや Decorator パターンの様に、多くのオブジェクトを集約したり連鎖させるパターンとも相性が良いでしょう。これは複合オブジェクトの生成に関するパターンに共通していますね。

　長月は Prototype の理解度が低い上に、使用した記憶もありませんし、オブジェクトの構成は静的に決まって欲しいので動的な構成は注目度が低く、Prototype にはこれと言って言える事が無いんですが、これも何らかの事情で実行時までオブジェクトの構成が決定できない場面に出くわしたら重宝するんでしょうね。きっと、多分、おそらく。
　で、次回は第３章最後の項、生成に関するパターンの大トリ Singleton です。なんか Singleton だけは今更何を言うまでも無くみんな知ってるんじゃないかという気がしないでもないんですが、順番なので次は Singleton をお送りします。ではまた。

　第三章のパターンも今回で半分以上をクリアですね。今回は Factory Method をお送りします。
　Factory Method はオブジェクト生成の為のインターフェイスだけを規定して、実際の生成はサブクラスに任せます。これは結構頻繁にやりますよね。本によっては仮想コンストラクタと呼んでいます。

　あるクラスの中で別のクラスのインスタンスを利用するが、実際に利用するクラスが事前に解らない状況は割と頻繁にあると思います。特にライブラリ等、後にも多用する予定のクラスなんかはそう言う状況も多いと思います。そう言うときには Factory Method の出番です。多くの場合コンストラクタの中で new すると思いますが、そこを生成関数に書き換えてしまいます。そして生成関数は仮想関数にしてしまうのです。後は違うインスタンスを返したい時には適宜欲しいインスタンスを返す生成関数を実装したサブクラスを用意するだけです。

　Factory Method は特定の実装をコードから分離します。これは Abstract Factory や Builder もそうであったように拡張や入れ替えを容易にします。
　ただし、Factory Method にはサブクラスの定義を強要すると言う欠点もあります。特にサブクラスを必要としていない時には一つの悩み所でしょう。これに対して、Ｃ＋＋ではテンプレートを使うと言う選択肢があります。テンプレートパラメータによって返すオブジェクトを返す生成関数を持つクラスを用意するのです。或いは生成関数をファンクタにしてしまうのも良いでしょう。ポリシークラスという選択肢もあります。テンプレート様様ですね。

　Abstract Factory や Template Method は良く Factory Method を利用します。
　Abstract Factory は Factory Method を用いて実装されますし、Template Method は Factory Method を内部で呼び出します。Abstract Factory のエントリで書いた CreateWindow() 関数は Factory Method に当たります。

　Factory Method はそれなりに熟練した方なら言わずとも利用しているであろうパターンです。特にＣ＋＋等ではコンストラクタを仮想にする事が出来ないので自然とこう言う手法を編み出す人も多いようです。長月は自力で編み出した訳ではありませんが、Effective C++ で仮想コンストラクタの手法を知って以来、GoF本を買うまで Factory Method とは知らずに利用していました。知らない方もこれを機に Factory Method を含めたデザインパターンを勉強してみては如何でしょうか？

　PCが調子悪い。どのぐらい悪いかと言うと起動しないぐらい悪い。
　何とか起動したけどBIOSが怪しい、BIOSじゃないならどこかのコンデンサが飛んでる。なんつか超ピンチ。
　サブPCでネットとプログラミングに関しては問題ないけど……むしろプログラミングに関してはメインPCより環境整ってるけど……
　さてどうしたものか……(´・ω・`)

　今回は生成に関するパターンその２、Builder パターンです。
　Builder も Abstract Factory に似て、実装を差し替える為のパターンです。 Abstract Factory が利用するオブジェクトの実装を差し替える様に、Builder はオブジェクト生成の実装を差し替えます。詰まり、Abstract Factory がオブジェクトの実際を気にせずオブジェクトを生成出来るようにしたのと似て、Builder はオブジェクトの構成や、それを実現する為の機能を気にせずに生成出来るようにします。Abstract Factory が生成されたオブジェクトのインターフェイスの共通性に主眼を置いているのに対し、Builder は生成されるオブジェクトの生成過程の共通性に主眼を置いています。
　えーと、解りにくいですね。要するに、同じ生成ルーチンで色んなオブジェクトを生成出来るようにすると言う事です。

　これは生成したいオブジェクトがたくさんの部品や組み合わせで構成されている場合等に有効です。また、内部表現の差し替えが用意になります。これは生成の為の実装詳細が局所化されると言う事も意味しますし、詳細が局所化されるという事は、それらを利用する生成過程の細かいコントロールが可能になると言う事でもあります。

　Builder パターンはしばしば Composite パターンと共に使用されます。何らかの複合 (Composite) オブジェクトを生成する為に Builder が利用されるのです。また、Builder が必要とする部品を提供する為に Abstract Factory や Factory Method も利用できるでしょう。

　今回はジェネリックスプログラミングに近い立ち位置にあるパターンである Builder を紹介しました。生成に関する限り、Builder はポリシークラスの様な役割を果たします。個人的にはポリシークラスの方が好みなので余り出番がないんですが、ジェネリックスプログラミングのパラダイムをサポートしてない言語を使うときには便利そうです。
　さて、本エントリで Builder に興味を持たれた方、是非本書や増補改訂版Java言語で学ぶデザインパターン入門等でデザインパターンを勉強してみては如何でしょうか？

　前回投稿後すぐに書き始めたのに途中で寝ちゃったおかげで結局この時間ですよ'`,､(´∀`)'`,､
　ついにパターンのカタログまで来ました。今回は Abstract Factory パターンです。

　Abstract Factory は何らかのインスタンスを必要とする時に、その実装に関わる具象クラスを明確にせずに生成する為のマネージャクラスを用意するパターンです。それなりに構造化された設計のプログラムなら、HogeManager とか HogeCreator 見たいなクラスがあったりするでしょう。そう言ったクラスは多くの場合 Abstract Factory を用いて設計されているのではないでしょうか。
　このパターンは、抽象クラスとサブクラスを用いて場合によって実装をスイッチする際等に活躍します。本書に載っている例で言えば、複数の look-and-feel 規格に対応したアプリケーションを書く場合、実際に使用する look-and-feel に拠らないウィジェットクラスを書くために Abstract Factory を利用しています。

　Abstract Factory を簡単にまとめると、何らかのオブジェクトの集合に対して複数の実装系がある時、生成用のアクセスポイントを持つマネージャクラスを用意し、実際の生成はサブクラスに任せる構造です。
　例えば、複数のプラットフォームに対応したアプリケーションを書く場合、各プラットフォーム向けのＧＵＩコンポーネント群を定義するでしょう。その時、実装に拠らず同じオペレーションで同等の機能を呼び出す為に、各コンポーネントは抽象基底クラスから派生して実装するかと思います。しかし、生成する場面で特定の実装に触れたくないのです。Window* w = ComponentFactory::GetInstance()->CreateWindow(); で Win32 も Mac も X-Window もフォローしたいわけです。そこで生成の為のインターフェイスを持つマネージャクラスを用意し、それを派生して各実装のコンポーネントを生成するサブマネージャクラスを定義します。後はプラットフォームにあわせた具象クラスを抽象マネージャクラスに代入して、コンポーネントの生成は抽象マネージャクラスを通せばよいのです。また、Singleton パターンや Factory Method パターンとの併用も良く見られます。

　ただし、パターンもいい事づくめと言う訳ではありません。メリットがあればデメリットもあります。AbstractFactory に関しては、インターフェイスの追加や削除を含む変更に弱いと言うデメリットがあります。インターフェイスの追加や削除が行われるとサブクラスまで手を加えなければなりません。この問題に関しては Andrei Alexandrescu が Modern C++ Design にて一つの解答を示しています。

　生成に関するパターンはＣ＋＋に於ける不可避の定数性、詰まり new 構文でクラス名が既知でならなければならない問題を最小化します。これは動的に型付けする言語では問題にならないのかもしれませんが、静的な型付けを行う言語ではまず確実に問題になる部分です。長月はＣ＋＋ぐらいしかまともなＯＯＰＬに触れていないので他の言語の事情を知りませんが、生成に関するパターンはＣ＋＋でそれなりに良い設計と実装を行いたければ必須の構造に思えます。
　今回はそれらの生成に関するパターンの中で、Singleton や Factory Method 等の小さい粒度のパターンを除けば最も頻出するであろう Abstract Factory を紹介しました。本エントリで Abstract Factory に興味を持たれた方、是非本書や増補改訂版Java言語で学ぶデザインパターン入門等でデザインパターンを勉強してみては如何でしょうか？

　改めて読むとGoF本結構退屈ですね。第2章は面白いのに(´・ω・`)
　今回から第３章に入ります。ここからはパターンのカタログなので、パターンの紹介の様な形になるかと思います。今回は第3章の概要です。続けて次のエントリで Abstract Factory パターンについて書きたいと思います。

　第3章では生成に関するパターンを扱っています。生成に関わるパターンのキモは二つ。生成されるオブジェクトの詳細を如何に隠蔽するか。そして実際の生成の詳細を如何に隠蔽するかです。
　あるオブジェクトのクライアントはオブジェクトに対する必要条件だけを持っていたいのです。言い換えるとインターフェイスの知識のみで必要なオブジェクト群を扱えるのが理想なのです。その為に、生成されるオブジェクトの詳細を如何に隠蔽するかが重要になります。
　また、クライアントではオブジェクトの生成をハードコードしたくないのです。具体的に言うと、new Hoge; 等とはしたくないのです。前述した方法の場合、Hoge の生成方法が new では無くなった場合ソースを書き換える必要があります。それは勘弁願いたいのです。なので、生成に関する知識の隠蔽も重要になってきます。
　本章では上記の様な要件を満たす為のパターンを五つ詳解しています。その五つのパターンを列挙しておきます。

• Abstract Factoryパターン
• Builderパターン
• Factory Methodパターン
• Prototypeパターン
• Singletonパターン

　本章ではこれらの実装例として迷路生成プログラムを使います。迷路の生成エンジンを各種パターンを適用して設計する事でそれぞれの違いを明確にします。ここをそれなりにちゃんと読まないと実装の説明を見ても何の事やら判らないかも知れません。気合を入れなければならないと言う程ではないですが、油断はしないようにしましょう。

　本項は概要の説明なので、特に技術的な事は出てきませんが、生成に関するパターンの思想が解説されています。プログラミングに於て今実装中の物の目的や思想、そして理想がわからないのは無用の混乱を生みますから、生成に関するパターンが何をどの様に目指す物なのかをきちんと把握しておきましょう。

　きらりんとこ経由でそれさえも平凡な日々さんの記事を読んだ。
　注目したのはそれさえ（ｒｙさん所の。

まずはこの二つのサイトを天下のW3CのHTML文法チェッカーで、文字コードだけを設定し、「極めていい加減」に確認してみました。

　という部分。面白そうなので長月も HTML Lint に掛けてみた。

http://www.atomnavi.jp/ を HTML4.01 Transitional としてチェックしました。 397個のエラーがありました。このHTMLは -95点です。タグが 24種類 783組使われています。文字コードは EUC-JP のようです。

　まあそんな物ですよね'`,､(´∀`)'`,､
　さくさく次行ってみましょう。

http://www.atom.meti.go.jp/ を HTML4.01 Transitional としてチェックしました。 254個のエラーがありました。このHTMLは -167点です。タグが 18種類 253組使われています。文字コードは Shift JIS のようです。

　いやすごい、なんていうか却って清々しい。
　ついでだからメジャーなところ行っとく？　ってことでMSN辺りを放り込んで見ませう。
　……ブックマに無い。ので代替案として知り合いのMSNブログを放り込んでみませう。

http://spaces.msn.com/members/内緒/ を HTML4.01 Transitional としてチェックしました。 571個のエラーがありました。このHTMLは -186点です。タグが 25種類 663組使われています。文字コードは UTF-8 のようです。

　うわすげえ、なんかどうやったらここまで行けるのか聞いてみたい。
　最後に当blogを放り込んで見ます。

http://blog.nagatsuki-do.net を XHTML1.0 Transitional としてチェックしました。 285個のエラーがありました。このHTMLは -66点です。タグが 31種類 554組使われています。文字コードは UTF-8 のようです。

　あんまり人の事は言えないようです(´・ω・`)

　と言う訳で、GoF本第二章です。なんか妙にだめだめな気分なのでさくっと行きます。
　第二章では実例を挙げてデザインパターンの使い方を解説しています。本章で実例として上げられているのはワープロソフトです。文章、絵、図を自由に配置でき、ウィンドウシステムや look-and-feel 規格への依存を最小化し、オペレーションを統一的なメカニズムで扱う、と言った設計上悩ましい部分にデザインパターンを適用する事で柔軟性を持たせます。
　本章で使われるパターンは、Composite パターン、Strategy パターン、Decorator パターン、Abstract Factory パターン、Bridge パターン、Command パターン、Iterator パターン、Visitor パターンの計八つ。それぞれのパターンについては今後のエントリに譲りますが、Composite パターンで内部表現を定義し、Iterator パターンで走査し、Strategy パターンで操作とデータ構造を分離し、Abstract Factory パターンでオブジェクトの生成とクラスの詳細を切り離し、Bridge パターンで概念と実装を分離し、Decorator パターンでＵＩに柔軟性を与え、Command パターンで操作に拡張性を与え、Visitor パターンで操作の実装への依存を最小化する実例を挙げています。
　なんと言うか、用意された綺麗な例である事は承知の上ですが、思わずお見事と誉めたくなる仕事です。読者をデザインパターンの世界に引き込みます。実際できるのであれば自分でもこういった綺麗な設計を行いたい物です。ですから、こういった綺麗な例を見せられると嫌が応にも期待が高まります。

　そんな訳で、第２章は割とへーと思うことが多いです。色々勉強できます。読む人のレベルによってはああ、そうそう、そうだよねと共感出来るでしょう。
　本章は読むのが楽しい場所でもありますから、カタログ部分が重いと感じる方はここから読んでみては如何でしょうか？

　なんていうか最近チョイスする本がＣ＋＋ユーザに媚びてる感のある長月です。と言う事で今回は特定のプログラミング言語に拠らない物をとＧｏＦ本をチョイスしてみました。ていうかＯＳ【第二版】はどうしたって？　避けてるんですよ、重いから。正直しょっぱなからあれは後悔しまくりです。とりあえずは今月中に何とか……ｏｒｚ

　そんな訳でＧｏＦ本です。Erich Gamma/ Richard Helm/ Ralph Johnson/ John Vlissides著、本位田 真一/ 吉田 和樹 監訳、オブジェクト指向における再利用のためのデザインパターン改訂版です。
　デザインパターンを簡単に説明すると、良い設計に現れる定石を一般化した物です。本書はそのデザインパターンと言う考え方 (定石を一般化、カタログ化して共通認識を作ると言う考え方) を提唱したガンマ先生以下四名、所謂 Gang of Four が世に送り出した論文や、パターンコミュニティで提案された、良い設計に頻出する厳選された２３のデザインパターンの解説書です。今回から数回に分けて本書について書いていきます。
　なお、本書については、パターンの紹介に近い形になるかと思います。なんと言うか他に書き様が無いとも……げふんげふん。

　そんな訳で今回は第１章について書きます。
　第１章はデザインパターンとは何かから始まり、本書で用いられている、デザインパターンのカタログの一項目としての整理の仕方､小見出しとそれに対するトピックの意味等の説明、本書で扱うデザインパターンの列挙と軽い説明、デザインパターンを設計に適用する際の指針と注意等が書かれています。
　プログラミングを嗜んでる方ならデザインパターンと言う単語を見た/聞いた事がある方多いんじゃないかなと思います。でも単語は知っててもそれ何？　と言う方も居られるんじゃないでしょうか？　本書で語られるデザインパターンとは、プログラミングの主に設計によく現れる定石の事、またはそれらの設計を一般化・カタログ化して共通認識を作ろうと言う考え方を言います。よく見る用法は前者ですかね。デザインパターンは粒度が様々なので、実装レベルに関わる事も多いのですが、デザインパターンは設計レベル、実装レベルの定石に関してはイディオムと呼ぶ事が多いようです。
　本章では定石をカタログ化する事の意味や Gang of Four の推奨するパターンのまとめ方等が解説されています。余り知られていないけどこれは割と応用が広くて良いんじゃないかと思うパターンをお持ちの方は、ここで提示されているフォーマットに従って文書化し、デザインパターンのコミュニティに投稿すると良いでしょう。
　また、本章ではデザインパターンを設計に適用する為のあれこれも解説しています。これはデザインパターンの適用と言う観点で書かれてはいる物の。デザインパターン自体が既に広く使われている設計の定石である事から、設計に関する一般的な考え方のトピックでもあります。個人的にパターンそのものよりもここで触れられている事をしっかり押さえる方が重要なんじゃないかと思います。デザインパターンを使いながら覚えるのが実践的ですかね。

　と言う訳で、もはやバイブルと化した感のある本書ですが、何気にデザパタ自体を知らない様な方もまだいます。そんな方には是非読んで欲しい本です。本書では重いと言う方は、結城浩氏の増補改訂版Java言語で学ぶデザインパターン入門辺りが割と易しくてオススメだそうです。長月は読んでないのでなんとも言えません。
　長月としてはデザパタはとにかく広まって欲しい物なので是非ご一読を。

　あ～もう眠い、だるい、やるせない、なんかお疲れ。だから今日の感想文なし。
　……嘘です。書きます。読んだのに書かないのなんか勿体無いですから。貧乏性です。
　今日も今日とてＣ＋＋、昨日に引き続いてハーブ・サッター著Exceptional C++ ４７のクイズ形式によるプログラム問題と解法 ５～８章です。

　え～、まず第５章はシグニチャの自動照合、ネームスペースに関しての規則に関するあれやこれやについての問題が収録されています。
　長月はネームスペース内で宣言・定義された関数の呼び出し順序とか規則とかを知っていても理解しきれてなかった様で、初めて本章を読んだ時「おぉ！？」と思った記憶があります。言ってしまえば重箱の隅をつついたトピックなんですが、今時のＣ＋＋ユーザならネームスペースは極普通に使っているでしょう。そして普通に気を使っていれば大抵の場合問題は無いはずですが、レアなケースで厄介なロジックエラーを起こす場合があります。そう言った場合、殆どのケースでは本章で書かれている様な事が起きているんじゃないかと思います。そんな事例滅多に無いよと読み飛ばさずに、一通り頭に入れておきましょう。

　第６章ではメモリ管理にまつわる問題を取り上げています。
　言ってしまえばよく見かけるトピックです。配列とポリモルフィズムは相容れないとか、メモリ管理はポインタのラッパでやろうぜとかそう言ったトピックです。ただ、取り上げているポインタのラッパクラスが auto_ptr なのが特徴的と言えば特徴的です。この手の話題では大抵の場合 auto_ptr は使えない例として少しだけ書かれて本題は参照カウントとかリンクリストとかでスマートポインタを実装する事であったりするのですが、本書ではＳＴＬに拘っているのか auto_ptr を上手く使おうぜと言った事が書かれています。
　また、本章では operator new や operator delete の自作に関しても触れていますが、これも多くの場合に見られるちょっ速なアロケータとか空間効率の良いアロケータと言ったトピックではなく、エラーを起こさない、例外安全で例外中立なアロケータを実装すると言う安全性を重視した内容になっています。

　第７章では、よく陥る罠、落とし穴、反イディオムと言った所謂アンチパターンについての問題を扱います。
　オブジェクトの生存期間に関するトピックは割とああなるほどと思えました。でも、他のトピックはああこれどこかで読んだなと言った感じでした。流石にもう自己代入チェックとか暗黙の型変換はだめぽとか飽きてきました、だって大抵の本に書いてあるんだもん(´Д｀；)
　ああ、「例外安全で例外中立な代入演算子 (或いはコピーコンストラクタ) ならば自己代入チェックは要らない、自己代入チェックのメリットは本当に自己代入が起きた時にのみ効率的なだけ」と言う主張にはへーと思いました。が、長月は何故そう言えるのかをちゃんと理解出来てない気もします。

　そして最終章の第８章です。第８章は分類しにくいトピックをいくつか扱います。なんと言うか個人的には読み物的な章でした。他の章に比べて難易度設定も低いようです。
　長月は第８章最初の問題からしてやられました。T t(); と言う記述、これだけで冷静に見れば T 型の値を返す引数をとらない関数の宣言です。しかしこれが変数の宣言･初期化のすぐ下にあったら？　長月は思わず変数の宣言 (定義) に見えました。ばっちり引っかかって誤読です。
　本章では const についても扱っています。この const、エラーとかが沢山出るとめんどくさくなって思考停止に陥るんですよね、結果 const 外すとか安易な道に走るか、良く考えずに思いついた事やってみてより大きなエラーを作りこむか、なんにしても悲惨です。そんな const の使うべき時使わざるべき時を割と丁寧に解説しています。特に「例え内部状態を変更しても外部から見た状態が変わらなければその関数は const である」は目から鱗でした。mutable の存在理由がやっと理解できました。
　そして最後のトピックである制御フローも興味深いトピックでした。自分が意図した以上に多くのパスが存在する事もあると自覚させられました。もうちょっと注意深く読んだり書いたりしなければと思わせます。

　いつもの如く駆け足なのか鈍足なのか、参考になるのかならないのか良くわからない文章ですみません。参考意見が欲しくて立ち寄って下さった方の為に書いておきます。
　本書は初心者の方にはオススメしません (内心却って初心者の内に読ませた方が良いかもとも思いますが)。しかし、貴方が少しはＣ＋＋を使えると言う自覚があるのならば一見の価値ありでしょう。また、効率の良いコーディングの本は読み飽きた、安全で頑強なコードの書き方が知りたいと言う方も読んでみるべきだと思います。
　解りやすい文章が書けないのが申し訳ないと思いつつ本書についてはここまでで筆を置きます。

　――――誰かの参考になる事を祈りつつ。

　エントリ公開したつもりで下書き投稿だったのに気付いた'`,､(´∀`)'`,､
　だから Exceptional C++ １～４章エントリは実質出遅れ……orz
　せっかくの連続更新続いてるのに切れるの勿体無いから投稿時間は下書き時点のままで勘弁汁。

　いやもういい加減囲碁関連のトピック書けっつーんですよね。ぽまいこのblogの閲覧者の８割が囲碁関連のページから来てるの知らんのかと小一時ｋ（ｒｙ
　ああもう、解ってるんですよ？　だからなんか書かなきゃナーとか思ってるんですよ？　でもね、今月読書強化月間だし読みたい本がコンピュータ関連ばっかりだしで仕方ないんですよ。
　と、一通り言い訳した所で読書感想書籍紹介文へ。今回から２回に分けて紹介予定の本はハーブ・サッター著、浜田真理訳、浜田光之監修、 Exceptional C++ ４７のクイズ形式によるプログラム問題と解法です。
　本書はクイズと言う形式にする事で、実際のプログラミング現場で求められる経験の学習を意図した物です。普通の学習書がボトムアップの発想であるのに対し、本書はトップダウンの発想で書かれています。その点で言えば以前紹介した Accelerated C++ と同じです。しかし二者には大きな違いがあります。はっきり言って Exceptional C++ は初心者さんにオススメできません。理由は追々述べます。

　さて、本書はクイズ形式を取っている訳ですが、第一章の項目一、詰まり一問目から飛ばしてます。
　第一章はジェネリックスプログラミングとＳＴＬについての問題ですが、項目一のイテレータにまつわる間違いを探す問題からして割といやらしい問題です。長月は一応なんとか気付きましたが、e.insert( --e.end(), TodaysDate() ); これ、どこが何故間違いなのか解りますか？　おそらく長月は問題として出されてなかったら気付きませんでしたし、怪しいと思っても Why? の部分が解るまで考える事は無かったでしょう。もうしょっぱなから難易度高いです。項目二で早速 char_traits いじってるのもうわーと思いました。
　この辺りが初心者さんにオススメできない理由です。文法や機能の理解であっぷあっぷしてる段階の人達には難しすぎるんです。

　では気を取り直して第２章へ進みましょう。第２章では例外に対して安全なコーディングについての問題です。
　Ｃ＋＋で例外を駆使すると、何気に色々な所に潜在的な危険を孕む事になります。何気なく書いたコンストラクタは例外を投げてもリソースリークしない？　何気なく書いた関数はちゃんと例外を呼び出し元に投げる？　例外安全で例外中立なコードを書いたつもりで副作用を残してない？　第２章ではそう言った視点でコードを見つめなおす為の問題が出題されます。
　例外安全なコンストラクタと例外安全な swap メンバ関数で実装する例外安全な代入演算子なんかのテクニックは必見です。

　第３章では、クラス設計と継承についての章です。この章に出て来る問題は色々な書籍や掲示板やＭＬで見かけた事のある様な物でしょう。しかし、解決の為のテクニックに注目すべき物があります、理由や意味をＣ＋＋で素直に表現する方法が書かれています。
　値のセマンティクスを持つクラスの型変換や演算子のオーバーロード、関数のオーバーロード・オーバーライドとそのどちらでもなく外部スコープの同シグネチャを隠す関数、public 継承と private 継承の違いとそれらの意味、Pimpl イディオムの効用と注意点、実装継承とコンポジション、本章ではこれらの問題を扱います。

　第４章では、依存性にまつわる問題を扱います。ヘッダのインクルードや Pimpl イディオム再び、前方宣言の駆使、継承からコンポジションへそして Pimpl の後ろ側へ、Pimpl イディオムを詳しく、Pimpl の最適化、等の問題が用意されています。
　ヘッダのインクルードに関しては目から鱗でした。考えてみれば目に見えない依存性を生み出している事にとても驚いた物です。また、Pimpl イディオムの有効性を軽視していた事も教えられました。お前は本当にデザパタを勉強してるのかと小一時間……orz

　本書は難易度が高いです。いや、難易度が高いのではなく、高級な話題が多いです。低レベル機能の実装でも高レベルの視点から考えます。実際、問題も難易度の高い物が多く、解説もいくらかの習熟と経験を必要としています。やはり初心者の方においそれとオススメ出来る物ではありません。しかし、だからこそ有益な情報が多かったと思います。
　中級以上だと自負する方、本書を読んで一歩先へ行ってみませんか？

　どもども、何気にまにあわなさげでひやひやな長月です。
　今日はアンドリュー･コーニグ、バーバラ・Ｅ・ムー著、Accelerated C++ の１３～１６章をお送りします。これで Acce