Nicht öffentliche Mitglieder für C# -Schnittstellen

Question

In C# sind bei der Implementierung einer Schnittstelle standardmäßig alle Mitglieder öffentlich. Denkst du, es ist besser, wenn wir den Accessibility-Modifier angeben können (geschützt, intern, außer privat natürlich) oder lieber eine abstrakte Klasse verwenden?

Answer 1

Würde keinen Sinn ergeben. Eine Schnittstelle ist ein Vertrag mit der öffentlichen, die Sie diese Methoden und Eigenschaften unterstützen. Bleib bei abstrakten Klassen.

Answer 2

Schnittstellen verfügen in ihren Methoden nicht über Zugriffsmodifikatoren, sodass sie für den Zugriffsmodifikator offen bleiben. Dies hat einen Zweck: Es ermöglicht anderen Typen, zu ermitteln, welche Methoden und Eigenschaften für ein Objekt, das einer Schnittstelle folgt, verfügbar sind. Wenn Sie geschützte/interne Zugriffe erhalten, wird der Zweck einer Schnittstelle vereitelt.

Wenn Sie darauf bestehen, dass Sie einen Zugriffsmodifizierer für eine Methode bereitstellen müssen, lassen Sie sie entweder aus der Schnittstelle heraus oder verwenden Sie wie erwähnt eine abstrakte Klasse.

Answer 3

Ich bin vertraut mit Java und nicht C#, aber warum eine Erde möchten Sie ein privates Mitglied in einer Schnittstelle? Es könnte keine Implementierung haben und wäre unsichtbar für die Implementierung von Klassen, wäre also nutzlos. Schnittstellen existieren, um Verhalten zu spezifizieren. Wenn Sie Standardverhalten benötigen, verwenden Sie eine abstrakte Klasse.

Answer 4

Wenn eine Schnittstelle intern ist, sind alle ihre Mitglieder intern in der Baugruppe. Wenn eine verschachtelte Schnittstelle geschützt ist, können nur die Unterklassen der äußeren Klasse auf diese Schnittstelle zugreifen.

Interne Member für eine Schnittstelle außerhalb ihrer deklarierenden Assembly wären sinnlos, ebenso wie geschützte Member für eine Schnittstelle außerhalb ihrer deklarierenden äußeren Klasse.

Der Punkt einer Schnittstelle ist die Beschreibung eines Vertrags zwischen einem Implementierungstyp und den Benutzern der Schnittstelle. Externe Anrufer werden sich nicht darum kümmern und sollten nicht haben, um sich um die Implementierung zu kümmern, wofür interne und geschützte Mitglieder sind.

Für geschützte Member, die von einer Basisklasse aufgerufen werden, sind abstrakte Klassen der Weg zur Angabe eines Vertrags zwischen Basisklassen und Klassen, die von ihnen erben. Aber in diesem Fall sind Implementierungsdetails in der Regel sehr relevant, es sei denn, es handelt sich um eine entartete reine abstrakte Klasse (wobei alle Mitglieder sind abstrakt) in diesem Fall geschützte Mitglieder sind nutzlos. In diesem Fall sollten Sie mit einer Schnittstelle arbeiten und die einzelne Basisklasse für die Implementierung von Typen zur Auswahl speichern.

Answer 5

Sie können die Implementierung einer Schnittstelle ausblenden, indem Sie den Namen der Schnittstelle vor dem Methodennamen explizit besagt:

public interface IInterface { 
    public void Method(); 
} 

public class A : IInterface { 
    public void IInterface.Method() { 
     // Do something 
    } 
} 

public class Program { 
    public static void Main() { 
     A o = new A(); 
     o.Method(); // Will not compile 
     ((IInterface)o).Method(); // Will compile 
    } 
} 

Answer 6

Eine Schnittstelle ist ein Vertrag, der alle implementierenden Klassen zu halten. Dies bedeutet, dass sie sich an alles oder nichts davon halten müssen.

Wenn die Schnittstelle öffentlich ist, dann muss jeder Teil dieses Kontakts öffentlich sein, sonst würde es einen Freund/interne Klassen und eine andere Sache zu allem anderen bedeuten. Verwenden Sie eine abstrakte Basisklasse oder (wenn möglich und praktisch) eine internal extension method on the interface.

