手元ではもう概ね読了しています。ブログに書くのは一旦ここまでで終了しようかなと思っています… こうやって書き出すよりいろいろ作って実践していったほうが身につくのは早そうなので…。

モジュールのパッケージ

1. ライブラリパスの通ったディレクトリ下にディレクトリを作成
2. その下に Python モジュールとして読み込ませるクラスや関数を書いた .py ファイルを作成
3. ↑と同じ場所に __init__.py という名前の空のファイルを作成

ロードするときは、ディレクトリ名が package_dir で、その配下にある hoge.py ファイルに定義されたクラスや関数をすべてロードする場合、以下の通りとなる。

from package_dir import hoge

# MyHogeHoge クラスのコンストラクタを呼ぶ場合
x = hoge.MyHogeHoge('params', '...')

名前空間はディレクトリ名、ファイル名にがっつり依存するので、ファイル構成は結構気をつけたほうが良さそうです…。

defaultdict

Python の辞書は存在しないキーを指定して参照しようとするとエラーになるので、キーが存在しない可能性がある場合は in でテストするか get() メソッド (存在しない場合はデフォルト値が返される) を介する必要があります。これは存在しないキーを指定してもデフォルトでエラーにならない Perl の連想配列の実装に比べて利点だと思うのですが (この挙動のおかげでバグを作りこんでしまうことが Perl の場合は本当に多い)、 defaultdict() はこの悪しき Perl の連想配列に似た挙動がデフォルトである上に、一度参照してしまうとそのキーにデフォルト値が割り当てられてしまうという最悪な動きをする代物です。

こんなの使うことあるんでしょうか…(´･_･`)

組み込みの辞書よりもスクリプト然としたコードを書くのに向いているのかもしれませんが (本書に示されている独自カウンタのサンプルのような… それもその直後に Counter を用いたずっと簡潔な書き方を示すことでくつがえ)、その割には冒頭で割と覚えにくい名前のパッケージ名からロードしてあげないといけないのも使い勝手としてはいまいちです。

Counter

積集合、和集合が取れるのがいいですね。

OrderedDict

Perl では古の pseudo hash を思い出しました…(‘A`)

その他

いろいろあるみたいですが、必要に応じて探してくれば良いのかなと思います。

「入門Python3」は電子版を購入したのですが、 O’reilly の電子書籍は一度購入してしまえば O’reilly のサイトからいつでもどこでもダウンロードできます。閲覧規制が若干厳しい職場の環境でもダウンロードできたので何気に便利で快適です^^。

今回は 4章の 4.6節から。手元ではすでに 8章の途中ぐらいまで概ね読み終わっているのですが、今回は 4章までの内容について記述します。

内包表記

Python をして、もっともスクリプト言語らしい機能のひとつであるように思います。ザ・構文糖衣。

number_list = [n for n in range(0, 10)]

ちなみにこれ、Perl で書くとこうなります。

@number_list = (0..9)

他の LL を学べば学ぶほど、 Perl が如何にスクリプト然としているかがよく分かるという一例です…。

なお、 Python は range にしてもスライスにしても、終端値は含まれないことに注意する必要があります。

range 自体にも step が指定できますが、内包表記の後ろに if 文を入れることでデータに含める値の条件を指定することもできます。下は凡庸な例ですが、既存のリストから条件を指定して値を抽出したいケースは多々あります。

even_list = [num for num in range(0, 6) if num % 2 == 0]  # 0, 2, 4

C# の Linq みたいなことをやりたい場合はジェネレータ内包表記でいろいろとできそうです… (例が思いつかないですが

可変長引数

* で始まる仮引数は位置引数のタプル、** で始まる仮引数はキーワード引数の辞書になる、というもの。

python の性質として面白いなと思うのは、位置引数とキーワード引数がこの仕組みによって完全に分離しうるということ。キーワード引数として指定しないと有効にならないパラメータ、なんてのも書こうと思えば書けてしまえるわけです。実際使うかは別として。

ラムダ

lambda a, b: b - a

のような構文で書けるみたいです。 (ソートの比較条件を指定する場面ってあるのかしら…?)

ジェネレータ

C# でいうところの IEnumerable みたいなもんですね。 yield キーワードは他の言語でもよく使われていてまぁまぁありふれた存在となりつつあります…。

デコレータ

可変長引数が最も活躍するやつです。 C# の Attribute みたいなもんですかね。

スコープと global 宣言

関数内で変数を使用する際、同じ名前の変数がすでにグローバル名前空間に存在するときの挙動が、最初に値を代入するのか、値を参照するのかで変わるという、実に気持ち悪い内容に困惑するなど。

グローバル変数にアクセスしたい場合は global 宣言を使え、はいいんですが、関数内で閉じたスコープで使いたい場合に特別な宣言が必要ないというのがどうにもしっくりこないですね。

例外

…については、 catch ではなく except であることと、 throw ではなく raise であること以外は普通だと思います。

複数の不等号を含む評価式が書ける

変数が取りうる値の範囲を調べる場合、その変数を and を挟んで 2回書く代わりに、複数の不等号を含む単一の評価式として書くことができる。

>>> x = 7
>>> 5 < x < 10
True
>>> x = 2
>>> 5 < x < 10
False
>>> y = 200
>>> 0 < x < 100 < y < 1000
True

こういう書き方できればいいのになぁと思うことは多々あったが、実際できる言語が存在するんですなぁ…。

ループブロックの else 節

ループブロックに else 節をつけると、 break 等による中断以外でループ終了する時に呼ばれるようです。

>>> numbers = []
>>> count = 0
>>> while count < 5:
...     val = input(str(count + 1) + "番目の整数を入力: ")
...     if val == 'q':
...             break
...     numbers.append(int(val))
...     count += 1
... else:
...     print(numbers, "の合計: ", sum(numbers))
... 
1番目の整数を入力: 1
2番目の整数を入力: 2
3番目の整数を入力: 3
4番目の整数を入力: 5
5番目の整数を入力: 7
[1, 2, 3, 5, 7] の合計:  18

使いどころはそれなりにあると思うのですが、これに else の名を冠するのは正直わかりにくい気もします…。

いろいろと便利な zip() 関数

複数のシーケンスを並列的に反復処理できる。

