読書感想文

Posts filed under 読書感想文

オンナノコになりたい!

Filed in 読書感想文

 オンナノコになりたい! と同コスプレ編が届いた。
 思ったより薄かったので徹夜明けで眠いのも押して通読してみた。
1. オンナノコになりたい 三葉
 なんていうか説明的で淡々としているので読みやすいです。
 その代わり衝動を掻き立てるような物ではないのでやる気の人でないとこの本がきっかけで女装しましたってことはないと思います。
 ちょっと知識のある人なら大半知ってることでもあるので、本当の初心者の人が基礎を知りたいときに買うべきだと思います。知ってることばっかり並んでいるとどんどんさめていきます。ふーん、ぱらぱらーな感じですね。
 残念ながら葵さんはこの本楽しめないです。
2. オンナノコになりたい コスプレ編 三葉
 そして前巻を踏まえてコスプレに応用しましょうという本書。
 前巻よりも扇動的な言葉が多かったり、専門的な話に及んでる分脳の肉欲を満たす目的にはよかったです。前巻とあわせて初心者の方がもう一歩進むのに有益な情報が載ってると重います。
 本巻だけでは舌足らずな部分があることと、前巻だけでは物足りないことを考えると二冊そろえて初めて価値が出るかもしれません。
 葵さん的にはこちらの方が楽しめました。「自分の体型に近いマネキンを是非1体は持つと良いでしょう」は名言だと思います。
#実はこっそり一緒にこんな本も買ってたり。
#でも今タブレットがないの(´;ω;`)

書籍レビュー目次

Filed in , 読書感想文

漫画

恋愛物

コンピュータ

プログラミング

技術

マネジメント

卓上ゲーム

囲碁

Effective C++ 原著第3版

Filed in 読書感想文

 C++プログラマなら余さず読めというレベルの定番書。
 誰もが一度は注意書きを目にする作法から最新の手法まで幅広く「効率」の視点から解説している本。
 と書くと誤解されがちだが、着眼点として効率を重視しているものの、効率という言葉の定義を広く持っており、実行効率だけではなく開発効率も考慮している為、いわゆる速度重視や空間重視による過激なデザインやコーディングはこの本には現れない。
 多少マニアックとも思える新しい手法 (例外安全なswapによる例外安全なコンストラクタの記述、ポリシークラス、TR1、等) も登場するが、あくまで元のトピックの添え物としての解説にとどめている為、主題がぼやけていない所は評価すべきだろう。
 この本は前作である改訂第2版もベストセラーだったので、改定第2版を読んだ事のある方も多いだろう。
 その中には第2版を読んだから大差ないだろうと考える向きもあるかと思うが、本作では新たなファクタとしてstd::tr1で加わる新たな標準ライブラリの機能やModern C++ Design、Exceptional C++から得た新たな手法も登場し、前作にない知識を与えてくれる。前作を読んだ方にも是非読んで欲しい一冊だ。

エンジニアのための時間管理術

Filed in , 読書感想文

 何かとスケジュール管理が苦手な長月がそろそろ勉強するかと衝動買いした本。
 何故一般的なタイムマネジメントTipsがエンジニアに向かないのかの説明から始まって解りやすく取っ掛かり易いテクニックの紹介。基本的なツールの使用方法。高度なテクニックとツール使用の応用と進んでいく。
 エンジニアと銘打ってあるのでプログラマ向けだと思っていたら、どうもプログラマではなくシステム管理者向けらしい。ただ、どちらも状況としては大きく違うものではなく、割り込みが多く作業がいつでも積もっている物なのでほぼそのままで流用できると思っていい。
 書かれているテクニックは一般的に行われているものと大差ないし、熟練したエンジニアであれば自然と身につけているものも多い。ただ、それぞれのテクニックにほんの少しエンジニアらしいマニアックなツール等が顔を出す。
 この本のテクニック全てでなくても、いくつかやりやすいものを採用することで改善されるものもあるはずなので、出来るだけ多くの人に読んでもらいたい一冊。

久しぶりに読み返してみる

