Logika w celu uzyskania części własności. Dobra praktyka?

Question

W przypadku datowania mojego pliku xaml na niektóre dane często używam części "get" dla właściwości, aby wykonać jakąś logikę. Np. Podając sumę sumy na liście lub czeku, jeśli coś jest pozytywne.

Na przykład

public List<SomeClass> ListOfSomeClass{get;set;} 

public double SumOfSomeClass 
{ 
    get 
    { 
    return ListOfSomeClass.Sum(s => s.Totals); 
    } 
} 

public bool SumPositive 
{ 
    get 
    { 
    if(SumOfSomeClass >= 0) 
     return true; 
    else 
     return false; 
    } 
} 

ten sposób można wiązać SumPositive i SumOfSomeClass. Czy jest to uważane za dobrą praktykę? Nawet jeśli jest bardziej skomplikowany niż to? A może lepiej byłoby zastosować metodę i zwrócić wynik? A co z połączeniami z inną klasą, a nawet z bazą danych?

Answer 1

Przywoływacze właściwości powinny być szybkie i idempotentne (tzn. Nie powinny być tam wykonywane działania destrukcyjne). Mimo że idealnie nadaje się do iteracji nad kolekcją przedmiotów w pamięci, nie poleciłbym żadnego rodzaju podnoszenia ciężkich elementów w uzyskać lub zestaw części. Mówiąc o iteracji, nadal buforowałbym wynik, aby zaoszczędzić kilka milisekund.

Answer 2

Mówię tak, ale staram się przechowywać na prywatnej zmiennej de wyniki ListOfSomeClass.Sum (s => s.Totals). Szczególnie jeśli używasz go więcej niż raz.

Answer 3

Posiadanie złożonej logiki w programach pobierających/ustawiających nie jest dobrą praktyką. Polecam przenieść złożoną logikę do oddzielnych metod (takich jak GetSumOfXYZ()) i użyć memoization w akcesoriach do właściwości.

Możesz uniknąć złożonych właściwości, używając ObjectDataProvider - pozwala to zdefiniować metodę pobierania niektórych danych.

Answer 4

Nie widzę żadnego bezpośredniego problemu (chyba że lista jest dość duża), ale osobiście skorzystam z metody myInstance.SomeList.Sum(), jeśli to możliwe (.net> = 2.0).

Answer 5

Do podstawowych obliczeń off pól lub innych właściwości w kolekcji byłoby dopuszczalne do zrobienia, że ​​wewnątrz własność dostać. Jak wszyscy inni mówili, prawdziwa logika nigdy nie powinna być zrobiona w getterze.

Answer 6

Zależy ... jeśli to było na podmiot domeny wtedy nie byłoby na korzyść posiadające złożoną logikę w getter a zwłaszcza nie seter. Używanie metody (do mnie) sygnalizuje konsumentowi istota, że ​​operacja jest wykonywana, podczas gdy pobierający sygnalizuje proste pobieranie.

Teraz, jeśli ta logika była w ViewModel, to myślę, że aspekt getter jest trochę bardziej wybaczalne/oczekiwano.

Answer 7

Myślę, że istnieje pewien poziom logiki, który jest oczekiwany w pobierające i ustawiające metody, w przeciwnym razie po prostu rodzaj pokrętny sposób deklarowania członkowie publicznego.

Answer 8

Tak, chyba że jest to operacja, która może mieć wpływ na wydajność. W takim przypadku należy użyć metody zamiast (jak to jest bardziej intuicyjna dla użytkownika końcowego, że metoda może być powolny podczas gdy nieruchomość będzie szybka)

Answer 9

Proszę zmienić tę getter do tego:

public bool SumPositive 
{ 
    get 
    { 
    return SumOfSomeClass >= 0; 
    } 
} 

Używasz już wyrażenia boolowskiego, nie musisz jawnie zwracać wartości true lub false.

Answer 10

Podobają mi się twoje konwencje nazewnictwa i całkowicie zgadzam się z użyciem treści, takich jak twój przykład w getloadach właściwości, jeśli dostarczasz API do użycia z wiązaniem.

Nie zgadzam się z punktem, który inni poczynili na temat przeniesienia kodu do metody tylko dlatego, że jest on ciężki pod względem obliczeniowym - to nie jest rozróżnienie, które kiedykolwiek popełniłem, ani nie słyszałem, aby inne osoby sugerowały, że bycie w metodzie implikuje wolniej niż własność.

Uważam, że właściwości powinny być wolne od skutków ubocznych na obiekt, na który są nazywane. Znacznie trudniej jest zagwarantować, że nie mają one wpływu na szersze środowisko - nawet względnie banalna właściwość może pobierać dane do pamięci lub przynajmniej zmieniać pamięć podręczną procesora lub stan vm.

Answer 11

Byłbym ostrożny, umieszczając dowolną logikę w Getterach nieruchomości. Im jest droższy, tym bardziej niebezpieczny. Inni programiści oczekują od gettera, aby natychmiast zwrócił wartość, tak jak pobiera wartość ze zmiennej członkowskiej. Widziałem wiele przypadków, w których programista używa właściwości w każdej iteracji pętli, myśląc, że po prostu zwracają wartość, podczas gdy właściwość faktycznie wykonuje dużo pracy. Może to być poważnym spowolnieniem wykonywania kodu.