一方ＰＨＰは、Zendが、Flex／AIRと連携なのね・・・

前に、「C/C++でFlashアプリが開発できるAdobe Alchemy」ってまじ！。。。ってことで、ＣとＣ＋＋の話を書いたんだけど、ＰＨＰは、

Zend、AdobeのFlex／AIRと連携可能な「Zend Framework 1.7」をリリース
http://sourceforge.jp/magazine/08/11/21/0224200
ということで、Flex／AIRと連携なのね・・・

形式的な共通化により、意味が見えなくなる場合の対応

さっきの形式的な共通化と意味的な共通化の話。まとめると、

業務に結びついている部分を共通化する場合（自衛隊と一般公務員の給与計算の共通化など）を
　　意味的な共通化と、ここではよぶ。
　　これは、アルゴリズムを共通化しているようなものである。

業務とは関係ない、計算システムへの落とし込みを共通化する場合（画面はStrutsでなど）を
　　形式的な共通化と、ここでは呼ぶ。
　　これは、アルゴリズムの実装を共通化しているようなものである。

---

　で、ここで、形式的な共通化を利用する場合（フレームワークなどもそう）、意味部分を考えないため、意味部分の情報を捨象して、共通化を行う。

　具体的には、Strutsの画面などで、各画面、それぞれ違いがあるけど、これを共通的にしないといけないので、ActionFormという中に入れている。
　ＶＯ（バリューオブジェクト）、カオル姫方式のハッシュマップに値をいれるのや、XMLで引数をわたすのや、ＨＴＴＰの引数としてのＵＲＬエンコーディングや、InterStageのCBMMsgとか・・・挙げるとキリがないので、この辺でやめるけど、引数をなにかにいれるのが、これになる。

　プロセスのほうもそうで、Strutsの場合もActionに入れたりするけど、こちらのほうは、Javaだとリフレクションを使えばいいし、Cだと、関数をポインタにいれて、そいつを起動するなどできるので、引数のようにあえて共通化する変数・クラスとかは作らないけど、おんなじように、意味部分（給与計算とか受注とか）を捨象して、共通化する。

　これにより、画面やＤＢなど、実装部分は、形式的に操作できる。

---

　この結果、形式的な共通化により、意味が見えなくなることになる。
　引数をハッシュマップで渡してしまうと、引数の値は、わからない。
　共通のＶＯクラスを継承したものを引数とする場合、わたってきたクラスは、（ＶＯを継承していることは分かるけど）実際に、どのクラスで、変数（フィールド）は何なのか、はわからない

　この場合は、共通の形式→意味変換が必要になる。

　具体的に言うと、

public void exec(HashMap arg)


と共通化され、引数がハッシュマップに入っていて、その属性と値が知りたいのなら


String[] argKeyList = (String[])(arg.keySet().toString(new String[0]));

でハッシュマップのキーを取得。あとは、arg.get(argKeyList[i]);

みたいな感じで、それぞれの値を得る。


引数が、あるクラスに入っている場合、Ｊａｖａなら、かならず、Objectは継承しているはずなので、

　arg.getClass()で、クラスを取得でき、クラスのgetName()で、クラス名、
　クラスのgetField()でフィールドを取得し、そのフィールドに対して、getName()で、フィールド名

みたいな感じで、それぞれの値を得る。

---

　こういった、共通手続きで、意味的情報が取得できることはありがたいが、これらの情報は、動かしてみないと入手できないこともある。なので、共通化するときは、このような機能の有無にかかわらず、ドキュメントを残しておく必要がある（けど、ドキュメントも共通化すれば、もっと効率が上がるのよね）

形式的な共通化と意味的な共通化

　あるプログラムやシステムを共通化すると言った場合、形式的な共通化と意味的な共通化がある。

　たとえば、給与計算を共通化するといったとき、
　　　　自衛隊の給与計算も、外務省の給与計算も、人事院の給与計算も共通化するというのは、
　　　　　　　　　意味的な共通化といえる
　　　　→つまり、業務に結びついている

　一方
　　　　画面はStruts,ＤＢアクセスはHibernateでＯＲマッピング、
　　　　その他設定ファイルはＸＭＬでＤｏｍ読み込み
　　　　　　っていうのは、形式的な共通化といえる
　　　　→つまり、業務に直接結びついていない

業務に結びついている部分の共通化は、そもそも、業務が共通化できるかどうかが必要である。
なぜなら、コンピューターシステムは、業務を計算モデルでシミュレートしているにすぎないわけで、
業務的には、不可能だけど、コンピューターで適当にやってよ！といっても、どう計算モデル
（＝アルゴリズム→プログラム）をつくればよいのか。。。（＾＾；）

　一方、形式的なものは、業務にかかわらず、統一しやすい。
　画面の内容（＝業務）にはかかわらず、表示方法、入力方法（アルゴリズムの実装）にかかわっているからだ。

---

　つまり、もっとはっきり言ってしまうと、

　意味的な共通化＝アルゴリズム自体の共通化
　形式的な共通化＝アルゴリズムの計算システムへの帰着（実装）レベルでの共通化

　といえる。アルゴリズム自体は万能性があるように作るのだから、そのうち、ある言語に帰着させる形式的な共通化は、ある意味、出来て当たり前といえるかもしれない。それに対して、アルゴリズムを共通化させるというのは、本質的に、そのアルゴリズム（まあ、業務？）に共通部分がないと出来ない。
　そこで、この、共通部分の担保の取り方（＝共通部分であると、なぜ言い切れるのか？）が問題になる。

---

　ただし、形式的な共通化をしようとしたときに、意味的な共通化が入ってきてしまうときがある。
　その場合の問題などなどを、（このシリーズの？）次に書こうと思う。