2009-06-09 2 views
15

Простой вопрос, надеюсь, простой ответ:Аксессуар с различным набором и типами?

Я хотел бы сделать следующее:

private DateTime m_internalDateTime; 
public var DateTimeProperty 
{ 
    get { return m_internalDateTime.ToString(); } // Return a string 
    set { m_internalDateTime = value; } // here value is of type DateTime 
} 

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

Возможно ли это?

--edit--

Я просто понял, что я мог бы сделать что-то вроде:

private DateTime m_internalDateTime; 
public object DateTimeProperty 
{ 
    get { return m_internalDateTime.ToString(); } // Return a string 
    set { m_internalDateTime = (DateTime)value; } // here value is of type DateTime 
} 

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

+1

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

+8

Не смей писать этот код. – mquander

ответ

8

Нет, вы, очевидно, добавить .ToString() в вызывающем коде, но вы не можете делать то, что вы предлагаете без различных имен, как это:

private DateTime m_internalDateTime; 
public DateTime SetDateTime { set { m_internalDateTime = value; } } 
public string GetDateTime { get { return m_internalDateTime.ToString(); } } 

Или, еще лучше использовать методы, вместо свойств (как указано в комментариях):

private DateTime m_internalDateTime; 
public void SetDateTime(DateTime dateTime) { m_internalDateTime = dateTime; } 
public string GetDateTime() { return m_internalDateTime.ToString(); } 

Имейте в виду, что var для неявно время компиляции набрали var iables, not dynamic переменные.

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

+9

Если вы собираетесь использовать GetDateTime и SetDateTime, они должны быть скорее методами, а не свойствами. –

+0

Могу ли я спросить, почему можно было бы использовать эти методы, а не свойства? – Nick

+8

@Nick: Поскольку методы похожи на глаголы, которые что-то делают с объектом, а свойства подобны существительным, которые говорят что-то об объекте. SetDateTime и GetDateTime - это глаголы, поэтому должны быть методы. –

5

В собственности, нет, это невозможно. Вы можете использовать методы Get и Set разных типов, но для свойства типы должны быть одинаковыми.

EDIT:

В то время как:

private DateTime m_internalDateTime; 
public object DateTimeProperty 
{ 
    get { return m_internalDateTime.ToString(); } // Return a string 
    set { m_internalDateTime = (DateTime)value; } // here value is of type DateTime 
} 

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

Лично я бы рекомендовал использовать два метода (см. Комментарий Джеффа Йетса для объяснения причин).

private DateTime m_internalDateTime; 
public string GetDateTime() 
{ 
    return m_internalDateTime.ToString(); 
} 

public void SetDateTime(DateTime dateTime) 
{ 
    m_internalDateTime = dateTime; 
} 
3

Не так, но вы можете иметь второе свойство, которое обращается к полю m_internalDateTime.

public string DateTimeString 
{ 
    get { return m_internalDateTime.ToString(); } 
} 
0

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

0

как насчет:

private DateTime intDT; 
public string DateTimeProperty 
{ 
     get { return intDT.ToString(); } // Return a string 
     set 
     { 
     DateTime dt; 
     if (DateTime.TryParse(value, out dt)) 
      intDT = dt; 
     else throw new ArgumentException(string.Format(
      "{0} cannot be converted to a DateTime.", value);   
     } 
} 
3

Возможно, что помогает

public class TDecimal 
{ 
    private decimal? m_value; 
    public bool HasValue { get { return m_value.HasValue; } } 
    public decimal Value { get { return m_value.Value; } } 

    public static implicit operator TDecimal(string a_value) 
    { 
     decimal d; 
     if (decimal.TryParse(a_value, out d)) 
     { 
      return new TDecimal() {m_value = d}; 
     } 

     return new TDecimal() {m_value = null}; 
    } 

    public static implicit operator decimal(TDecimal a_value) 
    { 
     if(a_value.HasValue) 
     { 
      return a_value.Value; 
     } 

     throw new ArgumentNullException("a_value"); 
    } 
} 

public class A 
{ 
    public TDecimal Prop { get; set; } 
} 


A a = new A(); 

a.Prop = "123"; 
if (a.Prop.HasValue) 
{ 
    decimal d = a.Prop; 
} 
Смежные вопросы