>>> pythonObj = 'tuple', 'list', 'dict', 'set'
>>> perlObj = 'list', 'list', 'hash', 'hash'
>>> cppObj = 'tuple', 'vector', 'unordered_map', 'unordered_set'
>>> mean = 'タプル', 'リスト (配列)', '辞書 (連想配列)', '集合'
>>> for py, pl, cpp, jp in zip(pythonObj, perlObj, cppObj, mean):
...     print('Python: ' + py + ', Perl: ' + pl + ', C++: ' + cpp + \
...     '\nこれは何? - ' + jp)
... 
Python: tuple, Perl: list, C++: tuple
これは何? - タプル
Python: list, Perl: list, C++: vector
これは何? - リスト (配列)
Python: dict, Perl: hash, C++: unordered_map
これは何? - 辞書 (連想配列)
Python: set, Perl: hash, C++: unordered_set
これは何? - 集合

また、2つのシーケンスを zip() したものを dict() に食わせることで、一方をキー、他方を値とする辞書が作れる。

>>> py2pl = dict(zip(pythonObj, perlObj))
>>> py2pl
{'tuple': 'list', 'set': 'hash', 'dict': 'hash', 'list': 'list'}

数列を作る range() 関数

リストのスライスが欲しいのではなく、数の並びそのものが欲しい場合は、 range() 関数を使えばいい。 Perl でいうところの範囲演算子 .. のようなもので、スライスと同様に step も指定できます。

>>> for x, y in zip(range(0, 3), range(3, 0, -1)):
...     print("x:", x, "/ y:", y)
... 
x: 0 / y: 3
x: 1 / y: 2
x: 2 / y: 1

range(x, y) で得られる数列の逆順が欲しい場合は、 range(y, x, -1) ではなく、 range(y-1, x-1, -1) とするか、または range(x, y)[::-1] とする必要があります。

>>> list(range(0, 3))
[0, 1, 2]
>>> list(range(3, 0, -1))
[3, 2, 1]
>>> list(range(2, -1, -1))
[2, 1, 0]
>>> range(0, 3)[::-1]
range(2, -1, -1)

range にスライスを指定するとリストではなく新たな range を生成するのは面白い特性ですね。

>>> range(0 ,100, 3)[10:20]
range(30, 60, 3)
>>> range(0 ,100, 3)[30:10:-5]
range(90, 30, -15)
>>> range(0 ,10, 3)[30:10:-5]
range(9, 9, -15)
>>> range(0 ,50, 3)[30:10:-5]
range(48, 30, -15)

…といった感じになるらしいです。

リストをコピーする方法が 3通りもある

意外と自由度高いな…。

>>> a = [1, 2, 3]
>>> b = a.copy()
>>> c = list(a)
>>> d = a[:]
>>> a[0] = 'hoge'
>>> a
['hoge', 2, 3]
>>> b
[1, 2, 3]
>>> c
[1, 2, 3]
>>> d
[1, 2, 3]

見た目だけなら d のやり方が一番好きだけど、パフォーマンス的にはどれが一番マシなんだろう…?

ちなみに辞書のコピーは 3.4.12 節では copy() メソッドによる方法しか示されていなかったが、少なくとも dict() コンストラクタを使う方法は同様にイケるっぽい。

Python ではリストとタプルは別物である

Perl で慣れてるのでこういう表現になります。

Perl では値をカンマで区切ったものは何でもリストになります。 Python では値をカンマで区切ったものはタプルとなり、要素の追加・削除・変更ができません。

局面に応じて値の並びをミュータブルに扱いたいかイミュータブルに扱いたいかを選べるようになっているのは良いことだと思います。そうなっていることで不便を感じることも多分無いと思います。 Perl のリストの仕組みに不便を感じたことはありませんが。

強いて言えば値 1個だけのタプルの書き方がちょっとキモイですね…。

>>> (1)
1
>>> 1,
(1,)

Perl みたいに丸かっこで括ったらリスト、じゃないやタプルとして扱われる、でも良かった気もしますが…

ただ、C++ や C# などでライブラリに存在するタプルオブジェクトなんかに比べれば、これが本来タプルに求められるべき使い勝手なんだろうな、という気はします…(´・ω・`)。

dict コンストラクタ

2要素のタプルのタプルからでも生成できるみたいだけど、引数にタプルのリテラルを指定する場合はカッコをいっぱい挟まないといけない模様…(´・ω・`)

>>> dict(1, 2, 3, 4, 5, 6)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: dict expected at most 1 arguments, got 6
>>> dict((1, 2), (3, 4), (5, 6))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: dict expected at most 1 arguments, got 3
>>> dict(((1, 2), (3, 4), (5, 6)))
{1: 2, 3: 4, 5: 6}

dict コンストラクタに指定できる引数の数が 1つだけなので、まぁ当然っちゃ当然ですが… 素直に { 〜 } 使えってことですね。

dict_keys はそのまま sorted に渡せる

辞書の keys() メソッドは dict_keys オブジェクトを返す。リストとして扱うには list() コンストラクタに渡す必要があるが、ソートしたキーの一覧が必要な場合はそのまま sorted() 関数に渡せばいいっぽい。

>>> da = { 'hoge': 'foo', 'fuga': 'bar', 'piyo': 'baz', 'piyopiyo': 'qux' }
>>> da.keys()
dict_keys(['hoge', 'piyo', 'piyopiyo', 'fuga'])
>>> list(da.keys())
['hoge', 'piyo', 'piyopiyo', 'fuga']
>>> sorted(da.keys())
['fuga', 'hoge', 'piyo', 'piyopiyo']

辞書のキーの集合を得るなら keys() メソッドの呼び出しも不要

これは 3.5.2 節に記載の通り。集合は for ループで回すこともできるので、普通の用途ならそもそもリストにする必要はないってことだやね。

>>> da = {'hoge': 'foo', 'fuga': 'bar', 'piyo': 'baz', 'piyopiyo': 'qux'}
>>> set(da)
{'hoge', 'piyopiyo', 'fuga', 'piyo'}
>>> for a in set(da):
...     print(a)
... 
hoge
piyopiyo
fuga
piyo

本当に for ループで回すだけなら keys() が返す dict_keys でもイケるようですが。

>>> for a in da.keys():
...     print(a)
... 
hoge
piyo
piyopiyo
fuga

集合の使い勝手はむしろ集合同士の比較演算にあるようです。 (3.5.4 節)

辞書はキーにタプルが使える

タプルとそれ以外との混在も可能っぽい。

>>> da = {'foo': 1, 'bar': 2, ('foo', 'bar'): 3, 'baz': 4, ('foo', 'baz'): 5}
>>> da
{'bar': 2, 'baz': 4, ('foo', 'bar'): 3, 'foo': 1, ('foo', 'baz'): 5}
>>> da['foo', 'bar']
3

DBMS でも 2つのカラムが PK になる場合とかありうるので、データ構造が無駄に複雑にならなくて済む場合もあってよさそう。

list コンストラクタに文字列を渡すと一文字ずつに分解してリスト化する

>>> list('cat')
['c', 'a', 't']

率直に言って気持ち悪いですね(´・ω・`)