Filed in 囲碁, , 読書感想文

 久しぶりに依田ノートを読み返し中。
 なんとなく思いつきで読み返し始めた物の、割とアリな行動だったみたいです。
 忘れてますね、棋理。しばらくまともに囲碁打ってないですからね。打ってないというか触れてないですから……orz
 改めて読んでみると、内容は良書なんだけど構成はダメだよなーとか割とありがちな感想が浮かんできました。そんな感想見飽きましたかそうですか。
 まあそんな訳でリハビリにしばらく棋書読み漁ってみるかなとか思う次第です。さしあたっては達人囲碁指南シリーズ読破とか。

リアルタイム/マルチタスクシステムの徹底研究

Filed in prog, , 読書感想文

 良書。
 もうすぐ組込みプログラムをお仕事で書く立場になるので勉強の為に買ってみました。どうやらこの選択は正解のようです。
 組込み系の世界で利用される技術を比較的わかりやすく読みやすくまとめています。
 専門分野の本だけあって少々前提知識を必要としますが、この本に興味を持つ人なら大丈夫でしょう。
 入門者向けの物をお求めなら「はじめて読む486」やなぜ動くのかシリーズをオススメします。

GoF本第四章その5: Decorator

Filed in C/C++, prog, , 読書感想文

 仕事中に右手人差し指の先を切り、さらに右手中指の爪が割れて先の方が五分の一ほど剥がれかけな長月です。皆様はご健勝でしょうか? 長月は本人も仮想世界への代理人も割と不健康な感じです。皆様はご自愛ください。
 さて、キーボードが少し打ちづらいながらも基本的に左利き寄りの両利きの為割と生活には支障ないのでいつも通りエントリは追加される訳です。今日はもうそろそろ見てる方々も飽きてきたであろう GoF本 第4章から Decorator パターンです。
 Decorator パターンはオブジェクトに動的に責任を追加するパターンです。ロジックとしては前回取り上げた Composite パターンと似ています。Composite パターンは、コンテナとプリミティブなクラスを同じクラス階層に置く事でツリー状にお互いを包含する構造を作り出し、部分と全体に差を無くすパターンでした。Decorator パターンの場合も、Composite パターンでも行われた様に、全体を俯瞰する為のルートクラスを用意し、Decorator に当たるサブクラスではルートクラスのオブジェクトへの参照を持つ事で連鎖します。Composite パターンとの違いはルートクラスのインターフェイスが最大化しない事ですかね。
 Decorator パターンは、個々のオブジェクトに責任を追加し、且つ他のオブジェクトへの影響を最小化すべき時。責任の追加に加えて、責任の削除が出来るべき時。サブクラス化による責任追加が現実的ではない時。等に利用されます。
 Decorator パターンは継承を用いた拡張よりも柔軟です。また、クラス階層の上位のクラスが、所謂「スーパーマンクラス」になる事を防ぎます。
 しかし、ある Decorator クラスが装飾しているクラスはその Decorator クラスと同一ではないので、同一性に期待したコーディングが出来ない。非常に似通った小さなクラスが氾濫する。と言う欠点も持ちます。
 前述の通り Decorator パターンは Composite パターンと似通っています。構造を良く見てみれば内部に持つオブジェクトが一つに制限された Composite パターンに見えます。しかし Decorator パターンはオブジェクトの集約を目的としている訳ではありません。Decorator パターンはオブジェクトに責任を追加します。
 長月は Decorator パターンを余り使った事がないんですよね。もしかしたらやってるかもしれませんが、意識して使った事って少ないです。なんと言うか、動的に責任を追加する場面が余りないというか。そんなトリックが必要になるほど複雑な物を作ってないというか。そもそも殆どプログラム書いてな……げふっ(吐血
 まあそんな訳で今回はここまで、次回はおそらく長月の理解度が本書中一番低い Facade パターンをお送りします。

GoF本第四章その4: Composite

Filed in C/C++, prog, , 読書感想文

 今日は構造に関するパターンの三つ目、Composite パターンをお送りします。
 Composite パターンは複数のオブジェクトを合成します。また、合成されたまとめオブジェクトを一様に扱えるのが特徴です。
 プリミティブなオブジェクトを組み合わせる事で複雑なオブジェクトを構成する事はままあると思います。しかし、その時にそれらのオブジェクトを一様に扱う事に困難を覚えた事はありませんか? 例えば、プリミティブなオブジェクトをまとめて扱う方法としてコンテナへの格納は一手でしょう。しかし、プリミティブなオブジェクトとプリミティブなオブジェクトを集めたコンテナは別物です。いくつかのオブジェクトをまとめた物と、単一のオブジェクトを区別なく扱う。それが Composite パターンの提供する合成です。
 Composite パターンでは、プリミティブなクラスとコンテナクラスを同じクラス階層に置きます。詰まり一つの抽象クラスがコンテナでも、プリミティブなクラスでもあるのです。
 例として GUI コンポーネントを考えてみましょう。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 パターンをお送りします。

GoF本第四章その3: Bridge

Filed in C/C++, prog, , 読書感想文

 構造に関するパターンの二つ目は、前回も書いた通り Bridge パターンです。
 Bridge パターンは Handle/Body とも呼ばれ、割と良く使われているパターンだと思います。Bridge パターンはパブリックなクラスの定義と実装を分離し、それらを独立に変更できるようにしたパターンです。
 実装の分離と言うと pimpl イディオムを思い出しますね。あれも Bridge パターンの一形態だと思います。しかし Bridge パターンでは、実装の分離に関する思惑が pimpl イディオムとは違います。Bridge パターンは、実装上の汎化関係にあるクラスの関係を意味上の汎化関係を分離します。一般的に汎化関係は抽象クラスと継承を用いて表現されますが、クラス階層の中に実装上の汎化関係と意味上の汎化関係が混在すると、それぞれを独立に変更する事が困難になります。
 そんな場合、Bridge パターンを用いて実装と意味の階層を分離します。クライアントが参照する物は意味の階層、意味の階層の中で実装上必要とする物は実装の階層で定義する事で、クラス階層単位でのインターフェイスと実装の分離を実現します。
 Bridge パターンは抽出されたクラスとその実装を分離し、実装を動的に選択したり交換したりしなければならない場合、抽出されたクラスとその実装を両方ともサブクラス化によって拡張可能にする場合、抽出されたクラスの実装が変更によってクライアントに影響を与えるべきではない時、C++のような言語で実装を隠蔽したい時、複数のオブジェクト間でクライアントから隠蔽した状態で実装を共有したい場合等に使用されます。
 C++のような言語で実装を隠蔽するというのはまさに pimpl イディオムですね。一番良く使われる Bridge パターンではないでしょうか。
 Bridge パターンと Adapter パターンはクラス同士を繋ぐという関係では同じです。しかし Adapter パターンは既にあるクラス等、設計後に適用される事が多いのに対し、Bridge パターンは抽出されたクラスと実装を分離する為に、言い換えれば外部に向けた設計と実装を分離する為に、設計の早期に適用されます。
 長月は割と最近まで Bridge パターンを軽視していました。Bridge パターンというより pimpl イディオムですね。Exceptional C++ を読んでからは考えを改めたのですが、実装の隠蔽以外の意味で使用する Bridge パターンも馬鹿に出来ませんね。解っているつもりでやっぱり「ああなるほど」と思う所もいくつかありました。いや、本は読むものです。
 では今回はここまで、次回は Composite パターンをお送りします。

GoF本第四章その2: Adapter

Filed in C/C++, prog, , 読書感想文

 今回から数回は構造に関するパターンのカタログです。今回は 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 パターンと言えますね。C++に於ける pimpl にはソースファイルの依存性軽減とか Bridge パターン本来の目的とは違う物も含まれるので Bridge パターンそのものとは言えないかも知れませんけどね。
 では、今回はここまで。(=゚ω゚)ノシ


Warning: sprintf() [function.sprintf]: Too few arguments in /home/users/2/lolipop.jp-dp07042166/web/wordpress/wp-includes/widgets.php on line 1042
Oenology Post Formats
Click to view/hide

Warning: sprintf() [function.sprintf]: Too few arguments in /home/users/2/lolipop.jp-dp07042166/web/wordpress/wp-includes/widgets.php on line 1042
Posts Calendar
Click to view/hide
2017年5月
« 12月    
 123456
78910111213
14151617181920
21222324252627
28293031  

Warning: sprintf() [function.sprintf]: Too few arguments in /home/users/2/lolipop.jp-dp07042166/web/wordpress/wp-includes/widgets.php on line 1042
アーカイブ
Click to view/hide

Warning: sprintf() [function.sprintf]: Too few arguments in /home/users/2/lolipop.jp-dp07042166/web/wordpress/wp-includes/widgets.php on line 1042
最近の投稿
Click to view/hide