Define class-implementations in an interface

Are you able to define class-implementations in an interface?

For instance (pseudo-code alert!)...

interface IClass1
{
    String s { get; set; }

    // classes implementing this interface has to implement Class2 as "SubClass"
    Class2 SubClass;
}

interface IClass2
{
     Int32 i { get; set; }
}

class Class1 : IClass1
{
    String IClass1.s { get; set; }

    class IClass1.Class2 S开发者_运维知识库ubClass
    {
        Int32 IClass2.i { get; set; }
    }
}

The purpose of an interface is to define a contract which is separate from any implementation.

What you can do with an interface is defining a property like so:

interface IClass1
{
    String S { get; set; }

    Class2 SubClass { get; set; }
}

There is no syntax for forcing a class to implement another nested class. What you have effectively defined here is that any IClass1 implementation must have a field of type Class2.

Unfortunately there are two things wrong with this:

1. Class2 does not resolve to a known accessible type, therefore a compiler error will be generated.
2. The SubClass member of IClass1 is declared as a field, and interfaces cannot declare fields.

No. Also, Class2 isn't a subclass, it's a nested class or inner class. "Sub-class" is (in this context, there are other contexts that are completely different) another name for a derived class, in which context the base class is called a "super-class" (which is why Java has a keyword super that is analogous to base in C# though with some differences). "Derived" and "base" are the more popular terms in C#, perhaps because they are more popular terms in C++, perhaps because Bjarne Stroustrup says he finds them confusing and even he gets mixed up about which is which (after all, the subclass has a superset of behaviour and vice-versa).

Inner classes are essentially using their containing class as a namespace and nothing else, while interfaces only detail member methods and properties.

First of all, your question was: "Are you able to define class-implementations in an interface?"

The answer to this is "in a way / no".
You can't include class definitions "inside" the interface definition if that's what you mean.

As mentioned earlier, the implementation of such a thing could happen via interface properties.

You should probably not try to implement your described interface structure unless classes exist that the implementing code's functionality is totally dependent on and if the interface is already deeply integrated into several existing modules. That in it self is a design flaw, and could be swapped with an abstract class implementation.
The CLR does not support multiple inheritance, but it does allow types to implement one or more interfaces in addition to inheriting from a base class. Therefore, interfaces are often used to achieve the effect of multiple inheritance.

Requiring classes to inherit from a single base class would in most cases make the class hierarchy too inflexible. To use a base class internally to simplify library development, public members should delegate work to the base class instead of inheriting from it. Choose carefully between an abstract class and an interface when designing an abstraction as it can behave like an interface in that it can define members, and it can provide implementation details but are not required to do so, and can add members as needed to support additional functionality...

So, if used in the way you want, it departs from the concept of C# interfaces, but maybe seem to closer mimic the multiple inheritance model of languages such as C++ in practice, as it it implicitly "forces all implementors of your interface to create an instance of each class that the interface has specified properties for.

You need to think a bit about the reason for wanting to create such a structure (the need to force all implementors of an interface to also create instances of classes that the interface defines as properties).
This is more likely a design-flaw in your code than it is a missing language feature.

So even though it is a possible workaround, I wouldn't call it a good way of design things...

Apologies if I've misunderstood but, yes, I do this now (VB 2013 for .NET 4.0 & 4.5). Interfaces can define properties, properties can be complex, the class definition for which can be nested within the interface definition. In your class that implements the interface, you'll can only have a the getter/setter for the complex object as a whole, not for its individual properties. (The getters/setters for those are within the class definition of course). Working example from VB attached, along with untested conversion to C#.

VB:

Interface IPrintable
    Property Body As DocBody

    Class DocBody
        Property Text As String
        Property FontSize As Single
    End Class
End Interface

Class WordDoc
    Implements IPrintable
    Public Property WordBody As IPrintable.DocBody Implements IPrintable.Body
End Class

and C#:

interface IPrintable
{
    DocBody Body { get; set; }
    public class DocBody
    {
        public string Text { get; set; }
        public float FontSize { get; set; }
    }
}

class WordDoc : IPrintable
{
    public IPrintable.DocBody WordBody { get; set; }
    IPrintable.DocBody IPrintable.Body {
        get { return WordBody; }
        set { WordBody = value; }
    }
}

I'm unable to comment, but the accepted answer to this question is no longer accurate. As of C#8 it is possible to define default implementations for interface methods. As interfaces have no private member's, this is limited to calling other public members, and so is useful for defining method overrides that call into one another.