（……なんかなー、スプリンクラーみたいな感じに出せたらいいのになぁー）

　ユキはふと、前世にあった散水機（スプリンクラー）のことを思い出す。

　装置を中心に３～４方向に対して、回転するように水を撒くものだ。

（スプリンクラーって、なんかついついぼーっと眺めちゃうんだよなー。でも……あれを真似するためには……今、知ってるパラメータだけじゃできない）

　スプリンクラーの水の動きを真似するには、ユキが今、解読できている初期値設定だけでは、実現できない点があった。

　それは〝複数同時発射〟である。

　スプリンクラーは３～４方向に対して、同時に水を放出している。

　だが、現在、ユキが解読できている範囲では、弾は等間隔で１つずつ出すような仕組みになっており、複数同時発射はできなかった。

（うーむ……ちょっと骨が折れるけど……少し、解析してみるか……）

　ユキは意を決して、魔法論理（マジック・ロジック）の解析に着手した。

（今までは初期設定や更新処理の部分しか解析できなかったけど、きっと今ならもっと詳細を解析できるんじゃないかな……）

　ユキの解析能力も初期に比べると、成長していた。

　実際、冷蔵庫の開発過程においては実行（エグゼ）宣言なしでの自動走行を成功させるなど、それまではできなかった……いや、できないと思っていたことも成し遂げられたのだ。

（少し気合入れてやるか……）

　まず、ユキはこの初期化処理の大元となっている要素がないかを探してみることにした。

（恐らく……今まで解析してきたパラメータも何かしらの〝クラス〟の中のパラメータなんじゃないかな……）

　ユキはプログラミングにおいて、かなり重要な要素である〝クラス〟という概念の存在が魔法論理（マジック・ロジック）にも実装されていることは、ほぼほぼ確信していた。

　クラスとは、ものすごく簡単に言うと、そのモノが所持している〝要素〟と〝処理（メソッドと呼ばれる）〟をひとまとめにできる便利な仕組みである。

　例えば、このようなイメージだ。

　////////////////////////////////////////////

　class Device{

　// 要素の定義

　position // 位置

　angle // 角度

　count // カウンター

　temperature // 温度

　// 処理（メソッド）の定義

　// カウンターの初期化処理（メソッド）

　init_count(){

　　count = 0 // カウンターを0で初期化する

　}

　}

　////////////////////////////////////////////

　この例では、

　デバイス(Device)というモノが

　位置(position )や角度(angle)などの要素を持ち

　カウンターの初期化処理(init_count)をすることができる

　といった具合である。

　このクラス(class)という仕組みがあることを前提に考えると、

　ユキは、ある一つの仮説を立てることができた。

　それは、今まで、ユキが変更していた魔法論理（マジック・ロジック）が、特定のクラスの処理（メソッド）の一部なのではないか？　ということである。

　確信はない……だが、きっとそうであると信じたならば、ユキにできることは集中して魔法論理（マジック・ロジック）を感じ取ることだけだ。　

　もし、それを突き止めることができれば、設定の変更だけでなく、処理そのものの追加も可能となり、より自由度の高い改変が可能になるのだ。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

【あとがき】

クラスの概念は全くプログラミングをしたことがない方からすると、少しややっこしいですが、プログラミングにおいて、もっとも基礎的な考え方かもしれないです。

（最近のプログラミングはモノを主体に設計するオブジェクト指向という考え方が主流です）