XoopsObjectは寿命を延ばす
XoopsObject は、XOOPS で最も悪いクラスののうちの1つです。Onokazu さんもそれを認めました。しかし、今になって新しいクラスを導入することは、難しいです。私が思うに、大部分のモジュール開発は、 RAD ベースになるでしょう。従って、クラスのコードがクリーンアップされるならば、問題は少ないといえます。

私達は、 XoopsSimpleObject 、及び、 XoopsObjectGenericHandler を作りました。XoopsSimpleObject は、我々が抽出した XoopsObject の共通インターフェースを実装します。クラスダイアログを見てください :
XoopsObjectCD

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サービスにかかわりなく、開発者は、彼らのコードを変える必要がありません。私が思うに、このことは、近い将来重要になるでしょう。それは、ブリッジ技術にとって有益なように思われます。

しかし、その感覚は、私がアマチュアである私の経験から来たかもしれません。それは、専門家には役に立たないかもしれません。
|