日々の破片

_ 多様性は悪

設計の多様性と戦うには

もちろん多様性は無条件に善だから、「最適化戦略の選択」と言い替えたい。

_ ダックタイピング(というかRuby)と大規模開発(実装設計編)

大規模開発の意味を、ここでは以下の要件として考えてみる。

・静的構成の多様性

・実装設計の最適化

・実装の容易性（ここでの容易性というのは、コードが少なくて済む、制約――覚えなくてはならないこと。たとえば種々の規約、ライブラリ関数名、呼び出し手順、など――が少ないことを意味する）

静的構成の多様性は、非機能要件の実装を運用時に多種類の中から選択可能だということを意味する。また、一定の粒度のコンポーネント（ビジネスコンポーネント）単位での入れ替え、削除、追加が可能なことを意味する。

実装設計の最適化とは、上記、静的構成の多様性を許容可能とするための制約を実装設計に対してあらかじめ含めることを直接には意味する。

実装の容易性とは、実装者が一定の手順を遵守することで比較的に均質なモジュールを実装できることを意味する。

従来このような実装のための方策として選択されたのは、フレームワークである（注：しまった。後で書こうと思って、「注」とアノテーションを入れたのは良いが、書くべき内容を忘れた。やっぱりこういう文章では()を使うべきだ）。

フレームワークとは、3種の類型実装からテンプレートを経由して自動生成へ進む過程のある段階のソフトウェア（構造、環境、実装）を示す。

フレームワークが実装に課す制約の多くは型判定に基づく(例：C++の仮想関数、Javaのinterface)か、またはクラスの継承関係に基づく（例：Rails）。これらは相互に排他ではなく、相互に補完しあう。例：C++の仮想関数とクラスの継承関係。

ダックタイピングは基本的に型を利用しない。

そうではなく、名前に基づく。

ダックタイピングに対する危惧は、名前による制約の有効性にあると仮定する。

これは、以下の3点のうち、

・静的構成の多様性

・実装設計の最適化

・実装の容易性

実装の容易性を破壊するのではないか、という危惧である。

#あ、最初に考えていたのとは異なるソリューションを見つけた。もうちょっと考えてみる。

_ いまさら読んだが、最高に刺激的

多分、shelarcyさんかmumurikさんか、あるいは両方だと思うが、えらく褒めていたのを見て、購入したものの放置していたわけだが、やっと読み始めて、しびれまくり。

Modern C++ Design―ジェネリック・プログラミングおよびデザイン・パターンを利用するための究極のテンプレート活用術 (C++ In‐Depth Series)(アンドレイ アレキサンドレスク)

そうそう、「直行性」だよね、言葉は。機能要件と非機能要件は直行していなければならないし、さらに各非機能要件は相互に直交していなければならない（各機能要件には直交していなければならないという制約は完全に、まったくもって、存在しない。機能要件に対する制約は原理的にはビジネス以外には存在してはならない）。

とは言え、そんなに単純ではない（たとえば本書の例だと削除時の呼び出しとコンテナの実装方法）。したがって宇宙船を操縦することにもそれなりの意味があるということになる。

正直なところ能天気な本だなぁという気も実はするのだが、でも考えてみるまでもなく、ここまでフルに言語の機能を理解していたわけではない。

推薦文のスコットメイヤーの坦懐な述懐もいい。機能を知っていることと、機能を利用することには確かに差がある。Effectiveな本であれば確かにその通りだ。尊敬に値する著者だなぁ＞スコットメイヤー。

実装設計について考える必要がある人には、いまさらながら強く推薦する。これは価値がある本だ。でも、C++の暗号的なコードの本でもあるので、そこをどう気にするかだな。多分、()にアレルギーがなければOn Lispで、<>にアレルギーがなければ本書、なのかも（適当）。

typedefは暗号のような記述を簡潔にするだけではなく、シンボルとして実装を隠蔽するためのものである、というのは言われてみればその通りなわけだが、そういう意識しないことを言語化した知見にもあふれている。

#第1章を読んだだけだけど、ある意味、これだけでも十分に価値があった。

_ 名前の保証

実行してみる。外れれば外れ。

機械的に外挿しする。

後者はもちろん保証できるのだが、どうやって外挿しするのかという問題もある。むしろ、前者を推進できる環境が良いのではないか？

_ 筒井康隆の先見の明

金持ち娘と貧乏娘、性格の良いのはどっち？ みたいなやつを読んだ記憶が甦ってきたが、大まかにはあの結論は合ってるんだろうなぁと思ってみたり。