2009-10-30 12 views
5

Odpowiedzialność za widoczność metody jest relegowana do klasy implementującej interfejs.Czy istnieje powód, dla którego nie można zdefiniować modyfikatora dostępu dla metody lub interfejsu?

public interface IMyInterface 
{ 
    bool GetMyInfo(string request); 
} 

W języku C# ustawić dostęp modyfikator publiczne, prywatne lub chronione przed metody GetMyInfo() generuje następujący błąd: modyfikator „prywatny” nie jest prawidłowy dla tej pozycji.

Czy istnieje powód, dla którego nie można zdefiniować modyfikatora dostępu dla metody lub interfejsu?

(pytanie już zadane w francuski here)

+0

możliwy duplikat [Non Public Members for C# Interfaces] (http://stackoverflow.com/questions/17576/non-public-members-for-c-sharp-interfaces) – nawfal

Odpowiedz

14

Interfejs definiuje umowę między obiektem a klientami, które wymagają jego członków. Prywatna metoda nie może być dostępna dla żadnego innego obiektu, więc nie ma sensu dodawać jej do interfejsu. Wszyscy członkowie interfejsu są z tego powodu uznani za publicznych.

+0

dlaczego pominąłeś 'protected '? – UnKnown

4

Pod względem OO - hermetyzacja polega na ukrywaniu danych. Oznacza to, że wszystko, co dzieje się w klasie, zależy od implementacji klasy. Co oznacza, że ​​bezużyteczne byłoby umowne egzekwowanie prywatnych członków.

Jednak powodem, dla którego używa się interfejsów, jest zapewnienie, że klasa jest zgodna z określoną umową i ujawnia kilku członków publicznych w spójny sposób.

+0

Rzeczywiście, co, jeśli w rzeczywistości fizyczny interfejs do podłączenia przewodu do monitora do komputera był arbitralnie brakuje niektórych szpilek (ponieważ były one brakujące/ukryte/prywatne)? Po prostu nie zadziałałoby. Dlatego nawet wirtualne interfejsy muszą być w pełni dostępne i wyeksponowane. –

10

Ty może rzeczywiście sprawiają, że metoda prywatna w klasie wykonawczego, jeśli dokonać wyraźnego implementację interfejsu:

public interface IMyInterface 
{ 
    bool GetMyInfo(string request); 
} 

public class MyClass : IMyInterface 
{ 
    public void SomePublicMethod() { } 

    bool IMyInterface.GetMyInfo(string request) 
    { 
     // implementation goes here 
    } 
} 

Takie podejście oznacza, że ​​GetMyInfo nie będzie częścią interfejsu publicznego MyClass. Jest ona dostępna tylko przez odlewanie instancji MyClass do IMyInterface:

MyClass instance = new MyClass(); 

// this does not compile 
bool result = instance.GetMyInfo("some request"); 

// this works well on the other hand 
bool result = ((IMyInterface)instance).GetMyInfo("some request"); 

Tak więc, w kontekście interfejsu, wszyscy jego członkowie będą jawne. Mogą być ukryte przed publicznym interfejsem klasy implementującej, ale zawsze istnieje możliwość wykonania rzutowania typu na instancję i dostępu do członków w ten sposób.

+1

+1 za dodatkowy bit informacji. Nigdy jednak nie rozumiem, dlaczego tak się stało lub w jakich okolicznościach takie zachowanie jest pożądane (???) – Yoopergeek

+0

Tak, dziękuję za ten przykład. –

+0

Dzięki za wskazanie tej niezwykłej luki. – warriorpostman

1

Wszystkie metody interfejsu muszą mieć ten sam poziom dostępu - aby dzwoniący mógł z nich korzystać. Jednak interfejsy mogą być również wewnętrzne (lub jako zagnieżdżony interfejs prywatny).

Jeśli potrzebujesz różnych poziomów dostępu, użyj osobnego interfejsu.

0

prywatna definicja w interfejsie będzie:

  1. daje żadnych korzyści dla użytkownika interfejsu (jest to prywatny po wszystkich)
  2. ograniczyć klasę wykonawczą musieli wdrożyć metodę lub właściwość
  3. błotnisty koncepcyjny charakter interfejs z implementacji szczegółowo
  4. być jak klasy abstrakcyjnej z prywatnym metody (co nie jest dozwolone)
+0

"Prywatny" modyfikator może nie być przydatny, ale "wewnętrzny" modyfikator dostępu byłby. Są sytuacje, w których chcemy umożliwić zewnętrznemu kodowi przekazywanie referencji do klasy abstrakcyjnej, ale nie używać wszystkich jej funkcji lub tworzyć obiektów, które można zastąpić. Istnieją sytuacje, w których wykres typów obiektów, które mogą być wzajemnie zastępowalne, nie jest drzewem, a zatem może być modelowany tylko za pomocą interfejsów, a nie tylko dziedziczenia. Gdy te dwie sytuacje będą się nakładać, przydatne będą metody wewnętrznych interfejsów. – supercat

Powiązane problemy