0 
interface IDependency
{
    string Baz { get; set; }
}

class Foo
{
    IDependency dependency;

    public Foo(IDependency dependency)
    {
        this.dependency = dependency;
    }

    public void FubarBaz()
    {
        dependency.Baz = "fubar";
    }
}

これを次のように実装することもできます。

class FooStatic
{
    public static void FubarBaz(IDependency dependency)
    {
        dependency.Baz = "fubar";
    }
}

静的メソッドよりも不変オブジェクトを選択する必要があるのはいつですか？逆のことが当てはまる状況はありますか？

また、不変オブジェクトにはvoidメソッドを含めるべきではないように思われます。どう思いますか？

4

2 に答える 2

3

不変オブジェクトには確かにvoidメソッドが含まれる可能性があります。オブジェクトの状態を変更する以外にも、他の種類の副作用があります。検討：

public void WriteTo(Stream stream)

例として。

「不変オブジェクトと静的メソッド」の問題については、メソッドが実際に状態のいくつかの側面を必要とする場合はどうなりますFooか？状態が変化しないからといって、その状態を一緒にカプセル化することが意味をなさないという意味ではありません。1つではなく5つの依存関係があるとします。5つのパラメーターを受け取る静的メソッドをたくさん記述しますか？6番目の依存関係（または別の状態）を取得したときに、6番目のパラメーターをすべてのメソッドに追加する必要がありますか、それともコンストラクターだけに追加する必要がありますか？

于 2009-09-29T23:56:02.493 に答える
0

FubarBaz() はメンバーを変更するFoo.dependencyため、Foo不変ではありません。不変性は、 fields をマークすることにより、C# でより適切に表現できる設計上の制約ですreadonly。依存関係の関連付けは、コンストラクターで行うことができ、行う必要があります (IoC を実行している場合、ほとんどのフレームワークでこれが必要になります)。不変の設計は次のようになります。

class Foo
{
    private readonly IDependency dependency;

    public Foo(IDependency dependency)
    {
        this.dependency = dependency;
        dependency.Baz = "fubar";
    }
}

変更可能なクラスと不変なクラスの両方を設計するための時間と場所があります。値が頻繁に変更され、クラスが共有されていない場合は、可変クラスが機能します。不変性には、不変であるという利点があります。オブジェクトへの参照を渡すことができ、オブジェクトが指す値が変更されないことが保証されます。これは、特にマルチスレッド アプリケーションを扱う場合に強力な概念です。

静的クラスを使用するかどうかは、呼び出しをどのように表示するか、または拡張メソッドを作成する場合のように静的を使用する必要があるかどうかに基づいて決定する必要があります。IME、呼び出しを実装する前に呼び出しを書くことは、実装を配線する前に設計を決定するための優れた方法です。スタティックは基本的に非スタティックと同じですが、スタティックは「新しく作成」することはできません (ユーザーが作成します)。静的は、特に構築しないため、不変ではありません。対処するインスタンスは 1 つだけです。

不変クラス設計のメソッドで void 戻り値の型を避ける理由はわかりません。

于 2015-02-18T01:49:49.837 に答える