(つまり、おれは常識がないように思う。聞かれると確かによくわからないと言えばわからないわけだし)追記:sawatさんのコメント。この程度のプロパティの説明に「ブロッキングモードのソケットに対する擬似ノンブロッキング処理を行う場合の読み込み可能性のチェックのために利用します。クライアントが送信するすべてのデータの受信完了を調べるためには、ブロッキングモードの場合はreadメソッドが0を返すまでreadを実行してください」みたいな噛んで含めるような説明が必要か(しかも、特定ユースケースの例しか挙げることはできないし)とか。現場では教えれば済むわけだけど。富豪的な別解:常に予想される送信データ長より大きなバッファを利用する。設計の多様性と戦うにはもちろん多様性は無条件に善だから、「最適化戦略の選択」と言い替えたい。ダックタイピング(というかRuby)と大規模開発(実装設計編)大規模開発の意味を、ここでは以下の要件として考えてみる。・実装の容易性(ここでの容易性というのは、コードが少なくて済む、制約――覚えなくてはならないこと。種々の規約、ライブラリ関数名、呼び出し手順、など――が少ないことを意味する)静的構成の多様性は、非機能要件の実装を運用時に多種類の中から選択可能だということを意味する。一定の粒度のコンポーネント(ビジネスコンポーネント)単位での入れ替え、削除、追加が可能なことを意味する。実装設計の最適化とは、上記、静的構成の多様性を許容可能とするための制約を実装設計に対してあらかじめ含めることを直接には意味する。実装の容易性とは、実装者が一定の手順を遵守することで比較的に均質なモジュールを実装できることを意味する。従来このような実装のための方策として選択されたのは、フレームワークである(注:しまった。後で書こうと思って、「注」とアノテーションを入れたのは良いが、書くべき内容を忘れた。いう文章では()を使うべきだ)。フレームワークとは、3種の類型実装からテンプレートを経由して自動生成へ進む過程のある段階のソフトウェア(構造、環境、実装)を示す。フレームワークが実装に課す制約の多くは型判定に基づく(例:C++の仮想関数、Javaのinterface)か、またはクラスの継承関係に基づく(例:Rails)。これらは相互に排他ではなく、相互に補完しあう。例:C++の仮想関数とクラスの継承関係。ダックタイピングは基本的に型を利用しない。ダックタイピングに対する危惧は、名前による制約の有効性にあると仮定する。実装の容易性を破壊するのではないか、という危惧である。#あ、最初に考えていたのとは異なるソリューションを見つけた。shelarcyさんかmumurikさんか、あるいは両方だと思うが、えらく褒めていたのを見て、購入したものの放置していたわけだが、やっと読み始めて、しびれまくり。雅章)そうそう、「直行性」だよね、言葉は。機能要件と非機能要件は直行していなければならないし、さらに各非機能要件は相互に直交していなければならない(各機能要件には直交していなければならないという制約は完全に、まったくもって、存在しない。機能要件に対する制約は原理的にはビジネス以外には存在してはならない)。言え、そんなに単純ではない(たとえば本書の例だと削除時の呼び出しとコンテナの実装方法)。したがって宇宙船を操縦することにもそれなりの意味があるということになる。正直なところ能天気な本だなぁという気も実はするのだが、でも考えてみるまでもなく、ここまでフルに言語の機能を理解していたわけではない。推薦文のスコットメイヤーの坦懐な述懐もいい。機能を知っていることと、機能を利用することには確かに差がある。Effectiveな本であれば確かにその通りだ。尊敬に値する著者だなぁ>スコットメイヤー。実装設計について考える必要がある人には、いまさらながら強く推薦する。これは価値がある本だ。C++の暗号的なコードの本でもあるので、そこをどう気にするかだな。Lispで、<>にアレルギーがなければ本書、なのかも(適当)。typedefは暗号のような記述を簡潔にするだけではなく、シンボルとして実装を隠蔽するためのものである、というのは言われてみればその通りなわけだが、そういう意識しないことを言語化した知見にもあふれている。#第1章を読んだだけだけど、ある意味、これだけでも十分に価値があった。