Asp・PHP・Vb・Javascript・oracle・ mysqlなど、エンジニア必須技術の最新情報や、あなたの技術をより磨くためのお役立ち情報が満載です。

「ソフトウェアIC」という言葉が気になって、眠れなくなってしまった。

・・・

インターフェイスとは何ぞやということを考えていたら、あまりにも当たり前の現実に気が付いた。

それが「あなたの仕様は守っているけど、私の仕様は決めていない」

私の仕様を決めていないから、なかなかソフトウェアICが実現できないんじゃないか・・・。

・・・

例えば、スレッドクラスを作るためのRunnableインターフェイスを例にしてみる。Runnableを実装するクラスは、必ずrun()メソッドを定義することになる。これは「あなた（Thread）の仕様を守っている」ということです。

ここで、非同期にファイル監視するクラスAと非同期にソケット通信するクラスBがあったとき、クラスAとクラスBを取り替えたら動くだろうか・・・！？

動くわけないですな。

つまり、「私の仕様は決めていない」から片手落ちの手抜きのインターフェイスなんだろう。

・・・

じゃあ、ファイル監視するRunnableインターフェイスAとソケット通信するRunnableインターフェイスBの２つを定義したのちに、インターフェイスAを実装するクラスA1とクラスA2、インターフェイスBを実装するクラスB1とクラスB2があった場合ならどうよ。おそらくクラスA1とクラスA2は取り替えられるし、クラスB1とクラスB2も同様。

つまり、インターフェイスっていうのは、他に継承させているsuperインターフェイスは別として、末端のインターフェイスならばその実装クラスをどれに置き換えてもほぼ同じように動かないといけないんじゃないかな！？

・・・

ほとんど同じ例だけど、Servletの仕様を守っている１００個のServletがあったとしても、取替えができない。例えば、LoginServletとLogoutServletを取り替えたらどうなるか？　これはやっぱり手抜きなんだろうな。「あなたの仕様（Servlet）は守っているけど、私の仕様は決めていない」。

ILoginServletとILogoutServletのインターフェイスが別々に定義されていて、ILoginServletを実装するのがCSVLoginServletとなる。もしRDBにユーザマスタを持たせたいならRDBLoginServletで、XMLファイルに持たせたいならXMLLoginServletになる。

・・・

やっぱり私は、くどいけど「new ILoginServlet();」ってコーディングしたいですわ。

・・・

マザーボードにCPUソケットが付いていて、マザーボードのコーディングをしていたとする。そのときに３つの選択肢があるとする。

1. CPUSocket cpu = new IntelCPU();
2. CPUSocket cpu = new CPUSocket();
3. CPUSocket cpu = di.get("cpu");

１．はCPUソケットがあるのにインテルが直接半田付けされている感じ。
２．はCPUとCPUソケットを抽象的に扱っている感じ。
３．は外部にドライバがないとCPUソケットが使えない感じ（USBみたいな感じ）。

そういえばメソッドに安定しているか、安定していないか、って指定できればいいのに。

安定とは、同じパラメータを渡せば、同じ結果になるという意味です（正確には何と言うのか知らないけど、何となく意味は合っているでしょ？）。例えば、sin(x)やcos(x)は安定しているし、rand()やＤＢアクセスして結果を返すメソッドは安定していない。

・・・

実は安定しているメソッドは最適化できる。そもそもメソッドや関数は汎用的に作られている。数学関数（sinやcos)なんかは中がどうなっているか見たこともないが、とにかく正確な答えを返す。しかし、sinやcosに度数で｛０度、９０度、１８０度、２７０度｝しか使わないのなら、汎用的なロジックでなくても、この４パターンに特化したロジックでも良いわけです。
ここで、間違いなく汎用的なロジックより、特化したロジックの方が速い。

・・・

今までは人間がここを汎用ロジックで、ここを特化したロジックで、と判断していたわけなんだが、もうそろそろこの作業の半分くらいをコンピュータにやってもらおうか（笑）。つまり、あるクラスＡから、クラスＢ内の安定しているメソッドを呼び出したときに、パラメータが偏っているのならば、汎用的なロジックから自動生成した特化したロジックに切り替えてやったらどうよ。
一種のキャッシュみたいなもんだね。でも、キャッシュを人間が作りこむのではなく、ランタイムがキャッシュロジックを作りだして、メソッドのエントリポイントを変えてやる。雰囲気はJITコンパイラみたいな感じだけど、ソースファイルそのものを動的に作ってやる。

//元の人間が作ったソース
class A {
void func() {
int rc = B.calc(1);
}
}
class B {
@結果が安定しているマーク
static int calc(int x) {
return x*x;
}
}

//最適化したソース
class A {
void func() {
//REPLACE by runtime
//int rc = B.calc(1);
int rc = B_2.calc(1);
}
}
class B {
@結果が安定しているマーク
static int calc(int x) {
return x*x;
}
}
//GENERATE by runtime
class B_2 {
static int calc(int x) {
if (x==1) return 1;
else return B.calc(x);
}
}

運用していると、どんどんモジュールサイズが肥大化していきます（笑）。

・・・

でも、なんか同じ結果ならより速いロジックを自動選択していくみたいなことがDIで実現できればいいんだけどね。つまり、上の単純な値のキャッシュだけでなく、パラメータが０〜１００まではロジックA（クラスA)で、パラメータが１０１以上ならロジックBみたいな感じ。せっかくユニットテストを作るんだから、単純に○×だけでなく、速度の良し悪しもデータに残して、ランタイムがその成績みてロジックを選択してくれるみたいなことができてもいいな。