Answer 7

Sie können fast den gesamten Code ausblenden, der von Schnittstellen zu externen Baugruppen implementiert wird.

interface IVehicle 
{ 
    void Drive(); 
    void Steer(); 
    void UseHook(); 
} 
abstract class Vehicle // :IVehicle // Try it and see! 
{ 
    /// <summary> 
    /// Consuming classes are not required to implement this method. 
    /// </summary> 
    protected virtual void Hook() 
    { 
     return; 
    } 
} 
class Car : Vehicle, IVehicle 
{ 
    protected override void Hook() // you must use keyword "override" 
    { 
     Console.WriteLine(" Car.Hook(): Uses abstracted method."); 
    } 
    #region IVehicle Members 

    public void Drive() 
    { 
     Console.WriteLine(" Car.Drive(): Uses a tires and a motor."); 
    } 

    public void Steer() 
    { 
     Console.WriteLine(" Car.Steer(): Uses a steering wheel."); 
    } 
    /// <summary> 
    /// This code is duplicated in implementing classes. Hmm. 
    /// </summary> 
    void IVehicle.UseHook() 
    { 
     this.Hook(); 
    } 

    #endregion 
} 
class Airplane : Vehicle, IVehicle 
{ 
    protected override void Hook() // you must use keyword "override" 
    { 
     Console.WriteLine(" Airplane.Hook(): Uses abstracted method."); 
    } 
    #region IVehicle Members 

    public void Drive() 
    { 
     Console.WriteLine(" Airplane.Drive(): Uses wings and a motor."); 
    } 

    public void Steer() 
    { 
     Console.WriteLine(" Airplane.Steer(): Uses a control stick."); 
    } 
    /// <summary> 
    /// This code is duplicated in implementing classes. Hmm. 
    /// </summary> 
    void IVehicle.UseHook() 
    { 
     this.Hook(); 
    } 

    #endregion 
} 

Dies wird den Code testen.

class Program 
{ 
    static void Main(string[] args) 
    { 
     Car car = new Car(); 
     IVehicle contract = (IVehicle)car; 
     UseContract(contract); // This line is identical... 
     Airplane airplane = new Airplane(); 
     contract = (IVehicle)airplane; 
     UseContract(contract); // ...to the line above! 
    } 

    private static void UseContract(IVehicle contract) 
    { 
     // Try typing these 3 lines yourself, watch IDE behavior. 
     contract.Drive(); 
     contract.Steer(); 
     contract.UseHook(); 
     Console.WriteLine("Press any key to continue..."); 
     Console.ReadLine(); 
    } 
} 

Answer 8

Alle Antworten hier mehr oder weniger sagen, das ist, wie Schnittstellen sein sollen, sie sind universelle öffentliche Spezifikationen.

Dies ist der meistdiskutierte Thread, lassen Sie mich zwei ausgezeichnete Antworten, die ich auf SO gefunden habe, wenn diese Frage tauchte meine Meinung.

This answer gives an example wie es unsinnig sein kann, nicht einheitliche Zugriffsspezifizierer für Schnittstellenelemente in abgeleiteten Klassen zu haben. Code immer besser als technische Beschreibungen.

Für mich am meisten verdammte Sache über erzwungene öffentliche Schnittstellenmitglieder sind, dass die Schnittstelle selbst innerhalb einer Versammlung sein kann, aber die Mitglieder, die sie ausstellt, müssen öffentlich sein. Jon Skeet explains here that's by design sadly.

Das wirft die Frage auf, warum nicht Schnittstellen entwickelt wurden, nicht-öffentliche Definitionen für Mitglieder zu haben. Das kann den Vertrag flexibel machen. Dies ist sehr nützlich beim Schreiben von Assemblys, bei denen bestimmte Member von Klassen nicht außerhalb der Assembly angezeigt werden sollen. Keine Ahnung warum.

Answer 9

Meiner Meinung nach verstößt dies gegen Kapselung. Ich muss ein methos als public implementieren, dann implementiere ich eine Schnittstelle. Ich sehe keinen Grund, die Öffentlichkeit in einer Klasse zu zwingen, die die Schnittstelle implementiert. (C#)