Java RDF および OWL エンジン Jenaに精通している場合は、可能であればすべてをインターフェースとして指定する必要があるという彼らの哲学に出くわしたことでしょう。これは、Resource、Statement、RDFNode、Property、さらには RDF Modelなども、最初に考えるかもしれないことに反して、具象クラスではなく インターフェースであることを意味します。
これにより、ファクトリが頻繁に使用されます。PropertyやModelをインスタンス化することはできないため、それを行う何か他のもの (Factory デザイン パターン) を用意する必要があります。
私の質問は、ライブラリが提供しようとしているコンテンツの性質を考えると、従来のクラス階層システムとは対照的に、このパターンを使用する理由は何ですか? 多くの場合、どちらを使用しても完全に実行可能です。たとえば、データベースに基づくモデルの代わりにメモリに基づくモデルが必要な場合は、それらのクラスをインスタンス化するだけでよいので、Factory にクラスを提供するように依頼する必要はありません。
余談ですが、私は現在、Pearltreesのデータを操作するためのライブラリを作成中です。このライブラリは、Pearltrees の Web サイトから RDF/XML ドキュメントの形式でエクスポートされます。このライブラリを作成するとき、Peartrees データに存在する関係を定義するための多くのオプションがあります。Pearltrees データの優れている点は、非常に論理的なクラス システムがあることです。ツリーは、ページ、参照、エイリアス、またはルート パールのいずれかであるパールで構成されます。
私の質問は、Jena を使用するライブラリで Jena の哲学を採用すべきか、それとも無視して独自の設計哲学を選択し、それに固執するべきかを理解しようとすることから来ています。