オブジェクト指向は、ある技術を知らないと、デスマーチになるように出来ている？論理的に考えると？？

　オブジェクト指向の言語が、他の言語とわかれる決定的な違いは、カプセル化によるデータの隠蔽と、継承にあル戸思います。

　では、そもそも、オブジェクトは、なぜカプセル化できるのか？と考えると、そりゃーあなた、オブジェクトというのは、１つしか存在しない(一意に存在する）、その属性は、そのオブジェクトに閉じている（局所的に存在する）から・・

　・・・と、仮に答えてしまうと（多分、これが正解でしょう）、ここで問題が起こります。

　もし、クラス内に、まったく関係のない、他のクラスに依存する属性を持たせて、それをインスタンスにしてしまったら、どうなるでしょう・・・オブジェクトは、実在の世界からかけ離れたものができてしまいます。

---

　たとえば、極端な話ですが、顧客クラスに、特売購入フラグというのを作りましょう。
　これは、特売を買う人を、いち早く調べたいからという理由で導入したとします。

　本来なら、これは受注した(受注明細の）商品に付けるべき属性ですので、受注明細につくようなものです。
　（商品という普遍的なものでなく、受注した商品という受注明細の商品関連の属性となる）

　そして、受注明細で、特売レコードをあつめ、そこの明細に対応する受注をした顧客をあつめて、
　顧客データを取り出すべきものです。

　でも、めんどっちいから、顧客クラスに、特売購入フラグというのをいれましょう。

　DBにも、いれちゃいましょう。。。

　とします。

---

　一見、この修正は手っ取り早くて、うまくいきます。

　でも、もし、特売の受注がキャンセルになったら、

　　　特売購入フラグをOFFにしないといけません。

　　　さらに、キャンセルされていても、
　　　　他に特売を買っていたらONにしないといけません。
　
　　　そしてさらに、この場合、特売購入フラグがPublicになっていればいいけど、
　　　privateになっていたら、受注時キャンセルのときに、
　　　　　特売購入フラグが操作できないかもしれません。

　じゃあ、全部publicにすれば・・・っていったら、カプセル化になりません。

---

　つまり、オブジェクト指向で書くのであれば、カプセル化にして、情報を隠蔽するさい、隠蔽しても問題ないように、適切なクラスに属性をいれないといけません。

　そして、その「適切なクラス」とは、

そのクラスを実際の実存する（あるいは想像物の）
　オブジェクト（これをモデル化してクラスを作ったはず）に
　インスタンス化した際、

そのオブジェクトが、対象となる属性を持っていること
　（あるいは持っても差し障りない、持つべきもの）

ということになります。

　そうしないと、へんなクラスに属性を入れてしまうと、隠蔽化されているので、データ操作ができなかったり、値をセットし忘れたりしてしまいます。

---

　ということは、

（１）ビジネスの実態にあった、クラスを切り出す方法と
（２）そのクラスに対して、適切な属性をふる
　　　→局所化して、隠蔽できるように、属性をふりわける

という技術がないといけません。もし、この技術がなく、てきとうにセンスでえいや！とクラスに属性追加してしまうと、そのときはよくても、データが隠蔽されているので、あとで値を直せなかったり（直すために大幅修正になったり）、気づかなかったり（気づきにくくなっているので）する可能性が大きくなります。

　・・そーすると、デスマーチですよね。

blancoみたいな、Excelの設計書からの自動生成は、一度XMLに落としてくれたほうがいいよね！

　まえに、ここで、
　見える化したツールから、形式化（プログラミング言語）なんかを
　自動生成させるには、

　　　　見える化→XML→形式化の自動生成

と、一回XMLを仲介したほうがいいとかきました。
（そのほうが、いろんな形式で自動生成したい場合、よい）

---

　Excelの設計書もふくめて、設計書っていうのは、プログラミング内容の見える化、ないしは、プログラムにいたるまでの思考過程の見える化だと思うわけであります。

　ってことは、Excelなどの設計書から、プログラムなどを自動生成する場合も、いったんXMLを経由したほうがいいような気がするんですよ。

---

　たとえば、blancoなどの場合、Excelの設計書から、いろんなプログラミング言語を生成してくれるけど、あたらしい言語が出てきた場合や言語仕様が変わった場合、それに対応するには、VBAからいじらないといけなくなってしまうと思うんですよ。いまのような、Excelからソース自動生成だと。。。

　それよりも、Excelの仕様書から、XMLに落としてくれれば、
XMLから、ある言語を自動生成するプログラムは、VBAで書く必要はなく、（XMLが扱えれば）好きな言語でかけるので、
　自動生成プログラムを作れる人は増えるし、
　自動生成の稼動環境も増えると思う
（VBAに限定してしまうと、Windows環境になってしまうが、Excel仕様書からXMLに落として、そのXMLから自動生成するなら、自動生成部分は、LinuxでもOKになる。また、仕様書もExcelで書かなくても、OpenOfficeでも、おなじXMLで書き出せればOKとなる）。

---

　ってことで、自動生成は、いったん設計書（＝ある意味、見える化ツール）からXMLに落とし、そのXMLを各種プログラミング言語の自動生成（形式化の自動生成）に変換したほうが、いいような気がします。

クラスとエンティティが関連する論理的根拠。。

　Javaなどのプログラムのクラスと、RDBのテーブル、ER図のエンティティは、１対１対応とまではいかないものの（もし、１対１対応なら、O/Rマッピングツールなどはいらないはずだ）、もし、やろうとすれば１対１対応できるし、そうでないにしても、おおまかな関連は、たいていある（いくつかのテーブルをまとめて１クラスのような）。

　この根拠は、どこにあるのか・・という話。

　クラスをインスタンス化したのがオブジェクトであり、オブジェクトはモノとして存在している＝１つ１つが識別できる。
　一方、テーブル（エンティティとほぼおなじようなもん）をインスタンス化したものがレコードであり、これは、主キーにより、１つ１つが識別される＝一意に決まる。

　ってことは、レコードもオブジェクトも、
　　　　　エンティティをインスタンス化したものと考えられるわけで、
　ってことは、そのもととなるエンティティに対応する
　　　　　クラスとテーブルに、だいたい関係があってもおかしくない。

---

　ということになるけど、ってことは、テーブルに対応するのは、J2EEなんかだと、（エンティティが対応するクラスである）エンティティBeanっていうことになりそうなわけで、これに対して、セッションBeanは、ある業務プロセスにおいて、各種のエンティティを呼び出し、それらのトランザクションを管理するってことで、エンティティBeanとちがい、業務プロセスに対応するほうが近い。

　そして、もっと簡単に使うRESTの場合や、サーブレットの場合は、業務プロセス（＝ユースケース）に対応する部分が、コントローラーになったりするわけで（業務プロセス実行時→画面でボタンをおしたり、イベントを発生させるのが普通→サーバーを呼び出すのが普通→サーブレットを呼び出す：はじめと最後を切り出すと、業務プロセスは、サーブレットに対応しがちになり、そのサーブレットは、モデルを呼び出すコントローラーになる）。。。

　このコントローラーであるサーブレットに、セッションBeanの役割を持たす（トランザクション管理をさせる）か、
　エンティティBeanに相当するモデルのクラスの中にあるメソッド（＝これが、業務プロセスに対応）にトランザクション管理をさせるかは・・

・・・自由だー

ということになるんだろう。

グーグルケータイOS、androidのお勉強（８）－メソッドその２

　久々に、シリーズ「グーグルケータイOS、androidのお勉強」。
　今、画面をやっています。
　画面では、レイアウトのXMLと、Javaのクラスが必要でした。

　Javaのクラスでは、
　　onCreate()　　　　　　　：アプリ生成時
　　onCreateOptionsMenu()　　：メニューオプション作成
　　onOptionsItemSelected()　：メニュー項目が選択された

　を書き換えないといけなく、前回はonCreateをやったので、今回はonCreateOptionsMenuです。

---

■onCreateOptionsMenuの記述

　サンプル画面にはメニューがありました。そのメニューが作成されるとき、onCreateOptionsMenuが呼び出されるようです。

　で、このonCreateOptionsMenu、画面のクラス（ここでは、Notepadv1）に以下のように記述するようです。

 public boolean onCreateOptionsMenu(Menu menu) {
        boolean result = super.onCreateOptionsMenu(menu);
        menu.add(0, INSERT_ID, R.string.menu_insert);
        return result;
    }

（上記枠内は、http://code.google.com/android/intro/tutorial-ex1.htmlのStep９から引用）
Menuに関しては、Notepadv1.javaで

import android.view.Menu;
import android.view.Menu.Item;

を上のほうで宣言しています。

で、上位のonCreateOptionsMenuを呼び出し、menu.addでメニューを追加します。

このメニューのことば、R.string.menu_insertは、プロジェクトのフォルダーの下、res/value/strings.xmlに記述します。

---

■res/value/strings.xmlの記述

そこでは、こんなふうになっています。

＜resources＞
    ＜string name="app_name"＞Notepad v1＜/string＞
    ＜string name="no_notes"＞No Notes Yet＜/string＞
    ＜string name="menu_insert"＞Add Item＜/string＞
＜/resources＞

（上記＜　＞は、本当は半角。サンプルプログラムから引用）

そこの
＜string name="menu_insert"＞Add Item＜/string＞
が表示内容にあたります。

---

と、こんなことで今回はおわりにします。。