これはすでに質問されたように思えるかもしれませんが、この特定の方法で尋ねられた質問は見つかりませんでした。私はセッターを追加することがこのコードを改善する方法を理解していません。私はセッターを追加するのが標準的な習慣であることを知っていますが、私は理由を理解していません。このフィールドは変更できません。cards以来セッターなしのゲッターの使用
public class DataHelper extends Activity {
private final double cards = 52;
public double getCards(){
return cards;
}
は意味がない、ここでセッターを追加し、finalです。
finalではありませんでしたが、外部の変更を許可したくない場合は、 セッターを追加することは意味がありません。
デザインでフィールドに外部変更を許可するのが適切な場合にのみ、セッターを追加します。
なぜフィールドを直接変更するのではなく、セッターを追加するのかというと、答えはカプセル化になります。 メソッドを介してのみアクセスを提供することにより、ユーザに影響を与えることなく、基礎となる実装を変更することができます。
より良い例は、Fontクラスです。 フォントの一般的な特徴は、サイズをピクセル単位またはポイント単位で指定できることです。 内部表現がポイント内にあり、それをフィールドとして公開する場合は、内部表現をピクセルに変更する必要がある場合は 、後で に変更することはできません。 代わりに、セッターを提供すれば、 誰にも影響を与えずに内部表現を自由に変更することができます。
フィールドに直接アクセスする代わりにメソッドを提供すると、後でクラスの内部を変更してユーザーに影響を与えずにオプションを開くことができます。 これはカプセル化、情報隠蔽に適しています。
これは私にとって理にかなっています。私は変数がfinalに設定されている場合、ショートカットキーを使用するときにAndroid Studioがセッターを作成しないことを知りました。ファイナルを削除すると、セッターを作成することができます。 – seekingStillness
setterが不要な環境（ORM /依存関係注入/シリアライズフレームワークなど）でクラスを使用する場合は、setterを使用しないでください。 この特別なケースでは、変数はfinalで一度しか設定されていないので、セッターはあまり意味がありません。だから、カードメソッドを使ってプライベート変数の価値を得ることは悪い考えではありません。
セッターを追加することは、標準的な方法ではなく、一般的な反パターンのようになります。 –
あなたが話している価値があなたが他のクラスを修正させたいものであるかどうかによって決まります - 答えが「はい」である場合もあれば、そうでない場合もあります。答えがノーなら、セッターメソッドを追加する理由はなく、実際には物事を害するかもしれません。 – csmckelvey
getterのJava命名規則は 'getXxx'です。ここで' xxx'はプロパティです。 –