リフレクションを通じてプライベートメソッドが呼び出される状況に対処する必要がありますか？

ライブラリを作成するとき、同じクラスの他のメソッドではなく、リフレクションを通じて別のライブラリによって呼び出されたときに、プライベートメソッドが期待どおりに動作することを確認する必要がありますか？

たとえば、プライベートメソッドが以下をprivate DoSomething(int number)期待している場合：

• number は、ゼロ以外の正の整数であり、次のとおりです。
• プライベート変数string abcはnullではなく、空の文字列でもありません。

そして、完全に、これらの2つの条件が一致しない場合、い失敗します。クラスのすべてのメソッドが常に空でない値を割り当てて、をabc呼び出す前にこれらの失敗を処理する必要がありDoSomething、これに正の非ゼロ整数を渡します方法？

言い換えると、リフレクションによる安全でない呼び出しから保護されていないコードは低品質コードと見なすことができますか、それともリフレクションを使用して呼び出しが何も中断しないことを保証する呼び出し元に属しますか？

注：私の質問は、ライブラリの標準セットのみを対象としています。これは、高度に安全でなければならないコード（つまり、予期しない動作やクラッシュをさせるためにリフレクションを使用することに興味がある場合）をカバーしません。

^{¹他の開発者がこのメソッドを壊さないようにするための十分な単体テストがあるため、クラスが正しく文書化されているため}

メソッドをプライベートにすることで、意図と契約を確立しました。リフレクションを使用することにより、クライアントコードはこの契約に違反することを選択できるため、結果を負担する必要があります。プロトコルでも同じことが起こります。動作するルールに従う必要があるか、悪いことが起こるからです。

同じ問題は、C ++などの他の言語でも発生する可能性があります。

#define private public

要約すると、これらの状況に対処する必要はありません。発信者はよりよく知る必要があります。

誰かがリフレクションを使用してプライベートメソッドを呼び出している場合、誰かが何か間違ったことをしていることを示しています。彼が設計されていない方法でコードを使用しているか、内部作業の多くを隠してAPIを馬鹿にしているかのどちらかです。

しかし、あなたはまだその段階ではなく、先制的になろうとしているようです。だから私の意見は：それについて心配しないでください。プライベートメソッドは立ち入り禁止と見なす必要があります。誰かが意図的にこれらの制限に違反した場合、物事が爆発した場合、それは彼らの問題です。

さて、使用する前に非ローカル変数を検証することは常に良い考えですが、それ以外は心配しません。他の人が言ったように、そもそもメソッドを非公開にすることで意図を確立しました。クラスの外部からそれを呼び出す人は誰も保証しません。Javaで作業する場合、プライベートメソッドにjavadocコメントを付けません。