タプルも同じですか。

>>> tuple('cat')
('c', 'a', 't')

素直に [〜] とか (〜) とか使えって話ですね。

[0] はいくつでも重ねられる

リストのリストをいじっていて気づいたのですが、

>>> arr = [['foo', 'bar', 'baz'], ['hoge', 'fuga', 'piyo'], [1, 2, 3]]
>>> arr[0]
['foo', 'bar', 'baz']
>>> arr[0][0]
'foo'
>>> arr[0][0][0]
'f'

ここまではわかるのですが、

>>> arr[0][0][0][0]
'f'

あ、これできちゃうんだ、と。

確かに、文字列のオフセット位置を指定して抽出した文字も型としては同じ str 型なので当然と言えば当然なのですが、なんだかもにょる…(´・ω・`)

リストから同値の要素を除去する remove() メソッドの挙動

リストの先頭から検索して最初に hit した要素を削除する。 hit するものがないとエラーになる。

>>> arr = ['foo', 'bar', 'baz', 'bar', 'qux', 'quux']
>>> arr
['foo', 'bar', 'baz', 'bar', 'qux', 'quux']
>>> arr.remove('bar')
>>> arr
['foo', 'baz', 'bar', 'qux', 'quux']
>>> arr.remove('bar')
>>> arr
['foo', 'baz', 'qux', 'quux']
>>> arr.remove('bar')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: list.remove(x): x not in list

…使いみちあるの? これ(´・ω・`)

index() メソッドも hit しないとエラーになる。先に in 演算子でテストしておかないとダメってことやね。

>>> arr = ['foo', 'bar', 'baz', 'bar', 'qux', 'quux']
>>> arr.index('bar')
1
>>> arr.remove('bar')
>>> arr
['foo', 'baz', 'bar', 'qux', 'quux']
>>> arr.index('bar')
2
>>> arr.remove('bar')
>>> arr
['foo', 'baz', 'qux', 'quux']
>>> arr.index('bar')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: 'bar' is not in list

== 演算子でリストの内容を比較できちゃう?

join() メソッドに関するサンプルを試していて思ったのですが…

>>> arr = ['foo', 'bar', 'baz']
>>> sep = ':'
>>> joined = sep.join(arr)
>>> joined
'foo:bar:baz'
>>> separated = joined.split(sep)
>>> separated
['foo', 'bar', 'baz']
>>> separated == arr
True

ものすごく当たり前のことのように配列同士で比較が行われていてすげぇーってなりました…。

>>> arr1 = ['foo', 'bar', 'baz']
>>> arr2 = ['foo', 'bar', 'baz']
>>> arr1 == arr2
True
>>> arr1 = [['foo', 'bar', 'baz'], ['hoge', 'fuga', 'piyo']]
>>> arr2 = [['foo', 'bar', 'baz'], ['hoge', 'fuga', 'piyo']]
>>> arr1 == arr2
True
>>> arr3 = [['foo', 'bar', 'baz'], ['hoge', 'fuga', 'poyo']] #ちょこっと違う
>>> arr1 == arr3
False

階層深くしてもちゃんと比較してくれてますね…。

履修した中で気づいたことなどをちらほらとメモってみることにします。

/ は浮動小数点数の演算になる

演算子の左右が整数であっても、評価結果は必ず浮動小数点数になる。

整数の割り算を行いたい場合は // を使用する。

>>> 9 / 4
2.25
>>> 9 // 4
2

整数型はサイズの制限がない

Python3 では long 型が廃止され、 int 型は際限なく大きい値を取り扱えるようになっている。オーバーフロー例外は起こりえない。

面白いけど、 DBMS で取り扱われる整数だってサイズ制限はあるし、そこまでメリットあるのかなぁ…? 効率面との兼ね合いとかもどう折り合いをつけているんだろう? (ソースコード嫁>ヲレ)

スライスはステップも指定できる

begin:end:step、という構文。

文字列に対してもスライスを適用することができて、文字列を逆さにしたい場合はステップを -1 にしてやればいい。

>>> alpha = 'abcdefghijklmnopqrstuvwxyz'
>>> alpha[::-1]
'zyxwvutsrqponmlkjihgfedcba'

• cppgen.pl

Getopt::Compact モジュールを使用しています。ご利用の際にはそちらも合わせてインストールしてあげてください。

ツールの特徴としては以下のとおりです。

• 名前空間とクラス名を指定すると、それらから類推される名前でファイル名や include guard シンボル名を設定し、ひな形を生成する。これらの指定は必須。
  • 名前空間は 1階層にしか対応してません…。
• doxygen フォーマット (javadoc 風) でコメントを付加。
  • -s オプションでクラスの概要 (@brief) を指定可能。省略した場合はクラス名を使用。
• クラスの public 継承、仮想クラス、インタフェースクラスに対応。
• Pimpl に対応 (構造体及びメンバ変数名は固定です…)。
• Boost.noncopyable に対応。
• コピーコンストラクタ、ムーブコンストラクタを自力実装するようにプレースホルダを設ける機能に対応。

使い方ですが、例えば以下のようにすると、

