6

現在、コード ベースでcheckstyleを実行しており、 privateアクセス修飾子を使用しない非静的クラス フィールドにフラグが立てられます。

これは有効な checkstyle ルールですか、それとも非プライベート フィールドを持つことが望ましい状況はありますか? たとえば、JUnit テスト ケースが同じパッケージで作成される理由は、デフォルトのアクセス修飾子を使用してフィールドにアクセスできるようにするためだと思いましたか?

4

6 に答える 6

7

オブジェクト指向プログラミングの主な機能の 1 つは、情報の隠蔽/カプセル化です。これは、クラスがインターフェイスを介してのみメンバー変数へのアクセスを許可することを意味します: getter および setter メソッド。そのため、他のクラスはメンバー変数にアクセスできず、不要な方法で変更できません。したがって、checkstyle ルールは有効です

于 2011-03-30T10:09:17.003 に答える
6

効果的な Java 2nd の項目 13: クラスとメンバーのアクセシビリティを最小限に抑えます。

これをチェックしてください。それは素晴らしいアイデアを与えてくれます。

于 2011-03-30T10:07:45.687 に答える
5

IMHO可能な限りフィールドprivateを作成するのが最善です。finalただし、単体テストの場合は、それらをパッケージ プライベートにするか、リフレクション経由でアクセスすることが実際的な選択になる場合があります。（これは同じことになります）

また、ブラック ボックス テストのアプローチを取ることもできます。つまり、パブリック メソッドを介して何が起こったのかを判断できない限り、テストすべきではありません。(または、テストをより工夫する必要があります)

于 2011-03-30T10:12:28.107 に答える
2

JMockit のような高度なモッキング フレームワークでは、プライベート アクセスやファイナリティは問題になりません。ただし、ゲッター/セッターは、Android の古いバージョンではパフォーマンスが低下する可能性があります。

于 2011-03-30T10:24:42.333 に答える
1

一般に、プライベート フィールドを使用することは理にかなっていますが、規則には例外があります。考えられる例外の 1 つは、データ転送オブジェクト (DTO) を扱っており、プロパティの値を設定してもバックエンドで変更が発生しないことをクライアントに明確に伝えたい場合です。public フィールドは、それを伝える良い方法です。

于 2011-03-30T10:13:57.257 に答える
0

OOP の重要な側面である情報隠蔽が正しく行われることを保証する有効なルールだと思います。

オブジェクトがその状態の変更を制御できる場合は、代わりに Public getter および setter メソッドを使用してください。

于 2011-03-30T10:13:48.227 に答える