2011-12-23 17 views
19

W języku C# musimy nazwać parametry metody interfejsu.Dlaczego musimy nazwać parametry metody interfejsu?

Rozumiem, że nawet jeśli nie musisz, robi tak by pomóc czytelnikowi zrozumieć znaczenie, jednak w niektórych przypadkach to nie jest naprawdę potrzebne:

interface IRenderable 
{ 
    void Render(GameTime); 
} 

powiedziałbym powyższe jest tak czytelne i sensowne jak poniżej:

interface IRenderable 
{ 
    void Render(GameTime gameTime); 
} 

Czy istnieje jakiś techniczny powód, dla którego wymagane są nazwy parametrów metod na interfejs?


Warto zauważyć, że wdrożenie metody interfejsu można używać różnych nazw jak w metodzie interfejs użytkownika.

+0

Myślę, która stałaby nazwy sygnatur metoda zgodny!!! –

+0

Zobacz mój zredagowany ostatni komentarz. –

+1

co mam na myśli to, że deklaracje metod są spójne między klasami i interfejsami ... –

Odpowiedz

19

Jednym z możliwych powodów może być użycie opcjonalnych parametrów.

Jeśli używaliśmy interfejsu, niemożliwe byłoby podanie nazwanych wartości parametrów. Przykład:

interface ITest 
{ 
    void Output(string message, int times = 1, int lineBreaks = 1); 
} 

class Test : ITest 
{ 

    public void Output(string message, int numTimes, int numLineBreaks) 
    { 
     for (int i = 0; i < numTimes; ++i) 
     { 
      Console.Write(message); 
      for (int lb = 0; lb < numLineBreaks; ++lb) 
       Console.WriteLine(); 
     } 

    } 
} 

class Program 
{ 
    static void Main(string[] args) 
    { 
     ITest testInterface = new Test(); 
     testInterface.Output("ABC", lineBreaks : 3); 
    } 
} 

W tej implementacji, w przypadku korzystania z interfejsu, są domyślne parametry dotyczące times i lineBreaks, więc jeśli dostęp za pośrednictwem interfejsu, możliwe jest użycie domyślne, bez wymienionych parametrów, bylibyśmy nie można pominąć parametru times i podać tylko parametru lineBreaks.

Tylko FYI, w zależności od tego, czy uzyskujesz dostęp do metody Output za pośrednictwem interfejsu, czy poprzez klasę określa, czy parametry domyślne są dostępne i jaka jest ich wartość.

+0

Interfejsy były tam przed parametrami opcjonalnymi i nazwanymi. :) – CodeCaster

+0

@CodeCaster Dobry krzyk, najprawdopodobniej nie pierwotny powód, jednak jest to z pewnością powód teraz :) Myślę, że możliwość przyszłych funkcji takich jak ten był powodem, dla którego je nazwali. – Lukazoid

+0

@Lukazoid, dobrze zrobione. To najbardziej logiczna odpowiedź, niezależnie od tego, jak na nią patrzysz. –

9

Nie widzę żadnego powodu, który spowodowałby, że byłby to wymóg techniczny. Ale mogę wymyślić jeden szczególnie dobry powód:

Jak już wspomniano, nazwy parametrów nie są potrzebne podczas implementacji interfejsu i mogą być łatwo zastąpione.
Jednak, gdy przy użyciu interfejsu, wyobraź sobie trudność, jeśli żadne parametry nie mają znaczących nazw! Bez intellisense, bez podpowiedzi, nic poza typem? Fuj.
To musi być największy powód, dla którego imię jest zawsze wymagane.

+0

plus to czyni je spójnymi z deklaracjami metod w klasach. – Thilo

+2

"Wyobraź sobie trudność, jeśli żadne parametry nie mają wymownych nazw!" - po prostu napisz trochę Java w Eclipse, większość nazw parametrów jest wyświetlana jako "arg0" itd. – Adam

+1

@codesparkle Brzmi to zabawnie, jak czytanie przez zminimalizowany plik JavaScript! –

0

OK, ta możliwość prawie wydaje się zbyt niepoważna, ale - może, jeśli pozwolisz Visual Studio zaimplementować interfejs i kod pośredniczący we właściwościach i metodach, będzie wiedział, jak nazwać parametry?

Z drugiej strony, nie ma problemu VS rodzajowo nazewnictwa formantów ...

1

Nie mogę myśleć o jakiejkolwiek uzasadnionej przyczyny technicznej interfejsy mieć nazwy zdefiniowane.

Mogę łatwo zobaczyć sytuację, w której nazwy są automatycznie wdrażane, podobnie jak członkowie wspierający automatycznie wprowadzane właściwości.

Myślę jednak, że prawdopodobnie istnieją 3 główne powody, dla których zostały one potrzebne:

1) To był prawdopodobnie znacznie łatwiejsze do wdrożenia walidacji interfejsu w kompilatora przy użyciu tych samych zasad jak rzeczywistych metod. Ponieważ dopiero stosunkowo niedawno wprowadzono właściwości automatycznie implementowane, podejrzewam, że jest to niebanalna zmiana kompilatora.

2) W przypadku języków, które obsługują automatyczne tworzenie elementów interfejsu w klasie implementacji (np. VB), prawdopodobnie łatwiej jest utworzyć implementację interfejsu przy użyciu wstępnie zdefiniowanych nazw niż próba utworzenia nazw w locie .

3) Ponieważ interfejs może być odsłonięty poza aplikacją definiującą, nazwy usuwają niejednoznaczność powiązaną ze źle zdefiniowanym interfejsem.

Na przykład, próbując wdrożyć metody interfejsu:

void Foo(string, string, int) 

najprawdopodobniej doprowadzi do znacznie więcej zamieszania niż samodokumentujące przykład. Jest to jednak raczej problem z użytecznością interfejsu niż techniczna, chociaż można argumentować, że jeśli interfejs nie nadaje się do użytku, istnieje podstawowy problem techniczny.

2

Naming Metoda interfejsu parametry użytkowe pomaga dokumentacji samodzielne:

Na przykład ...

interface IRenderable 
{ 
    void Render(TimeSpan gameTime); 
} 

... mówi więcej niż:

interface IRenderable 
{ 
    void Render(TimeSpan); 
} 
Powiązane problemy