Do you think “auto interface implementation” would be useful in .NET / C# [closed]

Answer 1

Well I think the other answers will help you understand the use of the interface to abstract logic in different concrete classes, I also think you can accomplish something similar to what you want using the refactoring tools built into VS.

Define your class...

public class Person
{
  public int ID { get; protected set; }
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public string FullName { get { return FirstName + " " + LastName; } }
}

Then right click, select Refactor -> Extract Interface.

This will create a separate file containing the interface for the definition of the class, you could then mold the interface and implementing classes accordingly.

Extracted Interface:

interface IPerson
{
    string FirstName { get; set; }
    string FullName { get; }
    int ID { get; }
    string LastName { get; set; }
}

Answer 2

Let me see if I am understand what you're asking:

Why can't we declare an interface:

interface IPerson
{
    string Name {get;set;}
    int ID {get;set;}
}

And classes which implement that interface will inherit its properties without having to re-declare them:

class Person : IPerson { } 
//person now has properties Name and ID

The reason you can't do this is even though the text of your interface code and your class code are very similar, they mean very different things. The interface simply says "implementor will have a string Name with getter and setter". It is the class which says "return private field when getter for name is invoked." Even if you use the auto-property shortcut to let the compiler implement that logic, it is still logic, which belongs in the class. Just because:

string Name {get;set;}

looks the same in an interface and in a class, it does not mean even remotely the same thing.

It would be very dangerous for the compiler to implement arbitrary logic to fulfill your contracts for you, instead of complaining at compile time that you haven't implemented them. It could introduce bugs very difficult to track down. Having compilers fall back to default behavior when no behavior is defined is a very, very bad idea.

Answer 3

I think a better abstraction for this is a trait, or, as I've described here, a role. This is like an interface with code. Your example could be coded like this:

public role RPerson { 
  int ID { get; protected set; } 
  string FirstName { get; set; } 
  string LastName { get; set; } 
  string FullName { get { return FirstName + " " + LastName; } } 
} 

public class Person : RPerson { }

public class StubPerson : RPerson { 
    int ID { get { return 0; protected set { } } 
    string FirstName { get { return "Test" } set { } } 
    string LastName { get { return "User" } set { } } 
    string FullName { get { return FirstName + " " + LastName; } } 
} 

// ...

RPerson rperson = new Person(); 

RPerson rpersonStub = new StubPerson(); 

Answer 4

No, because you would be forced to expose all public members of an interface. Try ReSharper, and never worry about this again.

Answer 5

I guess I am missing the point - what are you accomplishing by mixing a class and an interface together? What problem are you solving with this approach?

This:

IPerson iperson = new Person();

is already legal in C#.

Edit: For clarification - the code above is legal given the following:

interface IPerson { }

class Person : IPerson { }

Answer 6

I believe Eiffel does something like this on .NET, in order to support multiple inheritance. A class declaration automatically produces a corresponding interface. When the class type is referred to, the compiler mostly emits a reference to the interface type instead. The main exception is in constructor expressions of course.