WriteOnly - свойство или метод?
Есть ли конкретный сценарий, в котором свойство WriteOnly имеет больше смысла, чем метод? Мне кажется, что методический подход более естественен.
Каков правильный подход?
Использование свойств:
Public WriteOnly Property MyProperty As String
Set(ByVal value as String)
m_myField = value
End Set
End Property
public string MyProperty
{
set{ m_myField = value;}
}
Использование методов:
Public Sub SetMyProperty(ByVal value as String)
m_myField = value
End Sub
public void SetMyProperty(string value)
{
m_myField = value;
}
РЕДАКТИРОВАТЬ Чтобы уточнить, я имею в виду свойства "WriteOnly".
Ответы 8
Я думаю, что свойство указывает на то, что может быть доступно только для чтения или для чтения / записи. Поведение свойства только для записи неочевидно, поэтому я избегаю их создания.
Например, установка списка значений в раскрывающемся списке в представлении и доступ к выбранному элементу:
public interface IWidgetSelector
{
void SetAvailableWidgets(string[] widgets);
string SelectedWidget { get; set; }
}
Имеет больше смысла, чем:
public interface IWidgetSelector
{
string[] AvailableWidgets { set; }
string SelectedWidget { get; set; }
}
Как бы то ни было, Рекомендации по проектированию Microsoft Framework (воплощенные в их инструменте FxCop) препятствуют использованию свойств только для записи и отмечают их наличие как проблему проектирования API из-за неинтуитивности такого подхода.
Я сомневаюсь, что есть правильный выбор. Дело вкуса.
В обоих сценариях вы теряете некоторую инкапсуляцию. Разработчик, использующий метод или свойство, должен кое-что знать о внутренней реализации, чтобы понять результат. Из-за этого я бы избегал их, когда это было возможно, и в противном случае использовал бы их экономно.
На мой взгляд, Properties предлагает тесную ссылку на частного члена с возможными правилами доступа. Если вы просто устанавливаете безопасного частного члена, я бы использовал свойство:
public string Password { set; }
Если ваш набор влияет на несколько участников, я бы пошел с этим методом. Что-то типа:
public void SetToRunMode(object[] runvars);
Самое главное - последовательность.
Я согласен с вашей догадкой: используйте методы. Как вы можете видеть из некоторых из этих ответов, идея свойств, предназначенных только для записи, довольно странная. SetInternalDataProperty () намного легче понять - и, в конечном итоге, вопрос в том, какой подход вызовет наименьшую путаницу. Я бы пошел с твоей интуицией.
Однако я видел, что сама .Net Framework использует свойства ReadOnly, первое, что приходит на ум:
System.Net.Mail.MailMessage.To
Для чего вам нужно вызвать метод для записи:
System.Net.Mail.MailMessage.To.Add(Recipient As String)
Еще одна мысль:
Свойство предполагается почувствовать и попробовать то же самое, что и поле. Невозможно создать поле WriteOnly. ReadWrite возможен, ReadOnly (const) возможен, но не WriteOnly. Несоответствие - это плохо [tm]
Вот пример кода, который я использовал в проекте XNA. Как видите, Масштаб предназначен только для записи, он полезен и (разумно) интуитивно понятен, и свойство чтения (получить) для него не имеет смысла. Конечно, его можно заменить методом, но мне нравится синтаксис.
public class MyGraphicalObject
{
public double ScaleX { get; set; }
public double ScaleY { get; set; }
public double ScaleZ { get; set; }
public double Scale { set { ScaleX = ScaleY = ScaleZ = value; } }
// more...
}
Согласно правилу анализа кода CA1044:
Методы доступа Get предоставляют доступ для чтения к свойству, а методы доступа set предоставляют доступ на запись.
Рекомендации по проектированию запрещают использование свойств только для записи. Это связано с тем, что разрешение пользователю установить значение, а затем запретить пользователю просматривать значение, не обеспечивает никакой безопасности. Кроме того, без доступа для чтения невозможно просмотреть состояние общих объектов, что ограничивает их полезность.
добавить к свойству метод доступа get.
В качестве альтернативы, если необходимо поведение свойства только для записи, рассмотрите возможность преобразования этого свойства в метод.
Пожалуйста, обратитесь к http://msdn.microsoft.com/en-us/library/ms182165.aspx для получения более подробной информации.