カプセル化:
パッチでどこまで行なうべきか?

複雑なパッチ

比較的複雑なプログラムを書くようになった場合、単独のパッチャーウィンドウの中に1つの巨大で入り組んだものを書くのではなく、様々なパーツからプログラムを組み立てるようにして下さい。そのためには、プログラムを異なったパッチャーファイルに分割することになります。異なったファイルを1つのメインパッチのサブパッチとして使用でき、メインパッチが開かれたときにそれらはすべてロードされます。

サブパッチはインレットとアウトレットを通じて、あるいは send および receive オブジェクトを経由してお互いに通信することができます。そして、アーギュメントとして同じ名前を持つ colltable、あるいは value オブジェクトを使うことによってデータを共有することができます。どのように大きく、複雑なパッチでも、多くの小さいパーツから作成できないということはありません。そして、この方法による利点は数多くあります。

モジュール化

プログラミングを行なう上で、モジュール化によるアプローチを採用することが好ましいというのには、いくつかの重要な理由があります。その1つは、モジュール化によってプログラムの実際の動作の検証が行ないやすくなるということです。これは、プログラムの動作が極端な場合や、一般的でない場合には特にあてはまります。動作の検証はプログラムのサイズが大きくなり、複雑になるほど、困難なものになります。小さなモジュールによってプログラムを構成し、モジュールそれ自体が要求される動作を行なっていることを確認しておくことによって、モジュールがより大きなコンテキストに組み込まれた場合に、考えられる問題点の数を減少させることができます。

第2の理由は、プログラムの多くのタスクは、他のコンテキストでも再利用できるということです。特定のタスクを実行する小さなモジュールを組み立てておけば、その同じタスクを実行する必要が生じた場合、その都度書き直すのではなく、そのモジュールを使用することができます。

また、別の理由として、プログラムの多くのタスクは他のタスクと同様なものが多いということがあげられます。小さく、汎用的なモジュール(多くの場合、アーギュメントを取り、そのアーギュメントによって的確に機能にバリエーションを持たせることができるようなもの)を書くことによって、1つのモジュールを様々な入力やアーギュメントに対して使用でき、同じような多くの処理を行なうことができます。

最後に、プログラムの様々な部分をカプセル化することは、プログラムの作成からしばらく時間がたった後で、自分自身(あるいは他者)が「そのプログラムがどのように動作するのか」を理解することを容易にしてくれます。

カプセル化

プログラムの個々のモジュールを1つのタスクにカプセル化することは最良の設計と言えます。モジュールの名前をその処理がわかるようなものにしておき、他のプログラムでそのタスクを再び実行したい場合には、ぜひそのモジュールを再利用して下さい。

特定の値を一カ所に置いておくことによって、その値を変更する必要があると判断した場合に、一度その変更を行なうだけで済みます。同じ値がプログラムの至る所に分散している場合、その値のすべてのインスタンスを見つけ出して、それらを個々に変更しなければなりません。

値を一カ所に置いておき、同時に多くの異なったオブジェクトで利用できるようにする方法の1つは、それらの値を、あらゆるパッチからアクセスできる1つのファイルに保存しておくことです。例えば、多くの異なったパッチで、同じファイル名をアーギュメントとして持つ table オブジェクトを使用することによって、同じテーブルファイルから値を読み込むことが可能になります。その1つのファイルの内容を変更すれば、ファイルを共有するすべてのパッチで使用される値が変更されます。

パッチ間のメッセージ

大きいプログラムと一体化して使用する小さなモジュール(パッチ)を設計する場合、そのパッチが「何をするか」ということだけでなく、「どのようなコンテキスト(文脈)で使用されるか」についても考慮しておくことが重要です。コンテキストは、それぞれのパッチがどのような種類のメッセージを作成し、受信するかによって決定します。例えば、処理のトリガに bang を使用したい場合、数値を使って何かのオンとオフのトグルスイッチを切り替えたい、あるいは演算のための値を提供したい場合、また、シンボル(start stop など)を使ってシーケンサのようなより複雑なタスクをコントロールしたい場合があるでしょう。パッチが送受信するメッセージがよりシンプルで、個々のパッチの機能がよりシンプルである場合、そのパッチを効果的に使用できると考えられるコンテキストの数は多くなります。

カプセル化とカプセル化の解除

オブジェクトのグループをサブパッチャーの中に置く方法によってカプセル化を行ない、作成しているパッチを整理することができます。

・サブパッチャーの中に置きたいオブジェクトを選択します。

・その後、Edit メニューから Encapsulate を選びます。

オブジェクトは、新しく作られたサブパッチャーに片付けられ、適切な inlet オブジェクトと outlet オブジェクトが追加されます。結果が思ったようなものでない場合、元に戻すことができます。

逆の操作も可能です。すべての経過を追うために2つのウィンドウを管理しようとする場合、サブパッチャー内で動作しないオブジェクトは時として厄介です。De-encapsulate(カプセル化の解除を行なう)機能によって、サブパッチャーの中にあるオブジェクトを、親パッチャーに戻すことができます。

・サブパッチャーを選択します。

・Edit メニューからDe-encapsulate を選びます。

サブパッチャーは消え、サブパッチャーの内容が、それまでの接続を維持したまま親パッチャーに置かれます。De-encapusulation(カプセル化の解除)も元に戻すことができます。

サブパッチのドキュメント化

独自のパッチをドキュメント化する(訳注:動作や内容がわかりやすいように説明を加える)ための3つのポイントを示します。これはサブパッチの場合にも適用できます。

  1. サブパッチに、それ自身の動作を示すような名前をつけておくと、個々のサブパッチが行なう処理が覚えやすくなります。

  2. inlet オブジェクトや outlet オブジェクトごとにアシスタンス用のテキスト(パッチャーのアシスタンスエリアに表示されるテキスト)を書いておくと、パッチを使う際に、インレットやアウトレットの使用目的がわかりやすくなります。

  3. サブパッチが複雑な場合、サブパッチの中に動作を説明するための comment ボックスを置いておくと良いでしょう。

参照

デバッグ パッチをデバッグするためのテクニック
効率化 プログラミングスタイルに関する問題