Networkは、そのネットワークに属するオブジェクト（KnowledgeとLink）について、Java標準のコレクションであるSetによるアクセス方法を提供します。しかし、場面によっては特定の条件を満たすオブジェクトのみを取得したい場合もあるので（例えば特定のプロパティを有するオブジェクトのみを取得するなど）、常にSetを用いてアクセスするのでは、データすべてを読み出したうえでフィルタリングしなければならず、非効率的です。

そのため、NetworkとSpiderは、特定の条件（SearchOption）を指定して検索できるようなメソッドを提供します。SearchOptionは用途に応じたサブクラスを提供しており、NetworkやSpiderは、指定された検索条件が実装するインターフェイスを調べることによって検索方法を判別します。これにより、Networkが現実に使用するデータベースの機能を用いるなどすることができ、アクセスの効率化が期待されます。

もっとも、現段階ではどのような検索条件が必要になるか明確ではないので、今後、具体的なアプリケーションを構築していくうえで問題が発生すれば、この仕様は変更されるかもしれません。

当初は、それぞれのNetworkが使用するデータベースとの接続オブジェクト（Connection）にはアクセスできないようにし、Network経由で接続を閉じるようなこともできないようにしようと考えていました。Networkがデータベース接続をラッピングするような役割を果たしているからです。Networkから実装側にアクセスできてしまうと、間違って接続を切断してしまうことも生じるのではないか、という不安もありました。

しかし、そのような方針では、アプリケーション側でConnectionを管理しなければなりません。すると、SpiderはNetworkを管理し、アプリケーションはConnectionを管理し、それらが整合するように調整する必要があります。これは手間ですし、バグを作り込む要因になってしまうので、Networkから実装側にアクセスする手段を提供することにしました。

Networkはインターフェイスですから、インスタンスを生成するためには実装クラスのコンストラクタを使う必要があります。しかし、それではアプリケーションとクラスライブラリが実装レベルで結びつくことになってしまい、仕様変更に強い設計になりません。そこで、Networkを構築するための情報として、NetworkSourceというインターフェイスと、NetworkFactoryというファクトリクラスを導入することにしました。

NetworkSourceはSerializableを拡張しており、シリアライズで永続化（保存）できることを想定しています。NetworkSourceのファクトリクラスも作れば完全に実装クラスとの結びつきを切断できるのですが、現段階ではファクトリのインターフェイスが定まっていないので、保留してあります。Networkのストレージとなるデータベースによって初期化に用いるパラメータが変わってくるので（例えばSQLiteではファイル名のみ、MySQLなどではデータベースのURLとユーザー名など）、そう簡単にはインターフェイス化できないのではないかと思っています。