Podczas przeglądania zestawów .NET Framework i drążenia w dół do klas podstawowych dla dowolnego ze standardowych obiektów, zauważysz wiele interfejsów (członków o nazwie ISomeName).
Interfejsy są w zasadzie do implementacji frameworków, dużych lub małych. Tak samo myślałem o interfejsach, dopóki nie chciałem napisać własnego frameworka. Odkryłem również, że zrozumienie interfejsów pomogło mi szybciej nauczyć się ram. W momencie, gdy chcesz napisać bardziej eleganckie rozwiązanie do wszystkiego, przekonasz się, że interfejs ma sens. To jak metoda pozwalająca klasie założyć odpowiednie ubrania do pracy. Co ważniejsze, interfejsy pozwalają systemom na znacznie bardziej samo-dokumentowanie, ponieważ złożone obiekty stają się mniej złożone, gdy klasa implementuje interfejsy, co pomaga kategoryzować jego funkcjonalność.
Klasy implementują interfejsy, gdy chcą mieć możliwość bezpośredniego lub pośredniego uczestnictwa w strukturze. Na przykład, IDisposable to wspólny interfejs, który zapewnia podpis metody dla popularnej i użytecznej metody Dispose (). W środowisku wszystko, co ty lub inny programista powinniście wiedzieć o klasie, to to, że jeśli implementuje ona IDisposable, to wiesz, że ((IDisposable) myObject) .Dispose () można wywołać w celu wyczyszczenia.
PRZYKŁAD KLASYCZNY: bez implementacji interfejsu IDisposable nie można używać konstrukcji słowa kluczowego „using ()” w języku C #, ponieważ wymaga to, aby każdy obiekt określony jako parametr mógł być niejawnie rzutowany na IDisposable.
PRZYKŁAD KOMPLEKSOWY: Bardziej złożonym przykładem byłaby klasa System.ComponentModel.Component. Ta klasa implementuje zarówno IDisposable, jak i IComponent. Większość, jeśli nie wszystkie, obiekty .NET, z którymi jest powiązany projektant wizualny, implementują IComponent, dzięki czemu IDE będzie mogło wchodzić w interakcje z tym komponentem.
WNIOSEK: Gdy zapoznasz się z .NET Framework, pierwszą rzeczą, którą zrobisz, gdy spotkasz nową klasę w Przeglądarce obiektów lub w narzędziu .NET Reflector (darmowym) ( http://www.red-gate.com / products / reflector / ) ma sprawdzić, która klasa dziedziczy, a także interfejsy, które implementuje. .NET Reflector jest jeszcze lepszy niż Przeglądarka obiektów, ponieważ pozwala także zobaczyć klasy pochodne. To pozwala ci dowiedzieć się o wszystkich obiektach, które wywodzą się z konkretnej klasy, a tym samym potencjalnie dowiedzieć się o funkcjonalności frameworku, o której istnieniu nie wiedziałeś. Jest to szczególnie istotne, gdy do .NET Framework zostaną dodane nowe lub nowe przestrzenie nazw.