以前思考実験をしまして( http://d.hatena.ne.jp/gallu/20060822/p2 )、おもいっくそ否定してたのですが。
ふとぜんぜん違う道のりから「使える？」とか思ってみたりしまして。はい。
現状、某OSS使ってるですが。
もちろん(って発言もまた失礼ではあるのですが)改修したい部分ってのはあって、改修をするです。
一方で。OSSを管理されているかたがたはそれなりにバージョンアップをされるです。
さて問題があります。
勝手改修は、あるバージョンn.n.nに対して行います。プログラムをごりんがりんがしゃんといじるわけですね。
一方で公式の修正もまた、n.n.nに対して行われます。
かくしてn.n.n+1勝手とn.n.n+1公式の２バージョンってかブランチが出来上がります。
終了。
…と、ここで終わられても困ります。公式のバージョンアップには大抵「セキュリティフィックス」が含まれていて、時々それが「しゃれにならんくらいクリティカル」だったりすることもあるので。
ただかといって「がんばってマージする」ってのも、結構これはこれで手間がかかります。
そこでDIコンテナの登場です！！
勝手改修のルールとして「公式に配られているクラスには一切変更を行わない」ことにします。で、変更したいクラスに対して「継承で」必要な部分をごりんがりん上書きます(それ継承違ういうな)。
んで、DIコンテナにある「newすべきクラス名」を書き換えます！！(←ここがポイント)
そうすると、変更部分はどのみち「継承先のクラス」に格納されているので、その辺だけ見直せばよく。
一方で「継承元の公式のクラス」に「クラス内で完結したセキュリティフィックス」があればその辺はまるまる享受できます。
ソースを見直すにしても、ChangeLogとか含めて目を皿にすれば「直接コードいじってた」ころよりは大分マシになるんじゃないでしょうか？
まぁ「新しいクラスが沸いて出てきたり」「インタフェースががらんごろんと変わったり」色々ネックはありますが。
少なくとも「一定の方向性」が出せるだけでもましなんじゃないでしょうか？
「っそっかぁDIコンテナってこゆ時に使えるんだなぁ」と、また奇妙な方向に思考を回してみましたｗ
