C＃でゲッター/セッターメソッドを記述することに問題はありますか？
私はJava devのほとんどすべてのプログラミング（少なくとも職場では）ですが、楽しみのためにUnityをいくつか使用しています。C＃プロパティを何度も使用していて、 getterメソッドとsetterメソッドを記述する必要なく、カプセル化を提供します。
とはいえ、代わりに（私の時間以外に）フィールドの実際のゲッターメソッドとセッターメソッドを記述することには不利な点はありますか？これは楽しみのために私の個人的なUnityコード内にあり、いかなる種類の作業環境や共有開発環境ではないと仮定します。
C＃プロパティはメソッドで構成されています。したがって、プロパティの代わりにメソッドを使用しても、実行時の利点は得られません。
代わりに、開発者の生産性とコードの読みやすさがすべてになります。
読みやすさもあなた自身のためです。数か月でコードの詳細を忘れ、バグを修正したり新しい機能を追加したりするためにコードを変更する必要がある場合。それを気にしなくても、おそらく同じ量のコードでより多くのことをしたいと思うでしょう。
生産性の面では、プロパティには少ないコードを記述する必要があるという利点があります。自動プロパティについて話している場合は、はるかに多くなります。読みやすさについては、コードが冗長になります（Getが少なく、Setが少なく、()が少ない）。
プロパティも発見可能性に影響を与える可能性があります。ゲッターとセッターがあると、同じフィールドに関連付けられたメソッドがインテリセンスで分離されます。
ただし、メソッドにはいくつかの引数があります。たとえば、値の設定が失敗する可能性がある場合は、メソッドを使用してboolを返すと、設定が失敗した場合に呼び出し元と通信できます。理論的には、プロパティの使用を回避できます。結局のところ、呼び出し元は、プロパティを設定した後にプロパティを読み取って、値が設定されているかどうかを確認できます。ただし、boolを返すことはスレッドセーフなAPIです。
別のケースは、プロパティが値を返すために長い計算を行う必要がある場合です。メソッドを使用すると、裏で何かをしていることが伝わります。同様に、プロパティの代わりにメソッドを使用すると、値の読み取りに副作用がある可能性があることを伝えることができます（純粋ではありません）。 補遺：これは難しいルールではありません。しかし、一般的にメソッドは何かを行うのであり、それはアクションです。一方、プロパティはいつでも読み取ることができ、大きな影響はありません。
最後に、配列を返すプロパティがある場合、インデクサーではそれを逃す可能性があります。実際のインデクサーを提供するか、混乱を避けるための方法を使用することをお勧めします。
ちなみに、オブジェクト指向という言葉を作り出したアラン・ケイは、セッターが好きではありません。代わりに、状態をカプセル化する必要があります。彼は言った：
多くのいわゆるオブジェクト指向言語にはセッターがあり、オブジェクトにセッターがあると、それをデータ構造に戻します。
Alan Kayにとって、第三者にオブジェクトの状態を予期せず変更させることは悪い考えです。
それを念頭に置いて、プロパティが悪いデザインであるいくつかのケースについてお会いしましょう：
何をすべきかを決定する手段としてプロパティを提供することは避けてください。呼び出し元のコードは、オブジェクトのプロパティを読み取って、呼び出すメソッドを決定する必要はありません。代わりに、そのロジックをクラスのメソッドにカプセル化します。つまり、オブジェクト指向の設計では、Tell、Do n't Askを優先します。
メソッドの動作を変更するプロパティは避けてください。それらがある場合は、プロパティの値をバックアップし、値を変更し、メソッドを呼び出し、値を復元するコードが作成されます。代わりに、その値をパラメーターとしてメソッドに追加します（クラスの実質的にすべてのメソッドに追加する必要がある場合でも）。これにより、APIの使用がはるかに簡単になり、驚きの原則を最小限に抑えることができ、スレッドセーフなコードに適しています。
プロパティ、特に読み取り専用のプロパティは、ロギングとデバッグに非常に役立ちます。また、シリアル化の形式やデータバインディングなど、動作するプロパティに依存するものもあります。
プロパティare "実際のゲッターおよびセッターメソッド"に注意してください。プロパティは、1つまたは2つのメソッドにすぎず、「これはプロパティです」というメタデータの一部です。プロパティメソッドを呼び出すための構文は通常のメソッドを呼び出すための構文とは異なりますが、それ以外は、プロパティメソッドは他のメソッドとまったく同じように機能します。
それは言った...
とはいえ、代わりに（私の時間以外に）フィールドの実際のゲッターメソッドとセッターメソッドを記述することには不利な点はありますか？これは楽しみのために私の個人的なUnityコード内にあり、いかなる種類の作業環境や共有開発環境ではないと仮定します。
あなた自身の個人コードで？いいえ、そうではありません。
主な欠点は、other人があなたのコードを読んだときに、何が起こっているのかについて間違った考えを抱く可能性があることです。 _deflection = surface.Deflection_と書けば、たわみの値を見つけるのは早くて簡単だと思います。 deflection = surface.GetDeflection()と書いた場合、たわみの値を見つけるには、ファイルの読み取りや、たわみを決定するセンサーとの通信など、遅いか困難なことが関係していると思います。
言い換えると、getterとsetterを作成する通常の方法は、C＃プロパティとして書き込むことです。そのため、C＃プロパティとして作成しないと、それを行わない特別な理由があると思われるでしょう。
そしてもちろん、あなたが人生の後半でチームの一部としてC＃を書く場合、チームはおそらく「通常の」方法でゲッターとセッターを書くことを望んでいるので、今は習慣を身につけたいかもしれません。
しかし、_controller.ProcVar = aircraft.Attitude.BankAngle_よりもcontroller.SetProcVar(aircraft.GetAttitude().GetBankAngle())を読み書きしたい場合は、予期しない問題が発生することはありません。