«Свойства прокси» хорошего стиля?

Question

У меня есть класс со строковым свойством, на самом деле это несколько строк, соединенных с разделителем.

мне интересно, если это хорошая форма, чтобы иметь прокси свойство как это:

public string ActualProperty 
{ 
    get { return actualProperty; } 
    set { actualProperty = value; } 
} 

public string[] IndividualStrings 
{ 
    get { return ActualProperty.Split(.....); } 
    set 
    { 
      // join strings from array in propval .... ; 
      ActualProperty = propval; 
    } 
} 

Есть ли какие-либо риски, я упускать из виду?

Answer 1

Ну, я бы сказал, что ваш «набор» - это высокий риск, что, если кто-то не знал, что должен был пройти уже присоединенную последовательность значений или ваш пример выше, возможно, отсутствовал. Что, если строка уже содержит разделитель, вы сломаетесь.

Я уверен, что производительность не велика в зависимости от того, как часто это свойство используется.

Answer 2

Определите «хорошо». Он не должен прерываться (если вы не смогли должным образом гарантировать, что разделитель (ы), переданный на Split(), никогда не разрешены в отдельных строках), но если доступ к IndividualStrings чаще, чем ActualProperty, вы в конечном итоге разбираете actualProperty гораздо чаще чем вам. Конечно, если обратное верно, то у вас все хорошо ... и если оба вызываются так часто, что любой ненужный синтаксический анализ или конкатенация неприемлемы, то просто сохраняйте оба и повторно разбирайте, когда изменяется значение.

Answer 3

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

Как минимум, я удалил установщик в свойстве IndividualStrings или переместил его на два метода: string [] SplitActualProperty() и void MergeToActualProperty (строка []).

Answer 4

Связывание двух устанавливаемых свойств вместе является плохим juju, на мой взгляд. Переключитесь на использование явных методов get/set вместо свойства, если это действительно то, что вы хотите. Код, который имеет неочевидные побочные эффекты, почти всегда укусит вас позже. Держите вещи простыми и понятными в максимально возможной степени.

Кроме того, если у вас есть свойство, которое является форматированной строкой, содержащей подстроки, похоже, что вы действительно хотите, это отдельный struct/class для этого свойства, а не злоупотреблять примитивным типом.

Answer 5

Кажется, что массив - это реальные данные, а однострочный материал - удобство. Все в порядке, но я бы сказал, что ищут такие вещи, как сериализация и клонирование последовательности, которые получат и зададут оба свойства записи.

Я думаю, что хотел;

• сохранить массив как свойство
• обеспечить способ GetJoinedString(string seperator).
• обеспечивают метод или Parse(string joined, string seperator).

Реалистично, сепаратор в строках не является частью класса, а является эфемерной деталью. Сделать ссылки на него явными, так что, скажем, приложение CSV может передавать запятую, где приложение с разделителями табуляции может передавать вкладку. Это упростит ваше приложение. Кроме того, он устраняет эту неприятную проблему наличия двух геттеров и сеттеров для одних и тех же фактических данных.

Answer 6

Свойства предназначены для очень простых членов класса; получение или установка значения свойства следует считать тривиальной операцией без значительных побочных эффектов.

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

«Комплексное» имущество опасно, потому что оно ломается от ожиданий абонентов. Свойства интерпретируются как поля (с побочными эффектами), но как поля, которые вы ожидаете иметь возможность назначить значение, а затем получить это значение позже. Таким образом, вызывающий должен ожидать, что сможет назначить несколько свойств и снова получить их значения позже.

В вашем примере я не могу присвоить значения обоим свойствам и получить их; одно значение повлияет на другое. Это нарушает фундаментальное ожидание свойства. Если вы создадите метод одновременного присвоения значений обоим свойствам и сделаете оба свойства только для чтения, становится намного легче понять, где установлены значения.

Кроме того, как в сторону:

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

Например:

YourClass i = new YourClass(); 
i.IndividualStrings[0] = "Hello temporary array!"; 

Этот код выглядит как это изменение значения в IndividualStrings собственности, но на самом деле массив создается собственности и не назначен везде, поэтому массив и изменения будут падать вне сферы действия сразу.

public string ActualProperty { get; set; } 

public string[] GetIndividualStrings() 
{ 
    return ActualProperty.Split(.....); 
} 

public void SetFromIndividualStrings(string[] values) 
{ 
    // join strings from array .... ; 
}