Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
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ż większość interfejsów API najlepiej modeluje się przy użyciu klas i struktur, istnieją przypadki, w których interfejsy są bardziej odpowiednie lub są jedyną opcją.
CLR nie obsługuje wielokrotnego dziedziczenia (tj. klasy CLR nie mogą dziedziczyć z więcej niż jednej klasy bazowej), ale zezwala typom na implementowanie jednego lub więcej interfejsów oprócz dziedziczenia z klasy bazowej. W związku z tym interfejsy są często używane do osiągnięcia efektu wielokrotnego dziedziczenia. Na przykład IDisposable jest interfejsem, który umożliwia typom obsługę usuwalności niezależnie od każdej innej hierarchii dziedziczenia, w której chcą uczestniczyć.
Inną sytuacją, w której zdefiniowanie interfejsu jest właściwe, jest utworzenie wspólnego interfejsu, który może być obsługiwany przez kilka typów, w tym niektóre typy wartości. Typy wartości nie mogą dziedziczyć z typów innych niż ValueType, ale mogą implementować interfejsy, więc użycie interfejsu jest jedyną opcją w celu zapewnienia wspólnego typu podstawowego.
Zdefiniuj interfejs, jeśli potrzebujesz wspólnego interfejsu API, aby był obsługiwany przez zestaw typów, w tym typy wartości.
✔️ ROZWAŻ zdefiniowanie interfejsu, jeśli musisz zapewnić jego funkcjonalność dla typów, które już dziedziczą od innego typu.
❌ UNIKAJ używania interfejsów znaczników (interfejsów bez elementów).
Jeśli musisz oznaczyć klasę jako posiadającą określoną cechę (znacznik), zazwyczaj użyj atrybutu niestandardowego, a nie interfejsu.
✔️ Zapewnij co najmniej jeden typ, który jest implementacją interfejsu.
Dzięki temu można zweryfikować projekt interfejsu. Na przykład List<T> jest implementacją interfejsu IList<T> .
✔️ Należy udostępnić przynajmniej jedno API, które używa każdego z zdefiniowanych interfejsów (metoda przyjmująca interfejs jako parametr lub właściwość mająca typ interfejsu).
Dzięki temu można zweryfikować projekt interfejsu. Na przykład List<T>.Sort konsumuje interfejs System.Collections.Generic.IComparer<T>.
❌ NIE dodawaj elementów do interfejsu, który został wcześniej opublikowany.
Spowoduje to przerwanie implementacji interfejsu. Należy utworzyć nowy interfejs, aby uniknąć problemów z przechowywaniem wersji.
Z wyjątkiem sytuacji opisanych w tych wytycznych, należy ogólnie wybrać klasy, a nie interfejsy podczas projektowania bibliotek wielokrotnego użytku kodu zarządzanego.
© 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.