クラスにパブリック変数を含めることは(代わりにゲッターとセッターを使用する)悪いOOプラクティスと見なされているので、すべての変数で使用private
しないのはなぜですか?悪い習慣であるのに、なぜJavaは使用を許可するのですか?public
(これは明らかに関数には適用されません)
クラスにパブリック変数を含めることは(代わりにゲッターとセッターを使用する)悪いOOプラクティスと見なされているので、すべての変数で使用private
しないのはなぜですか?悪い習慣であるのに、なぜJavaは使用を許可するのですか?public
(これは明らかに関数には適用されません)
たとえば、変数は正当なpublic static final
理由です。定数のように。
public
またはprivate
フィールドを持つことは設計上の決定です。言語自体は、開発者やチームが必ずしも実装したくない設計を強制するのではなく、プログラマーが独自の設計決定を行えるようにすることを目的としています。
言語が柔軟であればあるほど、それはより強力になります。フィールドにアクセスするための最も適切な方法を決定するのは、プロジェクトマネージャー、チーム、または個々の開発者の責任です。
可変フィールドのアクセス制御だけが問題ではありません。
単純さを考慮してください。Javaには、すべてのタイプのアクセス制御に対する単一のデフォルトがあります。これは、タイプごとに異なるアクセスルールを使用するよりも簡単に習得できます。
新規ユーザーのユーザビリティを検討してください。すべてがデフォルトでプライベートである場合、新しいユーザーは、何かにアクセスできなかった理由について混乱する可能性が高くなります。
最後に、「ゲッターとセッター」がパブリックフィールドの適切な代替手段であるとは限らないことに注意してください。一部のフィールドは、変更したり、クラス外でアクセスしたりしないでください。
[編集]選択の背後には歴史的な理由もあります。当時「オーク」と呼ばれていた初期のバージョンのJavaには、プライベートアクセスがありませんでした。デフォルトの最も制限されたアクセスはパッケージで保護されていました。(参照:この2002年のJavaニュースレター、Oak 0.2マニュアルを引用。)
それはあなたがフィールドを公開したい場所についてです。
フィールドの場合、定数のように、フィールドに対してpublic
安全に行うことができます。final
public static final ...
そしてfinal
フィールド:
public final ...
length
Java配列のフィールドのように。慣例では、フィールドを公開するよりもアクセサメソッド(ゲッター)を提供することです。
protected
フィールドをサブクラスに公開する場合は、フィールドを使用します。
同じパッケージ内の他のクラスにフィールドを公開する場合は、デフォルトの可視性(つまり指定されていない)を使用します。
これは(定数を除いて)この可能性があるのは良いことだと思います。これをstatic final
使用すると(ゲッターとセッターを定義する代わりに)いくつかの問題をすばやく解決できるため、ここではカプセル化ルールを破って注意する必要があります。
それは複雑さを管理することの問題です。
public
メンバーはクラスの外部からアクセスできます。これは、実際的な考慮事項として、「潜在的にどこでも」を意味します。フィールドに問題が発生した場合public
、原因はどこにでもある可能性があるため、バグを追跡するには、かなり多くのコードを調べる必要があります。
メンバーには同じクラス内からのprivate
みアクセスできるため、問題が発生した場合、通常、確認するソースファイルは1つだけです。プロジェクトに100万行のコードがあり、クラスが小さく保たれている場合、これによりバグ追跡の労力を大幅に減らすことができます。
もう1つの利点は、結合の概念に関連しています。いくつかの答えはこれに言及するのを忘れました。
private
デフォルトですべてを作成し、絶対に必要な部分のみを公開しますpublic
(または、ゲッターとセッターを使用します)。あなたが作ることができるprivate
ほど、より良いです。
その理由の大部分は「C++がそのようにした」ことだと思います。さまざまな言語がこの問題について意見を異にしているため、これが唯一の賢明な選択ではないことは明らかです。たとえば、Pythonにはすべてが公開されており、ライブラリのドキュメントに従うことを信頼していますが、Rubyにはプライベートフィールドしかありません。