Что-нибудь хорошее / плохое / ненужное в этом использовании публичного участника?

Question

Вот краткий обзор моего кода, который представляет собой умеренно сложный графический интерфейс WinForms.

Контекстом зависимостей является шаблон представления представления модели.

public class StatSyncherFormView : Form, IView 
{ ... }

public class Presenter 
{
   // Here is the member I made public
   public readonly IView view;

   public Presenter(IView view) 
   {
      this.view = view;
   }    
}

static void Main()
{
   IView view = new View();
   Presenter presenter = new Presenter(view);

   // Here is where I'm accessing the public member
   Application.Run((Form)p.view);   
}

1) Мне нравится тот факт, что представление устанавливается только конструктором и не будет изменено после. Я чувствую себя лучше в контексте многопоточной разработки GUI.

2) С public View {get; private set;} тогда я проигрываю (неизменность?).

3) С private readonly IView view мне также нужен public View {get {return view;}}, который кажется (для меня, по крайней мере, кто-то может сказать мне иначе) излишним.

Мой вопрос: я чувствую, что (3) это единственный способ избежать использования публичного участника, но в этом случае я не понимаю выгоды.

Я понимаю, что это мелочи, поэтому заранее спасибо всем, кто нашел время, чтобы дать мне совет по этому поводу.

Answer 1

Просто дайте докладчику метод Run ().

Answer 2

Это на самом деле просто вариант в общедоступных полях против дебатов о свойствах.

Следовать стандартным рекомендациям (ваш вариант 3) - это то, что большинство людей порекомендуют, несмотря на то, что вы называете "избыточностью".Кстати, я не уверен, что из следующего вы подразумеваете под избыточностью

• несколько дополнительных символов для ввода, или

• дополнительный метод полученияво время выполнения (которое, вероятно, будет оптимизировано JITter).

Ни в том, ни в другом случае не имеет значения «избыточность».

Сказав это, в вашем конкретном случаеОтвет Ханса Пассанта, который заключается в том, чтобы вообще избежать необходимости в собственности / поле, вероятно, является лучшим.

Answer 3

Преимущества вашего третьего подхода (который мне нравится больше всего) включают в себя:

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

Answer 4

Если вы используете открытое поле, вы не сможете изменить его на свойство позже, не перекомпилировав вашу сборку.Поэтому я думаю, что лучше сделать это правильно, используя свойство.