情報クラスの内部設計
momentspace momentspace まず情報クラスとはどのようなものなのでしょうか。 ニコニコ動画が提供しているAPIと一対一で対応しているものなんでしょうか。 それともある機能を実現するために必要な情報をまとめたものなんでしょうか。
途中参加なので把握出来ていないだけかもしれませんが、wikiには書いてなかったので質問させてください。
momentspace 説明の足りない、意味の通じにくい用語を用いてまして申し訳ない。
ニコリブで話している情報クラスとは、ユーザがニコニコのサービスの情報を取得のためにアクセスする情報の概念モデルを指しています。 ニコニコ生放送でいうと生放送クラスは生放送サービスの抽象的な概念を表すクラスで、内部には生放送に関する各種情報および情報群を保持する ようなイメージでいます。情報といっているのは放送中の番組数であるとか階層構造を持たない単項なデータのことで、情報群といっているのは ユーザ情報や放送情報といった情報が階層化するようなデータのことを指しています。各サービスに用意する方向で、「どこに何を持つか」が最初の 課題となってくると思います。サービスの単純なオブジェクトマッピング（サービスが持つ情報と同じ階層、形式で表現する）ならばある程度簡単かと 思いますが、データの種類や取得元によって若干考慮が必要になってくると思います（コメントサーバもそのようなものかと思われます）。 その辺りの設計をとりあえずはオブジェクトマッピングで作った物をたたき台に煮詰めていく感じになると思いますが、たたき台が用意できていません。 言語を絞ってやるのは、そういったたたき台の作成時間の軽減も考慮してですが、なじみの浅い言語で表現されることで他の言語がメインな方の モチベーションが若干低下するのが問題だと思っています。
回答ありがとうございます。
つまり情報クラスというのは複数のAPIやHTMLからの情報を保持するということですね。
そのクラス内で情報をXmlDocumentで持つということは、 ひとつのクラス内で各種APIの取得方法（URLやPOSTのパラメータなど）と情報の保持方法、アクセス方法を定義することになります。 ですが情報クラスではこの他にも、適切なタイミングでAPIにアクセスしたり（来場者数や市場データなど）、 APIアクセスのために他のデータを参照したり（コメント投稿時のPostKeyなど） などのタスクもあり、これらが混在するのはコードの肥大化を招いてしまう気がします。
この問題を解決するため、ぜひ私の書いた草案１にあるようなAPIとの一対一対応のAPI情報クラスを検討していただきたいと思います。 情報クラスではこのAPI情報クラスを内部的に使うようにすればいいので、プロジェクトの構造自体にもそれほど大きな変更は必要ないはずです。
さらにすでにニコニコのサービスに精通している人はこのAPI情報クラスを利用して直接データを利用できるし、 情報クラスの実装段階でもAPIの構造解析（API情報クラスの実装）を待たずに開発を行うことができます。
デメリットとしてはデータにアクセスするのに若干のオーバーヘッドが発生するようになりますが、十分メリットでカバー出来る範囲だと思います。
ライブラリの根幹に関わることなのでモメントさん以外のメンバーの方にも賛成反対の意見をもらえると嬉しいです。
最後に自分が考えているAPI情報クラスの概要を書いておきます。
momentspace API情報クラスを用意するのは面白い考えと思います。メリットとデメリットがあると思いますのでみんなで考えましょう。
私も何点か上げます。
五分五分といったところでしょうか。みなさんの意見待ちで。
情報クラスは情報をどう保持するか。XmlDocumentを内部的に保持する方法が有力っぽい。