Projekt interfejsu
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ż 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 wielu dziedziczenia (tj. klasy CLR nie mogą dziedziczyć z więcej niż jednej klasy bazowej), ale nie zezwala na implementowanie co najmniej jednego interfejsu 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 jest interfejsem, IDisposable który umożliwia typom obsługę rozproszenia 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.
✔️ Do zdefiniuj interfejs, jeśli potrzebujesz niektórych typowych interfejsów API, które mają być obsługiwane przez zestaw typów, które zawierają typy wartości.
✔️ ROZWAŻ zdefiniowanie interfejsu, jeśli musisz obsługiwać jego funkcje dla typów, które już dziedziczą z innego typu.
❌ UNIKAJ używania interfejsów znaczników (interfejsów bez elementów członkowskich).
Jeśli musisz oznaczyć klasę jako określoną charakterystykę (znacznik), w ogóle użyj atrybutu niestandardowego, a nie interfejsu.
✔️ Czy zapewnić 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ć co najmniej jeden interfejs API, który używa każdego zdefiniowanego interfejsu (metoda przyjmująca interfejs jako parametr lub właściwość typizowane jako interfejs).
Dzięki temu można zweryfikować projekt interfejsu. Na przykład List<T>.Sort używa interfejsu System.Collections.Generic.IComparer<T> .
❌ NIE dodawaj elementów członkowskich do interfejsu, który został wcześniej wysłany.
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.
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.