Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Uwaga / Notatka
Ta treść jest przedrukowana za zgodą Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2. wydanie. Wydanie to zostało opublikowane w 2008 roku, a książka została w pełni zmieniona w trzecim wydaniu. Niektóre informacje na tej stronie mogą być nieaktualne.
Chociaż właściwości są technicznie bardzo podobne do metod, są one zupełnie inne pod względem ich scenariuszy użycia. Powinny być postrzegane jako inteligentne pola. Posiadają składnię charakterystyczną dla wywoływania pól, a także elastyczność typową dla metod.
Jeśli obiekt wywołujący nie powinien mieć możliwości zmiany wartości właściwości, utwórz właściwości typu get-only.
Należy pamiętać, że jeśli typ właściwości jest modyfikowalnym typem odwołania, wartość właściwości można zmienić, nawet jeśli właściwość jest tylko do odczytu.
❌ NIE należy definiować właściwości tylko do ustawiania lub z szerszym zakresem dostępu dla settera niż dla getter.
Na przykład nie należy używać właściwości z publicznym modułem ustawiania i chronionym modułem pobierającym.
Jeśli nie można zapewnić pobieracza właściwości, zaimplementuj funkcjonalność jako metodę zamiast tego. Rozważ rozpoczęcie nazwy metody od Set, a następnie użyj nazwy, którą nadałbyś właściwości. Na przykład AppDomain ma metodę o nazwie SetCachePath zamiast właściwości tylko do ustawiania o nazwie CachePath.
✔️ Należy podać rozsądne wartości domyślne dla wszystkich właściwości, upewniając się, że wartości domyślne nie prowadzą do luk bezpieczeństwa ani do bardzo nieefektywnego kodu.
✔️ FUNKCJA DO zezwala na ustawianie właściwości w dowolnej kolejności, nawet jeśli spowoduje to tymczasowy nieprawidłowy stan obiektu.
Często zdarza się, że co najmniej dwie właściwości są powiązane z punktem, w którym niektóre wartości jednej właściwości mogą być nieprawidłowe, biorąc pod uwagę wartości innych właściwości w tym samym obiekcie. W takich przypadkach wyjątki wynikające z nieprawidłowego stanu powinny być odroczone do czasu, gdy właściwości powiązane są faktycznie używane razem przez obiekt.
✔️ Zachowaj poprzednią wartość, jeśli element ustawiania właściwości zgłasza wyjątek.
❌ UNIKAJ zgłaszania wyjątków z programów pobierających właściwości.
Metody pobierające właściwości powinny być prostymi operacjami i nie powinny mieć żadnych warunków wstępnych. Jeśli obiekt pobierający może zgłosić wyjątek, prawdopodobnie powinien zostać przeprojektowany jako metoda. Zwróć uwagę, że ta reguła nie ma zastosowania do indeksatorów, w których oczekujemy wyjątków w wyniku weryfikacji argumentów.
Projekt właściwości indeksowanej
Właściwość indeksowana to specjalna właściwość, która może mieć parametry i może być wywoływana ze specjalną składnią podobną do indeksowania tablicy.
Właściwości indeksowane są często określane jako indeksatory. Indeksatory powinny być używane tylko w interfejsach API, które zapewniają dostęp do elementów w kolekcji logicznej. Na przykład ciąg jest kolekcją znaków, a indeksator System.String został dodany w celu uzyskania dostępu do jego znaków.
✔️ ROZWAŻ użycie indeksatorów w celu zapewnienia dostępu do danych przechowywanych w tablicy wewnętrznej.
✔️ ROZWAŻ udostępnienie indeksatorów dla typów reprezentujących kolekcje elementów.
❌ UNIKAJ używania właściwości indeksowanych z więcej niż jednym parametrem.
Jeśli projekt wymaga wielu parametrów, rozważ, czy właściwość naprawdę reprezentuje metodę dostępu do kolekcji logicznej. Jeśli tak nie jest, użyj metod. Rozważ rozpoczęcie nazwy metody od Get lub Set.
❌ UNIKAJ indeksatorów z typami parametrów innych niż System.Int32, System.Int64, System.String, System.Object lub wyliczenie.
Jeśli projekt wymaga innych typów parametrów, zdecydowanie rozważ ponownie, czy interfejs API naprawdę reprezentuje dostęp do kolekcji logicznej. Jeśli tak nie jest, użyj metody. Rozważ rozpoczęcie nazwy metody od Get lub Set.
✔️ Użyj nazwy Item dla właściwości indeksowanych, chyba że oczywiście istnieje lepsza nazwa (np. właściwość Chars[] na System.String).
W języku C#indeksatory są domyślnie nazwane Element. Można IndexerNameAttribute go użyć do dostosowania tej nazwy.
❌ NIE udostępniaj zarówno indeksatora, jak i metod, które są semantycznie równoważne.
❌ NIE udostępniaj więcej niż jednej rodziny przeciążonych indeksatorów w jednym typie.
Jest to wymuszane przez kompilator języka C#.
❌ NIE UŻYWAJ właściwości indeksowanych, które nie są domyślne.
Jest to wymuszane przez kompilator języka C#.
Zdarzenia powiadamiania o zmianie właściwości
Czasami warto udostępnić zdarzenie, które powiadamia użytkownika o zmianach wartości właściwości. Na przykład System.Windows.Forms.Control zgłasza TextChanged zdarzenie po zmianie wartości jego Text właściwości.
✔️ ROZWAŻ wywołanie zdarzeń powiadamiających o zmianach, gdy wartości właściwości w interfejsach API wysokiego poziomu (zwykle składnikach projektanta) są modyfikowane.
Jeśli istnieje dobry scenariusz, aby użytkownik wiedział, kiedy zmienia się właściwość obiektu, obiekt powinien zgłosić zdarzenie powiadomienia o zmianie właściwości.
Jednak mało prawdopodobne jest, aby było warte dodatkowego obciążenia generowanie takich zdarzeń dla niskopoziomowych interfejsów API, takich jak typy podstawowe czy kolekcje. Na przykład List<T> nie zgłasza takich zdarzeń po dodaniu nowego elementu do listy i Count zmianie właściwości.
✔️ ROZWAŻ wygenerowanie zdarzeń powiadamiających o zmianie, gdy wartość właściwości zmienia się za pośrednictwem czynników zewnętrznych.
Jeśli wartość właściwości zmienia się za pośrednictwem jakiejś siły zewnętrznej (w inny sposób niż wywoływanie metod w obiekcie), zgłaszaj zdarzenia wskazujące deweloperowi, że wartość zmienia się i została zmieniona. Dobrym przykładem jest Text właściwość kontrolki pola tekstowego. Gdy użytkownik wpisze tekst w obiekcie TextBox, wartość właściwości automatycznie się zmienia.
© Części 2005, 2009 Microsoft Corporation. Wszelkie prawa zastrzeżone.
Przedrukowane za zgodą Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition przez Krzysztofa Cwalinę i Brada Abramsa, opublikowane 22 października 2008 przez Addison-Wesley Professional w ramach serii Microsoft Windows Development.