0

私がこの質問をするのは、彼らが非常に正当な理由でそれを行ったと信じており、ほとんどの人がそれを適切に使用していないと信じているからです.とにかく、これまでの業界での私の経験から. しかし、私の理論が本当なら、なぜプライベートアクセス修飾子が含まれているのかわかりません...?

デフォルト アクセスを適切に使用すれば、カプセル化を維持しながらテスト容易性が向上すると思います。また、プライベート アクセス修飾子が冗長になります。

デフォルトのアクセス修飾子を使用して、他の世界から隠す必要があるメソッドに一意のパッケージを使用することで、同じ効果を提供できます。テスト容易性を損なうことなくこれを行います。ソース フォルダーで宣言されているすべての既定のメソッドにアクセスできます。

これが、Javaがパッケージアクセスを「デフォルト」として使用する理由だと思います。しかし、プライベートアクセスも含まれている理由はわかりません。有効なユースケースがあると確信しています...

4

2 に答える 2

0

ちょっとした思考実験を提案します。次のコードを検討してください。

public void promoteUser(User user)
{
    int newRank = computeNew(user);
    user.setRank(newRank);
}

private int computeNewRank(User user)
{
    return user.getRank() + 1;
}

テストする必要があると感じるかもcomputeNewRankしれません (実際の実装ではもっと多くのことができるかもしれません)。しかし、そのことを少し忘れて、インライン化の魔法を使って次のようにします。

public void promoteUser(User user)
{
    int newRank = user.getRank() + 1;
    user.setRank(newRank);
}

この実験の優れた点は、あらゆる規模のプライベート メソッドに適用できることです。プライベート メンバーをインライン化し、 「ここで本当にテストしたいことは何ですか?」と自問することを常に想像できます。. それはプライベート メソッド自体ですか、それともプライベート メソッドを装ったまったく新しい機能を備えた新しいクラス/コンポーネントですか? 要点は、プライベート (またはパッケージ/内部) メンバーをテストする必要があることはめったに(あったとしても!) すべきではないということです。外の世界にとって、あなたの契約消費者にとって、それらはすべて無関係な詳細です.

もちろん、すべてをシステム テストに置き換えることもできます。それでは、通常のワークフローはどのようになりますか? ランク プロモーション コードをテストするために、ユーザーをログに記録し、セッションに登録し、3 分間待ち、プロモーション コードを入力し、SMS を受信し、確認する必要があるとしたらどうでしょうか。

単体テストはあなたのためのものであり、その逆ではないことを覚えておくとよいでしょう。それらを曲げたり、調整したり、適合させたりして、より高品質のソフトウェアを提供できます。この目的は、 100% のカバレッジという魔法のような目標を達成するのを助けることではなく、遭遇するバグや障害により迅速に対応できるように、行っていることについてすぐにフィードバックを提供することです。つまり、生産性を向上させるためです。

于 2013-12-02T16:19:16.183 に答える