Свойство WriteOnly или метод?
Вам необходимо добавить деталь внутри цикла в innerHTML.
let array = [11, 22, 33, 44],
result;
for (let value of array) {
results = array.indexOf(value) + ':' + value;
document.getElementById("answer").innerHTML += results + '<br>';
}<p id="answer"></p>Лучшей версией может быть сбор необходимой информации и присоединение новой строки из результатов.
let array = [11, 22, 33, 44];
document.getElementById("answer").innerHTML = array
.map((v, i) => [i, v].join(':'))
.join('<br>');<p id="answer"></p>8 ответов
Я думаю, что свойство указывает на что-то, что может быть только для чтения или чтение-запись. Поведение свойства только для записи не очевидно, таким образом, я стараюсь не создавать их.
Как пример, устанавливая список значений в выпадающем на представлении и получая доступ к выбранному пункту:
public interface IWidgetSelector
{
void SetAvailableWidgets(string[] widgets);
string SelectedWidget { get; set; }
}
Имеет больше смысла, чем:
public interface IWidgetSelector
{
string[] AvailableWidgets { set; }
string SelectedWidget { get; set; }
}
Если это имеет значение Microsoft Framework Design Guidelines (как воплощено в их инструменте FxCop) препятствует Свойствам Только для записи и отмечает их присутствие как вопросы проектирования API, из-за неинтуиции того подхода.
Просто другая мысль:
Свойство, как предполагается, чувствует и испытывает то же как поле. Нет никакого способа, которым Вы могли создать поле, которое является WriteOnly. ReadWrite возможен, ReadOnly (константа) возможен, но не WriteOnly. Несоответствие Плохо [TM]
Я соглашаюсь с Вашей догадкой: используйте методы. Как Вы видите из некоторых из этих ответов, идея свойств только для записи является видом странных. SetInternalDataProperty () намного легче понять - и в конечном счете, это - вопрос, которого подход вызовет наименьшее количество беспорядка. Я пошел бы с Вашим пищеварительным трактом.
Я сомневаюсь, что существует правильный выбор. Это - вопрос вкуса.
В обоих сценариях Вы теряете некоторую инкапсуляцию. Разработчик, использующий метод или свойство, должен знать, что что-то о внутренней реализации понимает результат. Из-за этого я избежал бы их, когда возможный и иначе используют их экономно.
Мне Свойства предлагают тесную связь члену парламента, не занимающему официального поста с возможными правилами доступа. Если бы Вы просто устанавливаете безопасного члена парламента, не занимающего официального поста, я использовал бы Свойство:
public string Password { set; }
Если бы Ваши эффекты набора несколько участников, я пошел бы с методом. Что-то как:
public void SetToRunMode(object[] runvars);
Самой важной вещью является непротиворечивость.
Однако я видел, что сам.Net Framework использует Свойства ReadOnly, первый, который приходит на ум:
System.Net.Mail.MailMessage.To
Для которого необходимо назвать метод для записи в:
System.Net.Mail.MailMessage.To.Add(Recipient As String)
Вот пример кода, который я использовал в проекте XNA. Как видите, Scale предназначен только для записи, он полезен и (достаточно) интуитивно понятен, и свойство чтения ( get ) для него не имеет смысла. Конечно, его можно заменить методом, но мне нравится синтаксис.
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