連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
AJOの話。粘着気味。 - 設計と実装の狭間で。
技術的なことで言えば、Annotationの情報は、コンパイル後にクラスファイルから取り除くこともできます。 ここだけは、ちょっと納得出来ませんでした。 基本的には、RetentionPolicyを決めた時点で、クラスバイナリの中に取り込まれるか否か、 及び実行時にVMにロードされるか否かは決まってしまう筈では…と思います。 独自実装したaptによって、クラスバイナリをコンパイルし直す事で、 Annotationを除去出来ると言う事をおっしゃっているのでしょうか…。 「最終的に開発が楽になるなら、Annotationに依存するくらいは、大目に見てPOJOと呼ぼうよ」そういうことです。 この辺は、僕が些細な事に拘ってるのかなぁ…とは思います。 大局で向いてる方向が違う。と言う事では無いので。 大目に見るのも、構わないと思います。 ここから先は、僕のわだかまりです。 只、僕はどちらかと言うと捻
設定とAnnotationと実装と。その２ - 設計と実装の狭間で。
AnnotationがXDoclet化するとダメなのは、 XDocletによる記述は、最終的に出力される「設定」の一時的な記述領域でしか無い為。との事。 要は、XDocletを使って出力されたXMLファイルを、全く触らずに運用していくのは 現実的に不可能に近いからなんですね。 id:masataka_kさんも仰っていますが、 Annotationによってコードに意味付けが為される事には大きな価値があると思います。 例えば、今までマーカインターフェースと言う実装ギミックがありました。 java.io.Serializableの様に、メソッドを持たないインターフェースの事です。 これは、フレームワークが、何らかの形で「実装」を自動的に扱う時、 大きな助けになります。 と、言う訳で、今日はちょっとだけ、コードモドキを書いてみたり。 ちなみに、Annotationの名前付けは、雰囲気をだす為のもの
AJOってどうよ？ - 設計と実装の狭間で。
大量のXML、特定のAPIに依存した実装、明らかに多すぎる機能。を持つオブジェクトとして、 EJBがあります。3.0では、それらが軽減されるような方向にあるのは知っての通り。 EJBに対して、特定のAPIに依存しない実装、必要最小限の機能。を持つオブジェクトを最近では、POJOと呼びます。 でも、最近気になっている事があります。 「ドサクサに紛れて、POJOと呼ぶのはちょっとオカシイオブジェクトが無いか？」 そうです、EJB3.0のオブジェクトです。 Annotationによって修飾されたオブジェクトをPOJOと呼ぶのは、抵抗があります。 何故なら、オブジェクトが期待される全ての機能を実現する為に、 明らかにAnnotationに依存しているからです。 Annotationに依存しているという事は、つまりは特定のAPIに依存していると言う事になります。 と、言う訳で、こういうオブジェクトを
設定とAnnotationと実装と。 - 設計と実装の狭間で。
最近、設定とAnnotationと実装の境界について考え直し始めています。 その昔、設定と言えば、.conf、.properties、.iniのようなキー＆バリュー形式のテキストファイルでした。 今でも、恐らく最も単純且つ理解し易く、実行速度が速い方法です。 しかしながら、設定情報が複雑化する過程の中で、情報をある程度階層構造化しなければならない局面が出てきました。 そこで、登場したのがXMLファイルによる設定の記述です。 XMLファイルでは、単に構造化された情報を記述出来るだけではなく、 DTDやXMLSchemaと言うメタ情報を記述する事が出来る為、 記述内容の妥当性を、ある程度の範囲ではチェックする事が出来ます。 スクリプト言語の世界では必ずしもそうではありませんが、 ほとんどのフレームワークで、XMLによる設定の記述がなされています。 XMLによる設定は、どんどん複雑化していってい
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日本IBM
amberarcher.org