Czego byście użyli w poniższym przypadku: właściwości czy metody? Czy string.Split i int.Parse można traktować jako computationally complex?
class X
{
public string Numbers { get; set; } // 1,2,3
public IEnumerable<int> NumbersParsed => Numbers.Split(',').Select(int.Parse).ToList();
// vs
public IEnumerable<int> ParseNumbers()
{
return Numbers.Split(',').Select(int.Parse).ToList();
}
}
Ja bym nie łączył wyboru w/s właściwości z dylematami wydajnościowymi.
Wyboru w/s właściwości się dokonuje ze względów "wyższych", projektowych, a jak trzeba wesprzeć wydajność to można np cachowac na polach private
edytka: zwrócę ci uwagę, że w przykładzie uzywazsz tylko najprostszego napisu właściwości
@AnyKtokolwiek: Microsoft pisze, że powinno użyć się metody, jeśli:
The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
No ale faktycznie klasa udostępniająca właściwość może cache'ować jej wartość, a nie klient tej klasy.
Wiem, że to trywialny przykład, ale co jakby pod spodem właściwości była jakaś deserializacja jsona? To już jest bardziej złożone. JSON może być spory. Uzależniać wybór właściwość vs metoda od rozmiaru JSONa tak trochę głupio. To już faktycznie cache lepszy.
Przecież właściwość tak naprawdę pod spodem generuje dodatkowe metody (setter i getter, jak masz get i set), więc tak naprawdę na jedno wychodzi.
Zaimplementujesz to:
public string Numbers { get; set; }
Kompilator wygeneruje coś takiego:
private string Numbers;
public void SetNumbers(string Val)
{
Numbers = Val;
}
public string GetNumbers()
{
return Numbers;
}
Innymi słowy, właściwość, to inny zapis getterów i setterów (albo tylko jednego z nich). Ja bym nie spodziewał się istotnego wpływu na wydajność.
Już prędzej można rozważać różnicę między publicznym polem a właściwością, jednak różnica będzie minimalna (trudno zgadywać jaka bez testów wydajnościowych).
@andrzejlisek: chodzi o intencję. Użytkownik raczej nie odpali w pętli metody, ale właściwość już tak :P
foreach (var anotherNumber in anotherNumbers)
{
if (x.ParsedNumbers.Contains(anotherNumber )) { ... }
}
vs
var parsedNumbers = x.ParseNumbers();
foreach (var anotherNumber in anotherNumbers)
{
if (parsedNumbers.Contains(anotherNumber )) { ... }
}
nobody01 napisał(a):
@andrzejlisek: chodzi o intencję.
Jeżeli to ja miałbym decydować, to zrobiłbym tak:
class X
{
public string Numbers;
public IEnumerable<int> ParseNumbers()
{
return Numbers.Split(',').Select(int.Parse).ToList();
}
}
Skoro pobieraniu lub zapisywaniu wartości pola Numbers nie towarzyszą dodatkowe działania, to po co getter i setter? Co do metody, to ja nie mam doświadczenia w wyrażeniach lambda, więc proponowana przeze mnie wersja wydaje mi się być bardziej czytelna i klarowna.
To jest tylko moje zdanie, z którym inny programista ma prawo sę nie zgodzić.
a po co ten string w ogóle?
niech klasa będzie dostępne tylko i wyłącznie przez builder, który przygotuje dane, a klasa będzie już miała poprawnie obrobione dane.
No skoro te wartości są cechą tego obiektu, to raczej właściwość.
W tym przypadku właściwość nie wygląda dobrze i nie przyczynia się do czytelności kodu to po raz.
Po dwa, wykonujesz już pewną konkretną operację związaną z zamianą danych, teorytycznie można by to zrobić też na właściwości.
Te wartości, jak wspomniał @somekind są cechą obiektu więc właściwość też wchodzi w grę, jak już wspomniałem.
Żeby się nie rozpisywać, uważam że masz do wyboru: klient ma cachować, czy twoja klasa?
z tego co widzę posiadasz klasę która przechowuje pole Numbers czyli przechowujesz tam liczby, następnie chciałbyś je przekonwertować,
ja mam taką zasadę że jak w właściwości zachodzi więcej operacji (też zależy od kontekstu, ale w twoim przypadku wychodzi na jedno i to samo) to po prostu robię metodę.
Więc masz do rozważenia:
klient ma cachować, czy twoja klasa?
Tego za ciebie nie zrobię :D