2009-06-09 17 views
15

Proste pytanie, mam nadzieję, że to prosta odpowiedź:Accessor z różnymi ustawieniami i typami get?

Chciałbym wykonaj następujące czynności:

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 
} 

Powyższe to tylko przykład tego, co próbuję zrobić. Chciałbym mieć publicznego dostępu do zmiennej wewnętrznej typu x. Chcę uzyskać tę zmienną jako ciąg znaków, ale ustaw ją za pomocą typu x.

Czy to możliwe?

--edit--

właśnie sprawę, że mogę zrobić coś takiego:

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 
} 

Ale potem, powiedzmy używam typu Y zamiast „string” jako mój „dostać” typ . Jeśli chcę użyć "DateTimeProperty", gdzie w moim kodzie, będę musiał go rzucić.

+1

Gorąco zachęcam nie używać kodu w swojej zmiany. Poza dziwnym zerwaniem z konwencją może to mieć niewielkie problemy z wydajnością i poważnymi problemami z lokalizacją. –

+8

Nie waż się pisać tego kodu. – mquander

Odpowiedz

8

nr Można oczywiście dodać .ToString() w kodzie dzwoni, ale nie można robić to, co proponują bez różnymi nazwami tak:

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

Albo, jeszcze lepiej metody używania zamiast właściwości (jak zauważono w komentarzach):

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

pamiętać, że var jest niejawnie, kompilacji wpisane Zmienne, nie zmienne dynamiczne.

Zdecydowanie do not rób to, co zauważyłeś w swojej edycji. Wprowadzono przerwę w konwencji, możliwe skutki wydajności (choć niewielkie) i znaczące problemy z lokalizacją.

+9

Jeśli zamierzasz używać GetDateTime i SetDateTime, powinny to być raczej metody niż właściwości. –

+0

Czy mogę zapytać, dlaczego można by zrobić te metody, a nie właściwości? – Nick

+8

@Nick: Ponieważ metody są jak czasowniki, które robią coś dla obiektu, a właściwości są jak rzeczowniki, które mówią coś o obiekcie. SetDateTime i GetDateTime są czasownikami, dlatego powinny być metodami. –

5

Jako własność, nie jest to niemożliwe. Można tworzyć różne metody pobierania i ustawiania, ale w przypadku właściwości typy muszą być takie same.

EDIT:

Podczas:

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 
} 

jest składniowo poprawny, zostanie skompilowany i pozwala przyjąć DateTime jako wejście i zwraca ciąg znaków, to nie byłby dobry plan. Działa, ale sprawia, że ​​ty i każdy użytkownik uzyskujący dostęp do tego kodu, wykonujesz niepotrzebne sprawdzanie poprawności. Ponadto jest on podatny na innĘ ... deweloper w przyszłoś ci, nie wiedzĘ ... c, ani nie realizujĘ ... c niejawnych reguł, dla których utraciliś my czas kompilacji. Ponadto, prawie żaden kod nie tworzy dwóch właściwości lub dwóch metod, które osiągają ten sam cel, w sposób mocno napisany.

Osobiście polecam używanie dwóch metod (patrz komentarz Jeff Yates, aby uzyskać dobre wyjaśnienie, dlaczego).

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

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

Nie w ten sposób, ale na pewno można mieć drugą właściwość, która uzyskuje dostęp do pola m_internalDateTime.

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

Prosta odpowiedź nie, do Twojego kodu zewnętrznego Twoja własność będzie zachowywać się dokładnie tak, jak to zrobi pole, nie możesz mieć własności o różnych typach zestaw/odbiór, tak jak nie można ustawić pliku za pomocą wpisz i kiedy zażądasz jego wartości, otrzymasz inny typ z powrotem.

0

jak about:

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

Może to pomaga

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; 
} 
Powiązane problemy