$ perl cppgen.pl -c Observer -d hoge -s 'オブザーバーインタフェース' -in
$ perl cppgen.pl -c Subject -d hoge -s 'サブジェクト抽象クラス' -vpn
$ perl cppgen.pl -c ConsoleView -d hoge -s 'コンソールビュー抽象クラス' -e Subject -p
$ perl cppgen.pl -c StaticText -d hoge -s 'コンソールに静的にテキストを表示するビュークラス' -e ConsoleView -p
$ perl cppgen.pl -c DateTime -d hoge -s '日時を扱うクラス' -pCM
$ perl cppgen.pl -c WatchController -d hoge -s '時計コントローラ' -e Observer -p
$ perl cppgen.pl -c ConsoleManager -d hoge -s 'コンソール操作管理クラス' -pn
$ ls
console-manager.cpp  console-view.h  date-time.h      static-text.h  watch-controller.cpp
console-manager.h    cppgen.pl       observer.h       subject.cpp    watch-controller.h
console-view.cpp     date-time.cpp   static-text.cpp  subject.h

以下のような構成でファイルが生成されます。

• Observer クラス … noncopyable なインタフェースクラス (observer.h のみ)
• Subject クラス … Pimpl を持つ noncopyable な抽象クラス (subject.h, subject.cpp)
• ConsoleView クラス … Subject を継承し、 Pimpl を持つ抽象クラス (console-view.h, console-view.cpp)
  • 他のクラスを継承するクラスは強制的に抽象クラスになります (デストラクタが virtual になる)。当たり前ですが…。
• StaticText クラス … ConsoleView クラスを継承し、 Pimpl を持つ抽象クラス (static-text.h, static-text.cpp)
• DateTime クラス … Pimpl を持ち、コピーコンストラクタ、ムーブコンストラクタのプレースホルダを持つクラス (date-time.h, date-time.cpp)
• WatchController クラス … Observer クラスを継承し、 Pimpl を持つ抽象クラス (watch-controller.h, watch-controller.cpp)
• ConsoleManager クラス … Pimpl を持つ noncopyable なクラス (console-manager.h, console-manager.cpp)

