1

私は次のクラス：

    public class Humptydump
    {
        public Humptydump()
        { }

        public Rectangle Rectangle { public get; private set; }

    }

このクラスでは、Rectangle クラスは system.drawing から
取得されます。ユーザーが四角形のメソッドにアクセスできず、四角形自体を取得できるようにするにはどうすればよいですか?

4

3 に答える 3

3

あなたの場合、それは「うまくいく」でしょう。

Rectangleは であるため、プロパティは のコピーをstruct返します。そのため、これを許可するメソッドを公開しない限り、だれも直接変更することはできません。RectangleRectangle

そうは言っても、一般に、型で定義されたメソッドへのアクセスを提供せずに型へのアクセスを提供することは不可能です。メソッドは型に沿っています。このような場合の唯一の代替手段は、公開したいデータやメソッドなしで選択したデータを公開する新しい型を作成し、それへのアクセスを提供することです。

于 2013-06-12T15:55:55.067 に答える
0

オブジェクトについて具体的に話しているのでしょうかRectangle、それともより一般的な用語で、それを例として使用しているだけですか?

より一般的な用語で話している場合、これはリファクタリング パターンで非常に頻繁に出てくるものです。これは、オブジェクトのコレクションで最も一般的に発生します。たとえば、公開すると、セッターがプライベートであっても、実際にコレクションを設定List<T>していないため、ゲッターを介してコレクションを変更できます。

これに対処するには、デメテルの法則を検討してください。つまり、誰かがオブジェクトによって公開されたコレクションと対話している場合、その人は本当にオブジェクト自体と対話しているべきでしょうか? その場合、コレクションを公開するのではなく、オブジェクトが必要とする機能を公開する必要があります。

したがって、再びコレクションの場合、次のような結果になる可能性があります。

class SomeObject
{
    private List<AnotherObject> Things;

    public void AddAnotherObject(AnotherObject obj)
    {
        // Add it to the list
    }

    public void RemoveAnotherObject(AnotherObject obj)
    {
        // Remove it from the list
    }
}

もちろん、オブジェクト自体のコピーを公開して、ユーザーが読み取れるようにすることもできますが、変更はできません。コレクションの場合、次のようなことができます。

public IEnumerable<AnotherObject> TheObjects
{
    get { return Things; }
}

そうすれば、誰でもオブジェクトの現在の状態を確認して列挙できますが、実際に変更することはできません。セッターがないからではなく、IEnumerable<T>インターフェースに列挙を変更するオプションがないからです。それを列挙するだけです。

あなたの場合Rectangle（または、とにかく値渡しされた構造体ではない類似のもの）の場合、非常に似たようなことをします。プライベート オブジェクトを格納し、クラス自体を介してそれを変更するためのパブリック機能を提供します (これは、メンバーがいつ変更されたかをクラスが知る必要があるためです) だけでなく、内容を変更することなくオブジェクトを検査する機能も提供します。検査した。おそらく、次のようなものです。

class SomeObject
{
    private AnotherObject Thing;

    public AnotherObject TheThing
    {
        get { return Thing.Copy(); }
    }

    public void RenameThing(string name)
    {
        Thing.Name = name;
    }

    // etc.
}

この場合、何が何であるかについてあまり詳しく説明せずにAnotherObject(したがって、これはある意味で疑似コードと考えてください)、内部オブジェクトを検査するプロパティは、実際のオブジェクトへの実際の参照ではなく、そのコピーを返します。値型の場合、これは言語の既定の動作です。参照型の場合、これとパフォーマンスのバランスをとる必要がある場合があります (コピーの作成が負荷の高い操作の場合)。

この場合、オブジェクトのインターフェイスが直感的でないものにならないように注意する必要があります。消費コードは、それ自体を変更する機能を公開しているため、検査中の内部オブジェクトを変更できることを期待する場合があります。そして、確かに、彼らはできる彼らが持っているコピーを変更します。これにどのように対処するかは、オブジェクトの概念的な性質と、それらが互いにどのように関係しているかに大きく依存します。これは、不自然な例では実際には伝わりません。内部オブジェクトの監視可能なプロパティのみを返すカスタム DTO (構造体であっても) を作成して、オリジナルではなくコピーであることをより明確にすることができます。インテリセンスのコメントのコピーだと言うだけかもしれません。オブジェクト自体を返す単一のプロパティではなく、内部オブジェクトの個々のデータ要素を返す個別のプロパティを作成する場合があります。たくさんのオプションがあります。あなたのオブジェクトにとって最も意味のあるものを決定するのはあなた次第です。

于 2013-06-12T16:09:39.550 に答える