Projekt właściwości

Uwaga

Ta zawartość jest drukowana przez uprawnienie Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. 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. Mają one składnię wywoływania pól i elastyczność metod.

✔️ Utwórz właściwości get-only, jeśli obiekt wywołujący nie powinien mieć możliwości zmiany wartości właściwości.

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 get-only.

❌ NIE należy podawać właściwości lub właściwości tylko dla zestawu o szerszym ułatwieniu dostępu niż 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 podać metody getter właściwości, zaimplementuj funkcjonalność jako metodę. Rozważ rozpoczęcie nazwy metody i Set postępuj zgodnie z tym, co nazwałaby właściwość . Na przykład AppDomain metoda ma wywołaną SetCachePath metodę zamiast właściwości tylko dla zestawu o nazwie CachePath.

✔️ Należy podać rozsądne wartości domyślne dla wszystkich właściwości, zapewniając, że wartości domyślne nie powodują dziury zabezpieczeń ani strasznie 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 za pomocą Get polecenia lub Set.

❌ UNIKAJ indeksatorów z typami parametrów innych niż System.Int32, System.Int64, System.String, System.Objectlub wyliczenie.

Jeśli projekt wymaga innych typów parametrów, zdecydowanie przeszacuj, czy interfejs API naprawdę reprezentuje metodę dostępu do kolekcji logicznej. Jeśli tak nie jest, użyj metody . Rozważ rozpoczęcie nazwy metody za pomocą Get polecenia lub Set.

✔️ Czy użyć nazwy Item właściwości indeksowanych, chyba że istnieje oczywiście lepsza nazwa (np. zobacz Chars[] właściwość 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 niezdefault.

Jest to wymuszane przez kompilator języka C#.

Zdarzenia powiadamiania o zmianie właściwości

Czasami warto podać zdarzenie z powiadomieniem 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 jej Text właściwości.

✔️ ROZWAŻ podniesienie zdarzeń powiadamiania o zmianie, gdy wartości właściwości w interfejsach API wysokiego poziomu (zazwyczaj składniki 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.

Jest jednak mało prawdopodobne, aby narzucić obciążenie, aby podnieść takie zdarzenia dla interfejsów API niskiego poziomu, takich jak typy podstawowe lub 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Ż podniesienie zdarzeń powiadamiania o zmianie, gdy wartość właściwości zmienia się za pośrednictwem sił 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.

Reprinted by permission of Pearson Education, Inc. from Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition by Krzysztof Cwalina and Brad Abrams, published oct 22, 2008 by Addison-Wesley Professional w ramach Microsoft Windows Development Series.

Zobacz też