Dzisiaj w pracy jeden z moich kolegów przejrzał mój kod i zasugerował, żebym usunął właściwość tylko do zestawu i zamiast tego użyłem metody.
Ponieważ oboje byliśmy zajęci innymi rzeczami, powiedział mi, abym przejrzał Property Design
sekcję z książki „Wytyczne projektowania ramowego”. W książce pisarz powiedział właśnie, aby unikać:
Właściwości, w których seter ma szerszą dostępność niż getter
A teraz zastanawiam się, dlaczego nie zaleca się posiadania właściwości tylko do ustawiania? Czy ktoś może mi wyjaśnić?
design
code-quality
code-reviews
code-smell
Prashant Cholachagudda
źródło
źródło
Password
własność wUser
klasie. Możesz to ustawić, ale nie możesz tego zdobyć. Możesz wtedy miećHashedPassword
właściwość tylko do odczytu . Wywołanie zestawu spowoduje wykonanie skrótu i zmianęHashedPassword
właściwości. Nie krzyczałbym na ciebie, gdybyś to zrobił.Odpowiedzi:
Myślę, że może to mieć związek z oczekiwaniami. Właściwości tylko zestawu są rzadkie, a właściwości są zwykle używane w „głupich” zestawach tylko do przechowywania wartości bez większego przetwarzania. Jeśli wykonujesz dużo pracy w seterach, lepiej jest użyć metody - ludzie oczekują, że metody mogą potrwać długo i mogą mieć skutki uboczne. Implementacja podobnego rodzaju zachowania we właściwości może spowodować, że kod narusza oczekiwania.
Oto odpowiednia sekcja Wytycznych użytkowania nieruchomości Microsoft :
źródło
Ponieważ w większości przypadków nie ma to po prostu sensu. Jaką możesz mieć właściwość, którą możesz ustawić, ale nie możesz odczytać?
Jeśli OO ma lepiej reprezentować rzeczywisty świat, właściwość tylko zestaw może sugerować, że twoje modelowanie jest całkiem niezłe.
Edycja : Zobacz także: /programming/4564928/are-set-only-properties-bad-practice, który zasadniczo mówi, że jest nieintuicyjny, a właściwość only set jest w zasadzie metodą o innej nazwie, więc powinieneś użyć metoda.
źródło
Foo Foo { private get; set; }
? Nie nazwałbym tego tylkoCóż, wyobrażam sobie, że jeśli możesz ustawić właściwość na czymś, ale nigdy jej nie uzyskasz, nigdy nie dowiesz się, czy coś innego zmieni / nadpisze ustawioną wartość. Może to stanowić problem, jeśli polegasz na ustawionej wartości i nie jesteś w stanie (z jakiegoś powodu) utrzymać jej do czasu, w którym chcesz ją uzyskać.
Użycie metody zamiast właściwości tylko dla zestawu będzie nieco mniej mylące dla użytkownika. Nazwa metody zwykle wskazuje SEt- lub korzystać z telefonu , ale nazwy właściwości zwykle nie wskazują, że coś może tylko być ustawiony i nie można zdobyć. Podejrzewam, że gdyby właściwość była podobna do „ReadOnlyBackgroundColour”, nie byłoby to mylące dla innych programistów, ale wyglądałoby to dziwnie.
źródło
Jest to bardzo stary temat, który jednak pojawił się w mojej opinii na tym późnym etapie i chciałbym skomentować, gdy próbuję uzasadnić właściwości tylko do zapisu ...
Mam zestaw
ActiveReport
klas, które są częścią strony internetowej, które są tworzone i uruchamiane w trybie postback po kilku wyborach użytkowników.Kod VB wygląda mniej więcej tak:
Te raporty używają ogólnych odwzorowań,
CommonReader
biorą procedurę składowaną i tablicę domyślnychSqlParameter
s, z których każdy ma powiązaną właściwość WriteOnly, która w zależności od projektu raportu może zostać przekazana jako parametr podczas tworzenia instancji lub ustawiona przez użytkownika po utworzeniu instancji przed wywołanieRun
metody raportów .Tak więc, jak widzę, w tym przypadku ma właściwość tylko do zapisu
SqlParameter
s są rodzajoweSqlParameter
s są klasami, a nie pierwotnymi wartościami, WriteOnly Properties pozwala na prostszy interfejs do ustawiania parametrówWięc to są moje myśli.
Czy zamiast tego mogę przekonwertować go na metodę? jasne, ale interfejs wydaje się ... mniej przyjemny
przeciw
źródło