Javaバックグラウンドから来たC#は初めてです。コーディングインタビューの持ち帰りの割り当てに取り組んでいます。通常、コードは次のように記述します(Java):
public class Test {
//fields
private string fieldA;
private int fieldB;
public Test () {
//.....
}
public String getFieldA() {
return fieldA;
}
//ETC.
}
ポイントは、上記のようにゲッター/セッターを使用することです。今、私は就職の面接のために行うコーディングの割り当てがあり、C#を使用して自動プロパティに遭遇しました。最初は少し混乱していましたが、それが今何をしているかを理解し、使用しました。
だからフィールドのために私は書くでしょう
public string fieldA {get; set;}
フィールドをそのようにパブリックに宣言するのは奇妙に感じられ、OOPカプセル化の原則に違反していませんか?
私の質問は、私が先に進み、自動プロパティを使用して、それが何であるかを知っていることをインタビュアーに示すべきですか?私が使用できるフィールドを設定したくない場合:
public string fieldA {get; private set;}
しかし、カプセル化の「ルール」を守っていないように見えても、リスクを冒したくないのは明らかです。 Javaと同じように書き出すことができます。
一般に、自動プロパティの使用についてどう思いますか?
一見すると、これら2つの行は同じように見える場合があります。
public string A;
public string B {get; set;}
しかし、それらはまったく同じではありません。ご存知のように、パブリックフィールドを使用していて、将来、値を取得または設定するときにロジックを追加する必要がある場合は、それを行うことができません(他の人に提供しているインターフェイスを壊さない限り)。値はカプセル化されていないため、できません。
代わりに自動プロパティを使用すると、クラスが提供するインターフェイスを変更する必要なく、いつでもロジックを追加できます。自動プロパティを標準プロパティに置き換えるだけです。または、その逆で、標準プロパティを自動プロパティに置き換えることができます。外部ユーザーには何も変わりません。
つまり、リモートでカプセル化を壊すことさえありません。便利な構文糖を使用しているだけです。
可能であればそれらを使用してください。舞台裏では、コンパイラはフィールドを公開するだけではありません。フィールドはまだプライベートです。
自動プロパティ
public string MyField { get; private set; }
このようなものに変換されます(長いバージョン)
private string _myfield;
public string MyField
{
get
{
return _myfield;
}
private set
{
_myfield = value;
}
}
内部的には、コンパイラーはJavaから知っているようなゲッターメソッドとセッターメソッドを生成します。したがって、OOPの原則に違反することはありません。
自動プロパティは、C#でゲッター/セッターを実行する慣用的な方法です。面接に向かい、C#に堪能であることを示すには、必ず自動プロパティを使用してください。特に、あなたがJavaバックグラウンドから来た場合、Visual StudioでJavaを書くことからすでに一歩先を進んでいることがわかると、面接担当者に安心感を与えるはずです。 。
ただし、public string fieldA {get; set;}
盲目的にコードの匂いです。プロパティのセットを事前にパブリックとして定義し、それらが実際にクラスインターフェイスの一部であるかどうかを確認することは決してないので、非常に魅力的で便利です。そして、実際にカプセル化を(「情報の隠蔽」のように)壊すことができます。
要約すると、それらを使用しますが、それらを美化されたパブリックフィールドにしないように注意してください。
XAMLベースのテクノロジー(WPF、Windows Phone)は、次のようなパブリックフィールドを受け入れないことを知っています。
public string a;
... XAMLでのデータバインディング用。
代わりに、次のようなパブリックプロパティを使用する必要があります。
public string a { get; set; }
彼らは同じように見えますが。ですから、違いはあります。