それがないとコンパイルできないという定義で良さそうだ。クラスライブラリの考えで、良さそう。Fowlerの言うPOJOは、flamework非依存での話。■DIとは依存性をinterfaceのみに手中させる考え方らしい。いう言葉は、ローカルな話。classがないので、フレームワーク依存度が高い。■DIは外部への依存は、自分が書くのではなく、Frameworkが渡してくれると思って使う手法、intefaceにのみ問い合わせて、実装クラスに対しては問い合わせない。■interfaceの互換性問題の解決が不明。S2Containterの定義するinterfaceはアプリには入らない。getComponent()のようなコンテナ依存APIは、アプリ側は使わないのが流儀。■インターフェイス依存のコーディングか今後主流になるかもしれない。Objective-Cの様に相手の型に依存しない書き方にしていきたい。■コンテナに問題があった場合、どうするのか?コンテナが問題を起こす可能性は高まるが、アプリプログラマーが書くよりは、まだマシなはず。コンテナ開発者にがんばってもらいましょう。Methodを否定している物ではないらしい。Methodパターン"(バグパターン)は満たさないのでダメだろう。必要なときに開発を要求する。Non-volatile)か。■WSDLのまずい点は、interfaceまたはclassを書いてから定義するので、順番が逆になっている。WSDLは手書きできないので作りにくい。Corba-interfaceのみでの依存関係なので、実装としては正しい。8086系CPUのportコントロールのCのコードで、歴史的背景を理解しないと理解しにくい。■Templateは動的入れ替えができない、マクロによる静的Factoryのようなものと言っていいだろう。他のUIとの並列配置による見やすさという意味がある。Closureという関数pointerを持った発想方法に見える。使う物だけtypedefで引っ張ってくればよいのではないのか。call"にするか"event"にするかの区別に見える。dyamic_cast(s))はjavaならinstanceOf()のイメージとなる。replacementという可能性はありえるのか、多分ないと思う。■新しいVMは古いjarは常に読めるはず。■C#もdreprecardのmethodは出てきているかもしれない。2.0で変わった物はあるのかもしれない。ようだが、Mementoではない、つまり保存しているのではなくCommandオブジェクト自体がスタックされていっている。Objectパターン■結局は自分でMultithreadを組み込むケースの話。J2ME環境でMultiThreadを使いたい時に、自分で作り込む話らしい。multithreadは自分では作るべきではないのではないのか、ちゃんと動く保証がない。Methodは使い道がほとんどない。Methodのめずらしい好例かもしれない。quickSortよりも最悪ケースではbubbleも遅くはない。■Hashtableが一番遅いという噂が出回っているが、誤解だ。hashtableはjavaも昔は最初の16byteで作ったが、今は直っていて、同じHashが固まりででてくることはない。DIP(依存性逆転の法則)に違反するらしい。