8

サンプルコード（代替コードは以下）、

// person.cs
using System;
class Person
{
    private string myName ="N/A";

    // Declare a Name property of type string:
    public string Name
    {
        get 
        {
           return myName; 
        }
        set 
        {
           myName = value; 
        }
    }
    public override string ToString()
    {
        return "Name = " + Name;
    }

    public static void Main()
    {
        Person person = new Person();
        Console.WriteLine("Person details - {0}", person);
        person.Name = "Joe";
        Console.WriteLine("Person details - {0}", person);

    }
}

myNameプライベートからパブリックに変更して、別のパブリック変数 Name を宣言する必要がなく、get と set を使用する必要がないので、直接書くことはできませんか?

代替コード

    // person.cs
    using System;
    class Person
    {

        public string myName ="N/A";

        public override string ToString()
        {
            return "Name = " + myName;
        }

        public static void Main()
        {
            Person person = new Person();
            Console.WriteLine("Person details - {0}", person);
            person.myName = "Joe";
            Console.WriteLine("Person details - {0}", person);

        }
    }
4

6 に答える 6

17

次の理由により、外部から見えるプロパティはフィールドよりも優れています。

  • プロパティにより、より優れたカプセル化が可能になります。フィールドは固定実装であり、消費者から直接アクセスできます。プロパティ：

    • 疎結合 (基になるフィールドが変数からデータベースにいつでも変更できるため)

    • カスタム ロジックを許可する (検証、イベント通知、遅延読み込みなど)

    • アクセスを制御します (ロジックは get/set で構築できるため、読み取り専用または書き込み専用と宣言されていても)。

  • インターフェイスではフィールドを使用できません。これは、テスト駆動開発 (インターフェース優先) の障害になります。

  • 自動または自動実装されたプロパティは、フィールドと同じくらい簡単に宣言でき、フィールドと同等のパフォーマンスを発揮するように最適化されています。ここを参照してください。

  • 外部から見えるフィールド (public、protected、protected internal) を宣言することは、FxCop 違反です。規則 CA1051を参照してください。

  • 呼び出し元のコードを再コンパイルする必要があるため、フィールドをプロパティに変更すると破壊的変更になります (バイナリ シリアル化にも適用されます)。

  • プロパティは、XML シリアル化、WPF バインディング、ASP.NET 双方向バインディングなどのタスクのために .NET の多くのライブラリで認識され、Visual Studio デザイナーでも認識されます。

于 2013-06-19T08:37:27.347 に答える
10

あなたはOOPの基盤の1つをクラックしています->情報の隠蔽/カプセル化

プロパティを public として定義することにより、すべての人にそれらへのアクセスを許可し、必要に応じて変更 (破損) することができます。この方法では、オブジェクトが常に一貫した状態になると約束することはできません。

ウィキペディアより

プログラミング言語では、カプセル化は 2 つの関連するが異なる概念の 1 つを参照するために使用され、場合によってはそれらの組み合わせ [1][2] を参照し
ます。 - オブジェクトのコンポーネントの一部へのアクセスを制限するための言語メカニズム。 ]
- そのデータで動作するメソッド (または他の関数) とデータのバンドルを容易にする言語構造。[5][6]

一部のプログラミング言語の研究者や学者は、オブジェクト指向プログラミングの際立った機能として、最初の意味を単独で、または2番目の意味と組み合わせて使用​​しますが、字句閉鎖を提供する他のプログラミング言語は、カプセル化をオブジェクト指向に直交する言語の機能と見なします。

2 番目の定義は、多くの OOP 言語では、コンポーネントの非表示が自動的に行われないか、オーバーライドできるという事実に基づいています。したがって、情報隠蔽は、2 番目の定義を好む人によって別の概念として定義されます。

于 2013-06-19T08:32:08.113 に答える
0

OOP では、すべての変数をユーザーから隠し、代わりに Getter と Setter を使用して操作するという慣習があります。保存するまで変数の値を変更する必要がある場合があります。たとえば、ユーザーに速度となる値を入力するように求め、ユーザーはその値を MPH で入力しますが、それらを変換して Km/h または m/s として保存したいとします。この場合、セッターを持つことは理にかなっています。変数を読み取り専用または書き込み専用にするために、セッターまたはゲッターをプライベートにしたい場合もあります。しかし、OOP規約で要約すると、パブリック変数の代わりにセッターとゲッターを使用することです。これはカプセル化の概念の一部です

于 2013-06-19T08:36:40.920 に答える
0

できますが、それは良い方法ではありません。プライベート変数をプロパティとしてカプセル化することは、クライアントができることとできないことをより細かく制御できることを意味します

少し冗長に思える場合は、次を使用することもできます

public string Name { get; set; }
于 2013-06-19T08:36:41.643 に答える