views:

3743

answers:

8

In C#, when you implement an interface all members are public by default. Do you think it's better if we can specify the accessibility modifier (protected, internal, except private of course) or better use an abstract class instead?

+4  A: 

Would not make sense. An Interface is a contract with the public that you support those methods and properties. Stick with abstract classes.

Ishmaeel
+1  A: 

Interfaces do not have access modifiers in their methods, leaving them open to whichever access modifier is appropriate. This has a purpose: it allows other types to infer what methods and properties are available for an object following an interface. Giving them protected/internal accessors defeats the purpose of an interface.

If you are adamant that you need to provide an access modifier for a method, either leave it out of the interface, or as you said, use an abstract class.

Jon Limjap
A: 

I'm familiar with Java rather than C#, but why an earth would you want a private member within an interface? It couldn't have any implementation and would be invisible to implementing classes, so would be useless. Interfaces exist to specify behaviour. If you need default behaviour than use an abstract class.

John Topley
+13  A: 

If an interface is internal, all its members will be internal to the assembly. If an nested interface is protected, only the subclasses of the outer class could access that interface.

Internal members for an interface outside of its declaring assembly would be pointless, as would protected members for an interface outside of its declaring outer class.

The point of an interface is to describe a contract between a implementing type and users of the interface. Outside callers aren't going to care and shouldn't have to care about implementation, which is what internal and protected members are for.

For protected members that are called by a base class, abstract classes are the way to go for specifying a contract between base classes and classes that inherit from them. But in this case, implementation details are usually very relevant, unless it's a degenerate pure abstract class (where all members are abstract) in which case protected members are uselss. In that case, go with an interface and save the single base class for implementing types to choose.

Mark Cidade
what do you mean by "users of that interface"? So is that when you create a variable lets say IMyInterface someVar; And then use someVar somehow?
CoffeeAddict
Also I may add that Interfaces force a pattern / commonality to the structure of your application (the classes within) which is a hug point even if you're not exposing the interfaces to external clients...right??
CoffeeAddict
@coffeeaddict yes and yes.
Mark Cidade
+2  A: 

You can hide the implementation of an interface by explicitly stating the interface name before the method name:

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
  }
}
samjudson
+2  A: 

An interface is a contract that all implementing classes adhere to. This means that they must adhere to all of it or none of it.

If the interface is public then every part of that contact has to be public, otherwise it would mean one to friend/internal classes and a different thing to everything else.

Either use an abstract base class or (if possible and practical) an internal extension method on the interface.

Keith
A: 

You can hide almost all of the code implemented by interfaces to external assemblies.

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
}

This will test the code.

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();
    }
}

Rudedog =8^D

A: 
internal class MyHiddenClass : IMyClass
{
   public IMyClass myNestedInstance = ...;
   public void DoSth()
   {
      myNestedInstance.DoSthElse(); // doesnt work! pls help!
   }

   internal void DoSthElse()
   {
      // this method should be hidden from public, 
      // but sould be possible to use internally
   }
}
Christian
Is this a new question? If so, it should be posted separately as a question, not as an answer.
Bill the Lizard