В чем преимущества неизменяемых объектов над статическими методами?

Question

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"; 
    } 
} 

Когда я должен выбрать неизменные объекты более статические методы? Есть ли ситуации, когда обратное может быть правдой?

Кроме того, мне кажется, что неизменяемые объекты не должны иметь недействительные методы. Как вы думаете?

Answer 1

Неизменяемые объекты, безусловно, могут иметь недействительные методы - существуют другие виды побочных эффектов, помимо изменения состояния объекта. Рассмотрим:

public void WriteTo(Stream stream) 

в качестве примера.

Что касается ваших проблем «неизменяемых объектов и статических методов» - что делать, если ваш метод действительно нуждается в нескольких аспектах состояния Foo? Просто потому, что состояние не изменяется, это не означает, что не имеет смысла инкапсулировать это состояние вместе. Предположим, что у него есть 5 зависимостей вместо одного - вы хотите написать много статических методов, которые принимают 5 параметров? Когда вы получаете шестую зависимость (или даже просто другое состояние), действительно ли вы хотите добавить шестой параметр ко всем методам или просто к конструктору?

Answer 2

FubarBaz() мутирует элемент Foo.dependency поэтому Foo не является неизменным. Неизменность - это конструктивное ограничение, которое может и должно быть лучше выражено в C# путем маркировки полей readonly. Связывание вашей зависимости может и должно выполняться в конструкторе (если вы делаете IoC, большинство фреймворков потребует этого). Неизменная конструкция может в конечном итоге, как это:

class Foo 
{ 
    private readonly IDependency dependency; 

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

Существует время и место для обоих изменяемых и неизменяемых конструкций класса. Возможно, значение часто меняется, а класс не разделяется, тогда работает изменяемый класс. Преимущество неизменности заключается в том, что он является инвариантным. Вы можете передать ссылку на объект вокруг и быть уверенным, что значение, которое оно указывает, никогда не изменяется. Это мощная концепция, особенно при работе с многопоточными приложениями.

Решение использовать статический класс должно основываться на том, как вы хотите, чтобы вызовы выглядели или вам абсолютно необходимо использовать статику, например, при создании методов расширения. IME, написание вызова перед выполнением вызова - отличный способ принять решение о дизайне перед подключением к реализации. Статика в основном такая же, как и нестатика, за исключением того, что статика не может быть «новой» (построенной вами). Статика не является неизменной, особенно потому, что вы их не строите. У вас только один экземпляр.

Я не вижу причин избегать типов возвращаемых ошибок при использовании методов в неизменном классе.