Twitter4Jでpublicなインターフェースがあって、その実装クラスがpublicでない感じなのだが、まぁ、これはこれで実装クラスを隠蔽して触らせない感じでライブラリを作る側からすると変更しやすいのでよくあるパターンの一つかと思う。でも、リフレクションをしたりするには実装クラスがpublicでないから、publicなインターフェースを使わないとアクセスできない。Seasar2 の Beans とかは実装クラスを使うので取れない感じに陥る。昔は綺麗な感じの設計が好きだったので前者の方だったのだけど、今は開発現場で便利に使える方が重要なので実装クラスはpublicでもいいんじゃない派になっている(publicフィールドにも結構抵抗があったけど、今じゃあれはあれで現場で便利だから拒否反応はなくなった)。S2のBeansで引数増やすとか、ゴニョゴニョと頑張るとかもあるかもしれないけど、そこでがんばるのも微妙な気がして…(Beansの中で実装クラスがpublicじゃなかったらインターフェースを取りにいってアクセスするとか?)。うーん、美しい設計(いまいち何と表現するのが良いか分からんけど)がいいのか、現場で便利なのがいいのか、どちらも間違ってはいないと思うしな。そんな私を悩ます問題は、ディスカッションの「TFJ-298 リフレクションで値が取れない」という話。いろんな考えがある気がしますが、他の方のご意見も興味ありますので時間がありましたらよろしくお願いします~。
Practical API Design や Effective Java の影響を強く受けています。
今はIDEのリファクタリング機能が進んでいるので一つのプロジェクト内で極端に隠蔽するよう設計しなくてもテストケースさえあればpubilcなフィールドでもメソッドでもじゃんじゃん変更がかけられますのでなんでもかんでも隠蔽しておこう、となると面倒なことも多いですね。
ただ、リフレクションは一般的に"hack"なので、リフレクションをしやすくするために public にしておく、というのはちょっと妙な感じを受けます。
Twitter4J は非常に多くのプロジェクトで使われており、利用者のレベルは様々です。
意図しない使い方をされてしまい将来互換性のないクライアントコードが出てしまわないように、言い換えればTwitter4J をリファクタリングしても利用者のコードに影響が及ばないように、可能な限りクラス、メソッドは隠蔽するように設計しています。
コメントをありがとうございますー。
そのやり方も正しいと思っています。
あそこではSeasar2が中心な話になってしまった気がしますが、
個人的には他のフレームワークなどでは影響はないのだろうか、
というのに非常に興味があったりします。そんなわけで、
広く公開ライブラリとして使ってもらうためには、隠蔽して
利用者のコードに影響がない方向が良いのか、謎のフレーム
ワークでもそこそこ動くような方が便利なのか、悩み中です。
あ、そのJIRAの件はクローズしてしまっても構いません。
お手数をおかけしました。