禁止されているサードパーティの方法について警告する


9

注:この質問は、JavaまたはC#で記述されたコードに関するものです。

私はいくつかの大規模なプロジェクトを管理しており、サードパーティ/ SDKのメソッドで問題(必ずしもバグではない)を発見し、代わりに使用する必要がある独自の拡張機能を作成しました。これらの方法を使用することは、このプロジェクトでは推奨されないことを開発者に覚えておいてください。

独自のライブラリを使用していた場合は、そのメソッドを簡単に削除したり、廃止/非推奨にしたりできますが、自分で作成していないライブラリに対してはそうすることはできません。

例として、2つのオーバーロードを提供するライブラリを使用します。

acme.calculate(int quantity_, double priceInUsDollars_);
acme.calculate(int quantity_, string currencyCode_, double priceInCurrency_);

私たちは開発者が常に最初のものを使用して、私たち自身の標準的な為替レートシステムから米ドルで価格を得ることを望んでいます。そして、IDE(Eclipse / Visual Studio)が最初の開発者を使用するときに開発者に警告するのは良いことです。コンパイラの警告でも十分です。

今のところ、現状では、コードレビュー担当者にそのようなエラーを発見してもらう必要があります。ご覧のとおり、これは信頼できるアプローチではありません。

準備ができている1つの方法は、独自のチェックスタイルチェック(http://checkstyle.sourceforge.net/writingchecks.html)を記述することです。でも、何か使えるシンプルなものはないのかと思っていました。私が説明したようなIDE /コンパイラの警告を達成する方法を知っている人はいますか?

IDE /コンパイラ以外のソリューションは大歓迎です。


1
ソースをサードパーティのライブラリに変更できないのはなぜですか?あなたそれを持っていると思いますか?(そうでない場合、それはあなたが集中する必要がある本当の問題です。決してそれをしないでください。)
Mason Wheeler

3
@MasonWheeler残念ながら、実際にはできません。これは、使用するコンパイル済みバイナリ(.dll、.jar)です。我々はなど。、(私達にとって非常に重要である)のサポートを逃して、最新のをオフに行くことができるように加えて、そのアプローチには落とし穴がある
Apoorv Khurasia

4
@MasonWheeler:サードパーティのlibのソースコードへのアクセスは、自由に選択できないことがよくあります。市場には、有用なオープンソースの代替手段が存在しないクローズドソースのライブラリがたくさんあります。
Doc Brown、

ライブラリ内のクラスを継承し、廃止されたものとしてマークされている、呼び出したくないメソッドにオーバーライドを追加できますか?
CaffGeek 2012年

@DocBrown:私はオープンソースとは言いませんでした。利用可能なソースを言った。あなたがそれを購入するときあなたに(独占的なライセンスの下で)あなたにソースを与える多くの独占的なライブラリがあります。利用可能なソースのないサードパーティのライブラリを絶対に使用しないというポリシーが機能しており、必要な状況を見つけたことはありません。
メイソンウィーラー

回答:


7

NDepend / JavaDependなどのツールを使用して、カスタムCQLクエリを記述し、これらの非常に特殊なケースに対して警告を生成できます。

質問で、IDE /コンパイラに開発者に警告することを望んでいると述べました。NDepend / JDependはIDEと緊密に統合されているので、これで問題が解決するかもしれません。


3
それは良い電話です。また、関連する他のツール(ソース管理、ビルド)に応じて、違反するチェックインで警告/アラートが発生したり、チェックインが拒否されたりするNDepend(JavaDependを使用しなかった)でスキームを簡単に作成できます。
Erik Dietrich

これは有望に聞こえます。明日これを試してみます。マットに感謝します。
Apoorv Khurasia

彼らは製品名をJavaDependからJArchitectに変更したようですが、プログラムはまだかなり面白そうです。
Dalin Seivewright、2014年

4

「ホワイトリストアプローチ」:ラッパーライブラリをライブラリに書き込みます。ライブラリ自体と基本的に同じインターフェイスシグネチャを使用しますが、禁止されている関数は除外します。ラッパーは、各メソッド呼び出しを対応するライブラリ呼び出しに委任する必要があります。次に、開発者が元のlibではなく、そのラッパーのみを使用/リンクできるようにします。ラッパーは、ライブラリー拡張の適切な場所でもあります。

libが数百の関数を持つ非常に大きなAPIを持っている場合、それは実用的ではないかもしれません。次に、提案した「チェックスタイル」ソリューションのような「ブラックリストアプローチ」を実装します。


うん。巨大な図書館です。しかしさらに悪いことに、(C#やJavaプロジェクト全体で)そのようなライブラリがたくさんあります。コンパイル後の蟻チェックも考えています。
Apoorv Khurasia

2
これも私の最初の考えでしたが、OPの質問をもう一度読んだとき、彼はより制限的なアーキテクチャではなく「警告」を探しているようです。これは、より多くのコードを記述するよりも静的分析の問題だと思います...
MattDavey

@MattDaveyそれは本当です。
Apoorv Khurasia

面倒な部分を行うラッパージェネレータープログラム(たとえばsourceforge.net / projects / wrappergen)があります。次に、手動で行うには、いくつかのメソッド削除または注釈のみです。
ロスパターソン、

@RossPattersonラッパーは、1回限りの設備投資ではありません。彼らは場合によっては、maintainanaceの悪夢になることがあります。
Apoorv Khurasia

2

JavaのReflectionの強力な機能の1つは、実行時にメソッドのプロパティを変更できることです。使用方法の1つは、プライベートメソッドをパブリックにして、とにかくそれを使用できるようにすることです。実行時に不要なメソッドをプライベートにすることで、逆にうまく機能する可能性があります。コンパイル時には表示されませんが、プロジェクトがテストされるとすぐに表示されます。

この記事では、実行時にメソッドのプロパティを変更する方法を示します。ここに興味深い部分があります:

Class theClass = MyClass.class;
Class[] paramTypes = { Integer.TYPE, String.class };
Method method = theClass.getDeclaredMethod("myMethodName", paramTypes);
method.setAccessible(false); // this makes the metod private
System.out.println("Making method  myMethodName(int,String) private");

1
ありがとう。最初にMattDaveyのソリューションを試してみます。静的な分析ができるからです。そうは言っても、すべての静的なアプローチが失敗した場合、私はあなたの解決策を試します。
Apoorv Khurasia

1
それはうまくいきません。コンパイルされたコードの場合、可視性ルールが最後にチェックされるのは、バイトコードが検証されるロード時です。リフレクティブAPIを使用したその後の変更は、他のリフレクティブコールにのみ影響します。
スティーブンC

0

これらの方法を使用することは、このプロジェクトでは推奨されないことを開発者に覚えておいてください。

場合によっては、すでに置換メソッドを作成する必要があるため。ライブラリ全体のラッパークラスを作成し、ラッパークラスのみを使用します。

ライブラリが更新された場合は、とにかくコードを更新する必要があります。ラッパークラスは更新が簡単です。

それでも、開発者が間違ったメソッドを使用するのを回避できます。開発者は、使用することを想定していないメソッドを覚えておくことができるはずです。


3
いいえ、開発者が彼が使用しているライブラリの完全に論理的なメソッドを「使用するべきではない」だけであることを覚えておくと期待するのは合理的ではありません。おそらく1つか2つですが、原則として、人間はそのようなことを確実に思い出すことはできません。ヘックで高度な訓練を受けた、やる気のあるパイロットは、飛行機を安全に離陸させるための詳細をすべて覚えているとは信じられません。そのため、コックピットのチェックリストがあります。
Michael Kohne

それがまさに私が欲しいものです。その関数を使用すると、IDEが警告を生成します。
Apoorv Khurasia

@MichaelKohne-私が著者と同様の問題を抱えていたとき、私はどの方法を使用すべきか思い出すのに何の問題もありませんでした。問題のライブラリは簡単に100の異なるメソッドでした。
ラムハウンド
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.