ストラウストラップのプログラミング入門(21) 第13章「グラフィックスクラス」

『ストラウストラップのプログラミング入門』を読む。今日は第13章「グラフィックスクラス」です。

12〜16章では、著者が作成したインタフェースクラス（ライブラリのラッパー）を介して、FLTKライブラリを使います。13章は、インタフェースクラスの設計の解説です。図形に対応する1つ1つのコードについて、なぜそういう設計にしたのか、著者の解説に耳を傾けつつ考える、といった内容です。

冒頭には、「この後の説明を読む際には、あまり先を急がないように」という警句があります。ほい。御意。

そうそう、焦点？ハテ？って感じだったので、貼っておきます。楕円なんて、もう忘れちゃいましたよ…。

基底クラス、派生クラスという概念が出てきます。structに対しても、基底「クラス」というのですね。

13章では、差分プログラミングが主に解説されます。多態性の話は出てきません。継承の詳細は、14章以降で解説されるようです。

13.15で、引数有りコンストラクタの中で、「基底クラス部分を初期化する」という構文が出てきます。これは、Javaのコンストラクタに書く super(引数); みたいなものだろうと思っています。

インタフェースクラスには、線（Line）をグルーピングするLinesというデータ構造が定義されています。

Lineは、2つの点（Point）によって定義されます。一方、Linesは、Lineのvectorではなく、Pointの集合によって定義されます。

Linesに線を追加するには、Pointを一組追加します。「1個のLine」を追加するのではありません。なんで？？ねえ、どうして？？

13章で疑問だった箇所はダントツでこれでした。複数の線を表すときに、線のコレクションではなく、点のコレクションとして保持すると、いったい何がうれしいのでしょうか。

また、Linesを描画する関数（draw_lines）では、Pointを2個ずつ取り出して線を引きます。つまり、線の集合から1本の線を取り出すには、必ず操作を必要とするわけです。なぜ、データ構造だけで線を線として識別できるようにしないのでしょう？

・・・しかし、結局理解を保留しました。図形と描画に関する実装の詳細は14章で解説されるようなので、待つことにします。

ちなみに、「Lineの集合で表現されるLines」を試しに書こうとしてみて分かったのは、

というあたりです。（一旦退却...）

名前のないオブジェクトが登場しました。

これって、行きはよいよい帰りはこわい、ですね。（図形の場合）attachするのはよいけれど、detachするのがしんどいです。個々の要素を特定するためには、毎回計算しなくちゃいけないのでしょうか？でも、それしかないですよね。

名前無しオブジェクトのサブセットに名前を付けて保持したり、jQueryのendみたいにバックアップ取ったり、できる（やってよい）のでしょうか。

9.3で、structは次のように紹介されました。（p.262）

structは、メンバがデフォルトでパブリックなclassである。（略）structは主に、メンバが任意の値を持つことができるデータ構造に使用される。つまり、意味のある不変条件を定義することはできない。

13章の図形は、すべてstructで実装されています。たとえば、楕円（Ellipse）の定義は相当複雑です。また、Polygonのメンバには、事前チェックが書かれています。こういうのはstructとしてアリなのでしょうか。

等々。

追記（2011/10/02）: 気にしなくてOK、みたいなことが14章の14.3.2に書いてありました。

13.13では、円（Circle）と楕円（Ellipse）の実装の相違を、表したい概念（＝幾何学のルール）の相違に遡って解説した上で、次のことが述べられています。

クラスを設計する際には、技巧に走りすぎないようにし、「直観」に惑わされてクラスとして意味を成さないクラスを定義しないように注意しなければならない。逆に言うと、クラスが一貫性のある概念を表しているかどうかに注意し、データと関数メンバの単なるコレクションにならないようにしなければならない。

幾何学のルールは、要件としてまだコードに落としやすそうですよね。業務も、数学の公式みたいに表現できればいいのに。。。なんて。

# もちろん、記号論・意味論を使えば可能だと思いますが、実際にそういうアプローチを取っているのを身近では見たことがないです。また、その効果も、自分にはよく分かりません…。

やりました。