メモの処理は情報構造体のリファクタリング

断片的に書き留められたメモは、その後処理されることになる。

いわゆるinboxの処理である。

このような作業は、居場所が固定されていないふわふわとしたものを定位置に収める、というイメージが喚起されるかもしれない。

もちろんこのイメージは間違っていない。手順的に考えればジャストなイメージだろう。

しかし、意識的にはどうだろうか。「居場所が固定されていないふわふわとしたもの」が意識の中に発生するだろうか。むしろ、それは以下のようなものではないか。

var text1 = "完璧な広告"; var text2 = "人生コンサルタント"; var text3 = "意識は一つでカテゴリはない。が、いろいろ思いつく";

つまり、メインで宣言された変数である。どこのサブルーチン（function）にも属していない、そっけなく、グローバルに宣言された変数。それが、これらのメモではないか。そして、メモの処理とはこれらの変数を適切なサブルーチンやオブジェクトに格納し直すことではないか。

そう捉えれば、メモの処理とは、情報構造体のリファクタリングということになる。

二種類のメモ

このように捉えると、二つのことが見えてくる。

まずロディアのように一枚一枚切り取る形で取られるメモと、「一日ページ」のノートに捉えるメモの関係だ。

前者は、まさに個別に変数を宣言していることになり、後者はたとえば、

var 20180416 = { text1 = "完璧な広告", text2 = "人生コンサルタント", text3 = "意識は一つでカテゴリはない。が、いろいろ思いつく", }

のようにあらかじめ作成したその日のオブジェクトに変数を追加していくことになる。

とは言え、「その日のオブジェクト」はそれ自身が──日記以外の──機能を持たないので、適切な別の関数やオブジェクトに振り分けられることになる。よって、辿る手順は同じである。

もう一つ、見えてくることは、リファクタリングのパターンの一部だ。

同じ属性の変数がたくさんあったらどうするか。たいていは配列にするだろう。配列とは何か。リストである。つまり、それはメモをリストに放り込むことに相当する。

この考え方を敷衍すると、メモにも型（タイプ）があることがわかる。言い換えれば、メモという言い方はあまりにも包括的過ぎるのだ。

でもそれは、原初のメモとして話を始めたのだから仕方がない。これから少しずつ腑分けしていけばいい。

では、どのような型が考えられるだろうか。

まずリストだろう。一次のリニアな構造だ。これは箇条書きリストとして実世界では実装されている。

次にマップだ。なんと呼んでいいのかわからないのでとりあえずこう呼ぶが、縦と横、言い換えれば平面に情報を配置したものになる。マインドマップはまさにそれだ。

さらに、ノートがある。ノートには文章が書け、箇条書きもできる。さまざまなものを織り交ぜられるということで、一つのオブジェクトと捉えることもできる。プロジェクトノートなどは、この拡張だと捉えられるだろう。

現実世界を観察してみれば、他にもいろいろな型を見出すことができるだろう。が、ここでは深入りはしない。とりあえず、メモの処理を情報構造体の処理と捉える視点が確認できれば十分だ。

では、なぜこのような考え方が必要なのだろうか。メモとかノートなんて、見れば区別できるではないか。そう、アナログならばそうなのだ。

次回はこの話を続けよう。