詳しくは -h オプションでヘルプを見るか、ソースを参照してください (^_^; 。

$ perl gencpp.pl -c DomNodeFromId -d hoge -t 'class NodeType' -ns 'ID を指定して DOM ノードを検索するラッパーオブジェクトクラス'

とかやると、以下の内容のヘッダファイル dom-node-from-id.h のみが生成されます。

/**
    @file   dom-node-from-id.h
    @brief  ID を指定して DOM ノードを検索するラッパーオブジェクトクラス定義  
*/
#ifndef HOGE_DOM_NODE_FROM_ID_H
#define HOGE_DOM_NODE_FROM_ID_H


namespace hoge {

/**
    @brief  ID を指定して DOM ノードを検索するラッパーオブジェクトクラス  
*/
template <class NodeType>
class DomNodeFromId {
    /// コピーコンストラクタ (使用禁止)
    DomNodeFromId(DomNodeFromId const&) = delete;
    /// コピー代入演算子 (使用禁止)
    DomNodeFromId & operator=(DomNodeFromId const&) = delete;
    /// ムーブコンストラクタ (使用禁止)
    DomNodeFromId(DomNodeFromId &&) = delete;
    /// ムーブ代入演算子 (使用禁止)
    DomNodeFromId & operator=(DomNodeFromId &&) = delete;

public:
    /**
        @brief  デフォルトコンストラクタ  
    */
    DomNodeFromId()
    {
        //TODO: デフォルト生成を行う処理の詳細をここに記述
    }
    /**
        @brief  デストラクタ  
    */
    ~DomNodeFromId() = default;
};

}   //namespace hoge

#endif  //HOGE_DOM_NODE_FROM_ID_H

見ての通り、 -n オプションと併用すると Boost.noncopyable を使用する代わりに、コピーやらムーブやらのあれこれを = delete しまくるコードが挿入されます。それから、デフォルトコンストラクタのプレースホルダはクラス定義内に確保され、デストラクタは = default で定義されます。

この他、 -CM オプションあたりが併用可能となっていますが、抽象クラスになるようなオプション (-vie) や、 Pimpl モード (-p) との併用はできません。

• C++ APIデザイン
  

今回から第4章に入ります。4章は C++ での実装の話はなく、設計に入るまでの情報の収集や整理 (要するに要件分析)、および様々なレイヤーでの設計に関する議論となっています。プログラミング実習をするような内容でもないので、要点をまとめながら解釈したり考えたりしたことをレポートしたいと思います。

今回はその中でも、 4.1～4.3節の、要件分析までの内容について見ていきます。

大原則

最初のセクションに入る前の書き出しで、以下のように書かれています。これはもう、大原則ですよね… (強調は拙引用者によるものです)。

…こうしたさまざまな分析テクニックは個別に使っても組み合わせて使っても有用である。とはいえ、「自分で理解できないことは設計できない」という原則を常に頭に入れて設計してもらいたい。

このことは、この後に説明されるさまざまな場面において重要な事柄です。システムの構成をうまく分解・整理できない、クラスや関数に適切な名前を付けられない、などといったことは、当該事項に対する理解が不足している証拠であり、そのために情報の収集や議論を重ね、要件を整理するということの繰り返しが必要不可欠になるわけなんですね。(あーしんどい)

優れた設計の必要性

4.1節では、優れた設計がなぜ必要なのかを、怖い話を交えて説いています。

…ちょっとだけ愚痴を (強調は拙引用者による)。

この問題にはもう1つの側面がある。コードの品質を高く保っていかないと、コードの進展とともに当初の設計がしだいに退化していくことだ。デッドラインに間に合わせるための手抜きは、後で戻って修正する限り許される。とにかく、自分の技術的な負債は必ず後で支払わされることを肝に銘じることだ。コードというものは、当初開発者が思ったより長く存続するものだ。APIを弱体化するときはこの事実を思い出して欲しい。このつけを長期的にサポートするはめになるのは本人だ。だからこそ、API設計に対する新規要件のインパクトをしっかりと把握し、(…以下略)

…このツケを踏み倒していく技術者のなんと多いことか＿|￣|…………◎ (←お前が言うな)

機能要件の収集

4.2節は機能要件について書かれています。まず、ソフトウェア業界における要件の種類を以下の 3つに整理しています (強調は原文ママ)。

• ビジネス要件: 事業という意味でのソフトウェアの価値。会社のニーズにどう応えられるか。
• 機能要件: ソフトウェアの動作や振る舞い。ソフトウェアが遂行すべき内容。
• 非機能要件: ソフトウェアが達成すべき質的水準。ユーザにとってうまく機能する度合い。

そのうえで、 API 開発に際して、上記のうちの機能要件、および (ついでに) 非機能要件について、 API のターゲットユーザーや専門家などからどういった要点で質問し、情報を引き出すべきか、そしてそれらについてどのように整理してまとめ、保守してゆくべきかが説かれています。

ちょっとショッキングな (だけど実感として納得できてしまう) 記述を以下に引用します…。

平均すると、あるプロジェクトで開発期間中に変更する機能要件は 25% あり、そのために書き換えるコードは 70～85% に上るという[52]。クライアントの変化するニーズをしっかり受け止めることは大事なことだが、要件の変更に伴うコストを関係者全員に理解させることも重要である。(…以下略)

(参考文献)
[52] S. McConnell, Code Complete: A Practical Handbook of Software Construction, second ed., Microsoft Press, 2004. ISBN 0735619670. (『Code Complete 第2版〈上〉〈下〉— 完全なプログラミングを目指して』、スティーブ・マコネル著、クイープ訳、日経BPソフトプレス、2005年)

…この場合、書き換えが発生すると予想できる分だけ余裕を持って見積もるべきなのか、要件の管理を徹底した上で、要件の変更が発生する度に追加の見積もりを計上すべきなのか、どっちなんでしょうかね…。アジャイルなやり方を採用している現場ならもう少し融通も利くのでしょうが、そもそもエンドが動かせないプロジェクトの場合、開発側代表者 (多くの場合、PM?) の交渉手腕、企業の人的リソース配分なども意味を持ってくることに… (考えたくない)

# マコネル読め>ヲレ

ユースケースの作成

ユースケース実践ガイド — 効果的なユースケースの書き方
(OOP Foundations)

4.3節はユースケースについて書かれています。ユースケースの様式 (フォーマットであったり、 UML であったり) よりも、概念や存在意義を始め、書くべき内容やボリューム感、粒度、使うべき言葉、それから向き合い方や取り扱いなどといった実践的な部分について書かれています。

4章で書かれていること全般的に言えることですが、ユースケースについてもあくまで概要レベルで触れられています。ここに書いてあることを読んだだけでも割といい感じで書けそうですが (それだけ要点よくまとまっています)、より深く学びたい人はアリスター・コーバーン著「ユースケース実践ガイド」がお勧めです。

それから、関連する事柄として、 4.3.4 でアジャイル開発での要件の取り扱いとユーザーストーリーについて論じられています。ユーザーストーリーについては以下の部分の引用が端的で分かりやすいのではないでしょうか。

(…前略)マイク・コーンはユーザーストーリーについてシンプルな形式を提案している[19]。

私は、 [役割] として [利点] のために [目的物] がほしい。

(参考文献)
[19] M.Cohn, User Stories Applied: For Agile Software Development, Addison-Wesley Professional, 2004. ISBN 0321205685.

私は、プログラマーとして Unicode を内部表現として安全に取り扱える C++ コンパイラと正規表現ライブラリが欲しいです…。

膨大な量の正式な要件文書を維持管理することは迅速《アジャイル》ではない

要件分析について述べられた内容は以上で終わりです。結局本書では、要件を分析する方法論として、機能要件の収集、ユースケース、ユーザーストーリーの 3種類しか挙げていません。しかも、必ずしもそれらをすべて揃えろという話ではなく、プロジェクトの性質に応じて、ユースケースのみを作成する、ユースケースから機能要件を引き出す (もしくはその逆)、ユースケースよりも迅速かつ簡潔な方法としてユーザーストーリーを用いる、などの選択肢がありうることを示唆しています。

要件定義の文書に盛り込むべき内容としてはさまざまなものが要求されることが多いです。入出力要求であるとか、業務フローであるとか…。そして、割と多くの企業や現場で、主に Excel や Excel、それから Excel などを使ってきっちりとした体裁の文書を作成し (悪意が滲み出てるって? きっと気のせいですよ…)、用語の解釈に誤りがないかとか、誤字・脱字はないかとかいったことで延々とレビューを繰り返すという光景が繰り広げられているのではないでしょうか。

もちろん、要件として残すべき資料がこの程度しか考えられないのは開発対象があくまで C++ で実装するような API の開発であり、それは開発者が使うためにリリースされるものであるからそんなもんで充分なんだろうという考え方もできると思います。なにはともあれ、振る舞い要求を分析する方法であるユースケースの説明を行う節の最後にアジャイル手法とユーザーストーリーの説明を交えてくる点も含めて、著者であるマーティン・レディが要件分析に対してどちらを志向しているのかが垣間見れるようにも思えます…。

当然のことながら、ウォーターフォールモデルを悪しき風習であると断じるつもりは (少なくとも私には) 毛頭ありません。それよりは、どんな手法や枠組みを用いるにせよ、形式に従うこと自体を目的にして費やされるコストに、もう少し懐疑的であっても良いのではないか、ということなのだと思います。箇条書きで済む内容だったら Wiki を使うんだっていいわけですし、図だって手書きのものをスキャンしたものを共有とかでもいいわけですし、履歴管理を重視したいなら図も GraphViz で書くという手だってあるわけですし、納品物という形を得たいなら印刷しなくても CD に焼いて納品という手だってあるわけですし…。

最後もなんだか愚痴っぽくなっちゃいましたね (^_^;。次回は 4.4節以降、設計の部分についてレポートする予定です。それではまた…。

• C++ APIデザイン
  

さて、API のラッピングパターンについてはざっと読むだけで終了とし、今回は Observer パターンについてさらってみました。

MVC っぽいことをやってみたい。

本書では、オブザーバーパターンの説明に入る前に、 MVC アーキテクチャについての説明がありました。

シンプルなアプリケーションでは、コントローラはユーザ入力に基づいてモデルへの変更に影響を与え、こうした変更をビューに通信して、UIを更新できるようにする。しかし、実際のアプリケーションでは、通常、水面下のモデルへの追加変更を反映するために、ビューも更新する必要がある。(…中略…)とはいえ、先ほど述べたように、モデルコードはビューコードを静的にバインディングして呼び出すことはできない。そこでオブザーバーが必要になるのだ。

なるほどなるほど。とまぁ、こんな説明の後に Observer パターンの実装例とその説明に入っていくのを見せられたら、そりゃあまぁ、 MVC っぽいことをやってみたい、って普通思いますよね…??

ただ、上記にあるようにモデルがビューを監視できるようにする必要があるという話であるにもかかわらず、多くの MVC フレームワーク実装を見るに、ビューからのメッセージを受け取って何らかの制御を行うコードは通常コントローラに書かれているように見えます。現実的には、ビジネスロジックはフレームワークを差し替えても流用可能であることが望ましく、オブザーバーにするための抽象クラスの継承でさえ避けたいというのが実情なのではないかと思います。

そこで、コントローラをビューに対するオブザーバーとする設計とし、ビューが提供するいくつかのメッセージに対して、メッセージハンドラのような感じでコントローラを登録し、実装できるようにする、という考え方でやってみることにしました。ビューはよく使いそうなパターンのものを幾つか用意しておけば、あとは必要に応じてたまーに新しいものを追加する程度の変更で事足りるでしょうが、コントローラは新しい機能を追加するたびに必ず実装を追加することになります。テキスト p.120 の図にも示されている通り、ビューはコントローラの実装を知らないほうが良いのです。モデルはコントローラが掴んで (もしくは生成して)、ビューから呼び出されるハンドラメソッド内で操作するようにすればよいでしょう。

コンソール画面で動くものを作ってみる。

MVC アーキテクチャっぽいものを、といっても、具体的に何を作ろうか、というのは悩みどころです。 GUI のものを作るにしても、 Web アプリケーションを作るにしても、結構大掛かりなシステムになってしまうのではないかという不安があります。お試しで作るんですから、簡単なものがいいんですよね…。

というわけで、コンソール画面で動くものを作ることにしよう、ということでプログラムを書いてみることにしました。それも内容的にもごく簡単なものをということで、お題はズバリ、時計です。コンソール画面の真ん中らへんで、現在時刻を表示し続けるというだけの、ごくごく簡単なプログラムです。

作ってみた。

そんなわけで、作ってみました。ソースコードは以下の場所にて公開しています。

• samples-for-blog/c++/api-design-for-c++/ch03-pattern/observer at master · murachi/samples-for-blog

このプログラムは std::thread を使ったマルチスレッドプログラムなので、 gcc でコンパイルするときは以下のように、必ず -pthread オプションを付けてあげて下さい。

$ g++ -std=c++11 -pthread -o watch *.cpp
$ ./watch

プログラムを実行すると、コンソール画面がクリアーされて、画面の真ん中らへんに現在日時がリアルタイムで表示されます。また、画面の下の方に「Hit any key to finish.」と表示されるとおり、なにか適当なキーを押すとプログラムは終了します。


なお、動作確認は以下の環境にて行いました。

• Ubuntu Linux 14.04 LTS x86_64/GCC 4.8.2/bash 4.3.11/kernel 3.13.0
• Windows7 Professional SP1 x86_64/Mingw_w64 GCC 4.8.2 (powerd by Win-builds)/コマンドプロンプト

プログラムの解説など。

モデル

日時の保持と現在日時への更新、といった辺りをビジネスロジックとして実装しています。 datetime.h と datetime.cpp がそれです。

ここはまぁ、日時の取り扱いに Boost.DateTime を使っているという点以外は特筆すべき点も無いんじゃないかと思います。

ビュー

コンソール上で動作するビュー全般、ということで console-view.h と console-view.cpp 、より具体的に静的に文字列を表示するだけのビューということで static-text.h と static-text.cpp を、そしてキー入力を待ち受けるためのビューとして key-listener.h と keylistener.cpp を実装しました。また、ビューはオブザーバーを登録して通知を投げるサブジェクトとして実装しています (subject.h 、 subject.cpp)。

class SubjectBase : private boost::noncopyable {
    // ...
};

class ConsoleView : public SubjectBase {
    // ...
};

class StaticText : public ConsoleView {
    // ...
};

class KeyListener : public ConsoleView {
    // ...
};

SubjectBase クラスについては、これはもう概ね教科書どおりの実装です。 subscribe() メソッドにてメッセージ ID を指定しつつ observer を登録し、何らかのイベントに応じて、そのイベントに対応するメッセージ ID に指定登録されたすべてのオブザーバーに通知を投げる、ということができる仕組みになっています。派生クラスは自身の notifyObserver() メソッドを呼べば、 observer として登録されているコントローラを呼び出すことができるというわけです。

なお、オブザーバーの登録・削除はスレッドセーフになるよう、 Mutex を使ってロックをかけています。オブザーバーへの通知の際にもロックをかけていますが、通知対象となるオブザーバーの配列をコピーするまででロックを解除し、コピーを見て通知を行うようにしています (通知の実行までロックした状態でやるとデッドロックを起こすことがあったので…^^;)。

ConsoleView クラスはコンソール上で動作するビューとしての一通りの機能を持つクラス… であるべきなのですが、考えられるすべての機能を盛り込みまくる動機付けもなかったので、とりあえず以下の機能だけ実装しました。

• 以下のステータスの保持と、それに基づく表示
  • 表示文字列
  • 表示位置 (コンソール座標)
  • 色番号 (0～7)
• 上記のステータスを変更すると、それに応じて表示を更新する
• タイマー、およびインターバルタイマー
• コンソール画面のサイズの取得

ステータスの変更は setStatus() メソッドにて行います。ステータスを変更すると即座に表示に反映される、ようにしたかったのですが、例えばテキストも表示位置も色も変更するよ、という場合に、それぞれの値を個別に受け取るようにメソッドを分けてしまうと、一度の変更で再描画が最大 3回も走ってしまう、というのでは激しくダサいなと思ったので、現在のステータスを構造体として受け取って、その内容を書き換えるコールバック関数を受け取るようにしてあります。このコールバック関数は std::function として受け取るようにしてあるので、キャプチャ付きのラムダを指定することも可能です (こちらの記事でやろうとしていたやつですね^^;)。

タイマーとインターバルタイマーは、それぞれ setTimer() と setInterval() 各メソッドを呼ぶことで発動します。どちらも指定した時間が来ると vm_Timer メッセージの通知を observer に投げます。インターバルタイマーの方はこれを stopInterval() を呼ぶまで何度でも繰り返します。今回のプログラムではインターバルタイマーの方だけ使っています。

StaticText クラスはコンソール上の固定の位置に、指定した色で指定したテキストをただ表示するだけのビューとして実装しました。 changeText() メソッドを使うことで、表示するテキストの内容だけ変更することができるようになっています。もっとも、ConsoleView::setStatus() メソッドが public なので、やろうと思えば表示位置や色も変更できてしまうのですが…。

KeyListener クラスは、キー入力を待ち受けし、入力値を取得することができる入力用のビューです。あまりコメントを尽くしていないのでわかりにくいのですが、 initialize() メソッドをオーバーライドしており、オブザーバーに初期化メッセージを投げる前に、この中でキー待受を行うスレッドを生成します。このスレッドがキーの入力を取得すると、今度はオブザーバーにそのことを伝えるメッセージを投げ、オブザーバー側で getKeyChar() メソッドを呼んで入力値を得ることができるようになっています。

コンソールマネージャ

コンソール制御は複数存在しうるビューとは切り離して実装する必要があると判断し、コンソールマネージャとして別途実装しています (console-manager.h 、 console-manager.cpp)。内容的にはシングルトンにしたいところなのですが、今回はビューに対して依存性を注入することを前提とした設計ということにしてみました (main() 関数の中で 1つだけインスタンスを生成するイメージ)。

実際に実装した機能は以下のとおりです。

• インスタンス生成時に画面をクリアする。
• インスタンス破棄時にカーソルの現在の文字の色を元に戻す (Windows では白で決め打ちにしちゃってます…)。
• コンソール画面のサイズの取得 (getSize())。
• 指定したカーソル位置及び色でコンソールに文字列を出力する (output())。
• エコーバックせずにキー入力を受け付ける (waitKeyInput())。

ConsoleView クラスやその派生クラスが提供する機能の具体的な実装は全てここにあります。

最後の waitKeyInput() は、要するに DOS の getch() 関数です (実際、 Windows では _getch() 関数を呼んでいます)。当然ブロックします (なので、 KeyListener クラスはスレッドを咬ましてこいつを呼びに行っています)。

コントローラ

時計のリアルタイム表示処理を行うコントローラとして watch-controller.h と watch-controller.cpp 、キーが入力されるまでプログラムを実行させ続けるためのコントローラとして wait-controller.h と wait-controller.cpp を実装しました。これらはサブジェクトであるビューから通知を受け取るオブザーバーとして実装しています (observer.h)。

class ObserverBase : private boost::noncopyable {
public:
    virtual ~ObserverBase() = default;
    virtual void notify(int message) = 0;
};

class WatchController : public ObserverBase {
    // ...
};

class WaitController : public ObserverBase {
    // ...
};

ObserverBase クラスも SubjectBase クラスと同様、教科書通りの実装となっております。通知を受け取る純粋仮想関数 notify() があるだけの簡単なインタフェースです。

WatchController クラスは時計のリアルタイム表示処理を行います。コンストラクタに StaticText インスタンスの参照を受け取り、コンストラクタの中で初期化メッセージとインターバルタイマメッセージ用に自身を登録します。で、初期化メッセージを受け取ったタイミングで StaticText のインターバルタイマ (これは ConsoleView から継承されている機能ですね) を開始し、インターバルタイマメッセージを受け取ったタイミングで、自身がメンバに持つ DateTime オブジェクトの現在時刻更新を行いつつ、 StaticText の表示に反映させる、という仕組みです。

WaitController クラスはキー入力を受け取るまでひたすら待ち続けるという処理を行います。 WatchController だけだと、 インスタンスを生成したはいいけど main 関数が処理から抜けてしまってプログラムがあっという間に終わっちゃうという物悲しい現象が起こってしまうので、何もしないでただ待つだけのスレッドを用意してそれに同期 (join) することで main 関数から抜けないようにして上げる必要があり、その役目を果たすのがこのクラスというわけです。

作りは WatchController に割と似通っていまして、まずコンストラクタに KeyListener インスタンスの参照を受け取り、コンストラクタの中で初期化メッセージとキー入力メッセージ用に自身を登録します。で、初期化メッセージを受け取ったタイミングでコンソールに「Hit any key to finish.」などと表示しつつ、フラグが立つまでひたすら待ち続けるだけのスレッドを作って join します (このため、 KeyListener::initialize() メソッドの呼び出し元がブロックされる)。その直前に KeyListener が生成していたキー入力待ち受けスレッドがキー入力を受け付け、そのメッセージをこのコントローラに投げると、そこで先ほど処理をブロックするためだけに作ったスレッドを終了させるフラグを立て、めでたくブロックされていた処理が開通する、という仕組みです。

両方のコントローラで共通する話なのですが、ビューへのオブザーバー登録はどちらもオブザーバーであるコントローラのコンストラクタの中で行っています。 WatchController での記述を以下に示しますが、

WatchController::WatchController(StaticText & text_view)
    : impl{new WatchController::Impl{text_view}}
{
    text_view.subscribe(ConsoleView::vm_Init,
        std::shared_ptr<ObserverBase>{this, [](ObserverBase *){}});
    text_view.subscribe(ConsoleView::vm_Timer,
        std::shared_ptr<ObserverBase>{this, [](ObserverBase *){}});
}

std::shared_ptr のコンストラクタの第2引数に何もしないラムダを渡すというなんだか気持ちの悪いことをやっていますよね。何でこんなことをやっているのか。サブジェクト側ではオブザーバーインスタンスを shared_ptr でメモリー管理していますが、これはサブジェクトがどのように生成されるかわからないという前提では妥当な設計だと思うのですが、その一方で実際に登録を行うときに、これをオブザーバーのコンストラクタの中でやってしまおう、そうした方がなんだかスマートに書けそうだという場合に、 this ポインタをそのまま shared_ptr に包んでしまうのは非常に危険です。なぜならそのオブザーバーインスタンスはどのように生成されるかわからないし、生成した側がどのような形で管理するかもわからないので、例えばスタック変数として生成した場合や、生成した側でも unique_ptr や shared_ptr に包んで適切に破棄しようとしていた場合には、どちらかの破棄のタイミングで例外が送出される (おそらくは、アプリケーションエラーになる) ことになってしまいます。そうならないように、何もしない deleter を shared_ptr に渡し、 delete が呼ばれるのを防いでいるわけです。メモリーの管理責任の所在については色々と議論もあるでしょうが、私はインスタンスの生成を行った側が、そのインスタンスの破棄についても責任をもつべきだと考えています。

main関数

main関数はわかりやすいように main.cpp ファイルに記述しました。まず ConsoleManager インスタンスを生成し、次に日時の表示を行うビュー StaticText とコントローラ WatchController を生成して、ビューの initialize() メソッドを呼ぶ。同様にキー入力待受を行うビュー KeyListener とコントローラ WaitController を生成して、同じくビューの initialize() メソッドを呼ぶ。ただこれだけです。これだけで何でよしなに動いてくれるのか、といった辺りは、ここまでで色々と説明したとおりです… (分かんないかなぁ^^;)。

作ってみた感想など

前回 Pimpl をさらった時に、テキストに示されていた以外にプラットフォーム依存のコードを各状況というのがなかなか思いつかなくて try 出来なかったのですが、今回 ConsoleManager という形で #ifdef 書きまくることが出来たのはちょっと幸運でした。こういうのは自分で書いてみないと、他人が書いたコードを読むだけではなんだかビビってしまうばかりなので… プラットフォームごとに違うことをやるようなコードを書いて、どっちのプラットフォームでも動くのを確認するのはなかなか爽快ですよ。

KeyListener みたいな仕組みは、本当はビューではなく全く別の枠組みで用意すべきだったのかもしれません。 Windows のメッセージループみたいに書けるのが本当は理想的… なのかなぁ?? (よくわからん)

Windows の方は実際一応動くのですが、キー入力時に時々よく分からんエラーを吐いて終わることがあります (2014/8/6 時点)。何かがツメが甘いのかも…。

より MVC フレームワークチックにやりたいということであれば、他にも色々と改良の余地はあるんじゃないかと思います。埋め込みリソースからビューを生成とか…。

こちらからは以上です。

• STL のコンテナ (std::vector とか) には基本的にオブジェクトへの参照を掴ませることはできない (領域確保の効率の問題とかでデフォルトコンストラクタが必須だから)。
• かといって、ナマポを掴ませるのは色々と危険 (意図せず寿命が切れて無効なポインタ掴まされた状態になったりとか)。
• そも non-copyable なオブジェクトを扱いたかったりと言った理由で値そのものを掴ませるのは却下したい (まぁ、いろいろあるんだよ…)。
• となると std::shared_ptr を噛ますのが順当かと思いきや…
• 必ずしもヒープに確保した (つまり、 new した) インスタンスだけを扱うとは限らないかもしれない。十分に寿命が長いことがわかっている自動変数やメンバ変数として確保したインスタンスのポインタをこのコンテナに突っ込んであげたい場合もあるかもしれない。
• そういう場合に std::shared_ptr 使っちゃって大丈夫なのか…??

Deleter を指定してあげれば大丈夫

• 今回のサンプルコード

std::shared_ptr の Deleter って、 Win32 の HANDLE みたいに delete 以外の方法で開放するリソースを扱う方法として紹介されることが多いと思うんだけど、単純に、リソース開放の責任はここにはないよ、ということを明示する方法としてももちろん使えるよという、ただそれだけの話なんですね。

#include <memory>
#include <vector>
#include <iostream>

class Hoge {
    int number;
public:
    explicit Hoge(int num) : number{num}
    { std::cout << "Hoge " << number << " constructed." << std::endl; }
    ~Hoge() { std::cout << "Hoge " << number << " destructed." << std::endl; }
};

int main()
{
    std::vector<std::shared_ptr<Hoge>> hogehoge;
    hogehoge.push_back(std::shared_ptr<Hoge>{new Hoge(1)});    // まぁ普通…
    Hoge fuga{2};
    hogehoge.push_back(std::shared_ptr<Hoge>{&fuga, [](Hoge *){}});    // を、行けるやん!!
    Hoge piyo{3};
    hogehoge.push_back(std::shared_ptr<Hoge>{&piyo});    //(アカン)

    return 0;
}

実行結果:

murachi@erueru:~/github/samples-for-blog/c++/minimal-cases/shared-pointer-deleter$ g++ -std=c++11 -o hoge hoge.cpp
murachi@erueru:~/github/samples-for-blog/c++/minimal-cases/shared-pointer-deleter$ ./hoge
Hoge 1 constructed.
Hoge 2 constructed.
Hoge 3 constructed.
Hoge 3 destructed.
Hoge 2 destructed.
Hoge 1 destructed.
Hoge 3 destructed.
*** Error in `./hoge': double free or corruption (out): 0x00007fff8a6192a0 ***
中止 (コアダンプ)
murachi@erueru:~/github/samples-for-blog/c++/minimal-cases/shared-pointer-deleter$ 

何もしない Deleter を指定しなかった場合、 std::vector が開放される際に std::shared_ptr が delete を呼ぼうとするんだけど、出自が自動変数だった当該インスタンスはスコープ抜けるときに vector より先に破棄されちゃっていたので、結果コアダンプしてしまうわけですが、 Deleter を指定してあげた方は std::vector 開放時には何もしないので、結果開放処理が重複することなく済むわけです。 Deleter が lambda で書けちゃうのもいいですね。

ただ、この方法は std::shared_ptr でメモリー管理する領域よりも、生成元での寿命のほうが確実に長いことがわかっている場合以外は使えません。そういう意味では、プログラマーがメモリーの管理責任から開放されるための仕組みとして std::shared_ptr やガーベジコレクションのようなものを採用していることとは矛盾するやり方だと言えるでしょう。基本的には、 std::shared_ptr で扱うべきものは、プログラム全体で std::shared_ptr を介してのみ扱うよう徹底するのが正しいやり方なのかもしれません。