XoopsObjectは寿命を延ばす
XoopsObject は、XOOPS で最も悪いクラスののうちの1つです。Onokazu
さんもそれを認めました。しかし、今になって新しいクラスを導入することは、難しいです。私が思うに、大部分のモジュール開発は、
RAD ベースになるでしょう。従って、クラスのコードがクリーンアップされるならば、問題は少ないといえます。
私達は、 XoopsSimpleObject 、及び、 XoopsObjectGenericHandler
を作りました。XoopsSimpleObject は、我々が抽出した XoopsObject
の共通インターフェースを実装します。クラスダイアログを見てください :
XoopsObject
は、非推奨になりました。しかし、 XoopsSimpleObject
は、独自のクラス、もしくは、有名なライブラリを持たないビギナーにとって便利です。XoopsSimpleObject
は、タイプセーフ特徴、シンプルなアクセスメソッド、 BOOL INT FLOAT STRING TEXT
である 5 つの DTYPE を持っています。Criteira クラスは、 SQL から分離され、そして、
XoopsObjectGenericHandler は、型安全性と共に Criteria によって SQL
を生成します。
Criteria クラスは動的 SQL
のための情報構造体に変わりました。Criteria::render() は XC 2.1 では非推奨です。
加えて、いくつかのツールが、開発者をサポートします。私は、直接 XoopsSimpleObject
のサブクラスを書いたことがありません。XoopsSimpleObject
を使うために常にツールを使っています。私は、自分より機械を信用しているのです。
私達は、それを強要することはしません。しかし、開発者が DB
にアクセスする際の問題を理解しないのでならば、彼は、 XoopsSimpleObject
やツールを使うべきだと考えます。
ところで、 XoopsObject には、多くの短所と、いくらかのメリットがあります。
Criteria::render() が XC 2.1
で非推奨ですから、あなたは、それを何にでも使うことができます。XoopsObject は、ハンドラによって
DB から分離されます。従って、 XoopsObject
、ハンドラ、及び、Crteiraは、抽象的です。あなたは、そのようなクラスを使うことによってWebサービスを使うことができます。
$handler
=&
gethandler(...);
$criteria
= ...;
$objs
=&
$handler->getObjects($criteria);
開発者は、どこからオブジェクトを得たかを知る必要がありません。それは、 DB
、または、WEBサービスであるかもしれません。しかし、 DB
、WEBサービスにかかわりなく、開発者は、彼らのコードを変える必要がありません。私が思うに、このことは、近い将来重要になるでしょう。それは、ブリッジ技術にとって有益なように思われます。
しかし、その感覚は、私がアマチュアである私の経験から来たかもしれません。それは、専門家には役に立たないかもしれません。