C# Interfejsy z opcjonalnymi metodami

Question

Rozumiem, że interfejsy są umowami, a wszelkie zmiany (nawet dodatki) łamią każdy zależny kod. Mogłabym jednak przysiąc, że przeczytałem jakiś czas temu, że jedna z ostatnich wersji .NET (3, 3.5 ??) dodała nowy atrybut, który można zastosować do nowych członków interfejsu. Ten atrybut umożliwiał wersjonowanie i/lub dodawanie członków jako opcjonalnych. Byłoby to coś w rodzaju:

interface ITest 
{ 
    void MethodOne(); 

    [InterfaceVersion(2)] 
    void MethodTwo(); 
} 

Wyglądałem wysoko i nisko, ale po prostu nie mogę tego znaleźć. Zastanawiam się, czy po prostu źle zrozumiałem to, co myślę, że czytam i nie ma czegoś takiego. Czy ktoś ma wgląd?

Answer 1

Należy utworzyć dwa interfejsy:

interface ITest 
{ 
    void MethodOne(); 
} 

interface ITest2 : ITest 
{ 
    void MethodTwo(); 
} 

to również jasno, którego funkcjonalność wymaga którą wersję interfejsu, dzięki czemu nie trzeba by sprawdzić, czy klasa wykonawczych interfejs realizuje tylko jedną lub obie metody.

Answer 2

Nie znam takiego atrybutu, który pozwala częściowo implementować implementację interfejsu. Można to obejść za pomocą klasy abstrakcyjnej, ale:

public abstract class Test 
{ 
    public abstract void MethodOne(); 
    public virtual void MethodTwo() { } 
} 

Pozwoliłoby to użytkownikowi zdecydować, czy chcą, aby zastąpić MethodTwo gdy dziedziczenie z testem, a zmuszając Nadrzędnym MethodOne.

Answer 3

Nie ma takiego atrybutu w środowisku .NET Framework.

Answer 4

Nie widziałem takiego atrybutu, ale myślę, że to możliwe. This article na MSDN opisuje wersjonowanie za pomocą słów kluczowych overrides i new.

W skrócie, język C# jest wyposażony w funkcje językowe, które umożliwiają ewolucję klas pochodnych i nadal zachowują zgodność. Ten przykład pokazuje czysto bazową relację, ale baza faktycznie implementowałaby interfejs potrzebny do wersji. Posiadanie jednego interfejsu wymaga innej (poprzedniej wersji) interfejsu sprzężonego z tą metodą również jest bardzo użyteczny.

Przykład tworzenia interfejsu, który wymaga innego:

public interface IMyInterface 
{ 
    void FirstMethod(); 
} 

public interface IMySecondInterface : IMyInterface 
{ 
    void SecondMethod(); 
} 

Przykład użycia dziedziczenia aby zachować kompatybilność:

public class MyBase 
{ 
    public virtual string Meth1() 
    { 
     return "MyBase-Meth1"; 
    } 
    public virtual string Meth2() 
    { 
     return "MyBase-Meth2"; 
    } 
    public virtual string Meth3() 
    { 
     return "MyBase-Meth3"; 
    } 
} 

class MyDerived : MyBase 
{ 
    // Overrides the virtual method Meth1 using the override keyword: 
    public override string Meth1() 
    { 
     return "MyDerived-Meth1"; 
    } 
    // Explicitly hide the virtual method Meth2 using the new 
    // keyword: 
    public new string Meth2() 
    { 
     return "MyDerived-Meth2"; 
    } 
    // Because no keyword is specified in the following declaration 
    // a warning will be issued to alert the programmer that 
    // the method hides the inherited member MyBase.Meth3(): 
    public string Meth3() 
    { 
     return "MyDerived-Meth3"; 
    } 

    public static void Main() 
    { 
     MyDerived mD = new MyDerived(); 
     MyBase mB = (MyBase) mD; 

     System.Console.WriteLine(mB.Meth1()); 
     System.Console.WriteLine(mB.Meth2()); 
     System.Console.WriteLine(mB.Meth3()); 
    } 
} 

Answer 5

Można myśleć o partial methods (MSDN).

Answer 6

Niedawno był w sytuacji, gdy podyktowane brakiem wielokrotnego dziedziczenia zabronił mi przekształcić istniejący interfejs do klasy abstrakcyjnej, i znalazłem się z rozciągającym się rozwiązania:

interface IFoo { 
      int RowCount(); 
    } 

    static class _FooExtensions { 
      public static bool HasAnyRows (this IFoo foo) { 
        return foo.RowCount() > 0; 
      } 
    } 

w ten sposób można zapewnić domyślna wersja w przypadku, gdy Twoja metoda abstrakcyjna może być zdefiniowana pod względem innych funkcji.

Answer 7

Mogłeś przeczytać coś podobnego

interface ITest 
{ 
    void MethodOne(); 

    [InterfaceVersion(2)] 
    void MethodTwo(); 
} 



[AttributeUsage(AttributeTargets.All)] 
public class InterfaceVersion : System.Attribute 
{ 
    public readonly int N; 

    public InterfaceVersion(int n) 
    { 
     this.N = n; 
    } 
} 

Ale nie sądzę, że mógłby realizację MethodTwo opcjonalnym.

EDIT:

Właśnie dowiedziałem się przez uruchomienie kodu, który tak naprawdę nie robi realizację MethodTwo opcjonalnym.

Answer 8

Być może myślisz o nowej funkcji "no pia" w C# 4? Oznacza to, że zezwalamy na "dołączanie" tylko części interfejsu, z którego faktycznie korzystasz z PIA, a następnie możesz pominąć wysyłkę PIA do swoich klientów. Jeśli robisz to kilka razy w kilku różnych złożeniach, CLR wykonuje pracę, aby dowiedzieć się, że wszystkie te połączone częściowe interfejsy są logicznie tego samego typu i ujednolica je. W ten sposób możesz przekazywać obiekty, które implementują każdy smak interfejsu z jednego zestawu do drugiego i wszystko działa. Jednak interfejsy oryginalne, z których tworzone są interfejsy "no pia", muszą być takie same.