C#接口不能实例化。那使用类似声明类的语法声明一个接口的含义是什么？

[Stan_Ding]

大家好，我刚刚开始学C#。我理解以下语句是用默认构造函数对类进行实例化
MyBaseClass MyBaseObj = new MyBaseClass(); //MyBaseClass 基类名

但书上说C#接口不能实例化，但给的例子中出现这样的声明该如何理解呢？
IMyinterface Myinterface= new MyBaseClass(); //MyBaseClass 基类名。

谢谢

[Stan_Ding]

感谢各位老师！目前看的《C#入门经典》虽然是第五版，但大部分还是在介绍各种语法该怎么写，不该怎么写，很少讲到这么规定背后的原因。因此记忆起来容易混淆。 根据书上和各位老师的的介绍，我自己测试了一个语句，有一个问题不理解，如果我的IMyinterface包含一个DoSomething()方法，我再定义一个子类MyDerivedClass继承MyBaseClass，并在两个类中都定义了DoSomething()这个方法，但仅再基类实现IMyinterface接口， 我在main()函数中用

IMyinterface Myinterface = new MyDerivedClass();

声明了一个MyDerivedClass的实例。并希望调用MyDerivedClass中写的DoSomething()方法。

Myinterface.DoSomething();

实际结果则是调用了MyBaseClass中写的DoSomething()方法。请问为什么呢？ 谢谢！ 以下是完整代码，编译则输出“Base show"

namespace test1
{
    public interface IMyinterface
    {
        void DoSomething();
    }

    public class MyBaseClass:IMyinterface
    {
        public void DoSomething()
        {
            Console.WriteLine("Base show");
        }
    }
    public class MyDerivedClass:MyBaseClass
    {
         new public void DoSomething()
        {
            Console.WriteLine("Derived Show");
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            MyBaseClass MyBaseObj = new MyBaseClass();
            IMyinterface Myinterface = new MyDerivedClass();
            Myinterface.DoSomething();
            Console.ReadKey();
        }
    }
}

[Brown_Sugar]

请看C#区置顶帖那个高频提问解答汇总的帖子

[以专业开发人员为伍]

.net 和 java 都不支持多重继承，这是它们的一个问题。使用接口就可以摸你多重继承设计实现。 例如一个 WebForm TextBox 控件不但是 WebControl，而且具有 IPostBackDataHandler, IEditableTextControl 等接口，而并不是所有的 Webcontrol 都支持回发处理的，所以 TextBox 就需要从多个父类继承其特性。 但是 java 并不支持多重继承，然后多了许多年之后出现了 .net 来抄 java 而设计，为了与之比较“性能”等原因，.net 也不支持多重继承。 接口就是把多重继承的责任推给了程序员，让你自己写代码来实现多重继承，而编译器只是强迫你必须实现多重继承的语法，而编译器并不自动给你实现底层代码。实际上你还是得手动实现，只不过编译器、语言本身不管你。 假设说 MyBaseObj 既是从 MyBaseClass 继承的、又是从 Myinterface 继承的，编译器帮你实现了多个父类继承来的代码（帮你自动调用 Myinterface 父类代码），那么你就省力了。但是 java 和 .net 语法定义就是不能这样的，就是只能有一个父类，剩下的 IMyinterface 就只是一个空壳，你的 MyBaseObj 类型必须手动地一个一个去书写 IMyinterface 要求的内容（例如说你有一个 Myinterface 类库，那么你的 MyObject 中实现 IMyinterface 接口的代码就必须手动地委派调用 Myinterface）。

[以专业开发人员为伍]

假设说 .net 是抄Eiffel 而不是抄 Java，我相信 .net 不但会高性能地去支持多重继承、契约编程，而且更加优雅简洁、工程化。 但是学术的东西都要让位给市场竞争。20年前的事情，现在也就是说说而已。毕竟 .net 还是是很成功的设计。

[以专业开发人员为伍]

比如说在 .net 和 java 之前也比较常用的编程 c++，它就支持多重继承的。支持了多重继承就没有必要有什么接口概念了。 c# 虽然是很想继承 c++ 语言，但是市场决定了它优先要考虑抄 java 而不是 c++。

[SoulRed]

接口就是相当于多发会谈达成的一个框架协议，大家都按照这个协议走，事情就不会走歪路

[以专业开发人员为伍]

你说的所谓“默认构造函数对类进行实例化、基类名、（接口）不能实例化”都还是主要在抄书本的文字上，没有抛开书本的干巴巴的文字来看懂背后的工程原因。 一个 MyBaseClass 对象实例它在实例化时只需要满足 MyBaseClass 的要求吗？不是的。它同时也还是一个 IMyinterface 类型的对象（这里我们先从设计角度来混淆 class 和 Interface 名词儿），也需要为了将来能实现 IMyinterface 的所有的属性、事件、方法等等接口功能而初始化。 但是，IMyinterface 定义中什么内涵都没有，只有一个空壳作为约束。你的 MyBaseClass 代码虽然描述了自己拥有 IMyinterface 接口，却不能像描述它具有某个“父 class”一样就自动地继承父类的大量代码。你的 MyBaseClass 代码中必须手动书写所有在 IMyinterface 接口中声明过的 事件、属性、方法等等。 因此我们首先不要使用接口，应该使用 class 继承机制。但是 .net 不支持多重继承，所以我们又不得不使用接口来模拟多重继承设计。 在你给出的例子中，它只是表示了这种接口的语法而已。并没有从程序设计的工程上来讲。它只是讲一个语法而已，所以不得罪人，就算是写了一堆冗余的语法解释，你也还是被动地死记硬背。但是如果你理解了工程设计和应用，才真正理解了语法到底有没有用。

[xuzuning]

    public class MyDerivedClass : MyBaseClass, IMyinterface
    {
         public void DoSomething()
        {
            Console.WriteLine("Derived Show");
        }
    }

[秋的红果实]

父类实现了接口，子类继承父类，自然也就实现了该接口 你在父类、子类里都实现了接口里的方法，而且在子类中使用了new，这样就“隐藏”了父类中方法的具体实现，最好不要这样设计，既然子类中才用到的功能，就不要放到父类中，这违反开闭原则，违反李氏转换原则

[秋的红果实]

方法的实现，是指 public void DoSomething() { Console.WriteLine("Base show"); } 就是给出方法要实现的业务逻辑，你的是在控制台输出：Base show

[Stan_Ding]

了解，非常感谢

[正怒月神]

多态。 简单的说，就是 父类 指向子类的引用。 只是这里的父类是一个接口类型而已。他并不是实例化了一个接口。 他真正实例化的还是 子类MyDerivedClass();

[绿领巾童鞋]

IMyinterface Myinterface= new MyBaseClass(); 简单一点来描述吧。 IMyinterface 是接口 ，他是引用类型，MyBaseClass是类，他也是引用类型；而MyBaseClass 实现 IMyinterface 接口，跟抽象一样，上面的用法没毛病吧～

[CqCoder]

接口不能实例化是指 IMyinterface Myinterface= new IMyinterface ();

[紫魂一号]

打个比方。你的项目里有这么些对象，比如说风扇，空调，冰箱。。。等等一系列的电器。。如果都有那么一个方法：启动（start） 那么你是不是要为每个电器定义一个方法，还不带重名的，那多麻烦。假如用接口的话就定义那么一个名字就ok了。 至于怎么实现这个方法，那是他们自己去处理。使用接口的人不关心具体的实现。。这样子分工协作很方便了

[wanghui0380]

这其实是哲学问题，不是计算机问题 现代软件学很多东西是从哲学，方法学，工程学过来的（相对30年前的近代软件学，那些是从数学学，物理学，统计学过来的，当然现在有回归的趋势，大数据，云计算这类玩意基本还是数学，统计学，概率论，所以python，lisp，R都复苏了） 回到你的问题，哲学各种分支都有一个类似分析过程 本体+客体 内涵+外延 主要矛盾+次要矛盾 物理存在+心理存在 自我+本我+超我 ------------------------ 那么运用这类分析，你就发现，无论你怎么定义。其实都逃不开上面那些哲学分析的套子 比如微软那个INotifyPropertyChange接口，可以用本体+客体来解释 object是本体，INotifyPropertyChange是客体。客体必须依靠本体实现，没有本体哪里来的客体？ 当然作为概念，客体可以被独立讨论，我们能不能忽略本体，独立讨论INotifyPropertyChange呢？ 当然可以，从你的例子来引申出来 IMyinterface Myinterface= new MyBaseClass(); IMyinterface是客体，他必须host到某个主体 MyBaseClass他自己不能独立存在，但是一旦主体MyBaseClass被new出来了，他就一定具备客体MyBaseClass的特征。 这个例子如果没学哲学的人很难明白，所以我们只能打比方了 胡歌是帅哥是把，问题是帅哥能独立存在么？你能new一个人脑里的帅哥出来么？（这里我采用存在主义哲学来描述，帅哥是唯心的存在，他不是物理存在，你可new不出），你没办法new一个帅哥存在 但是帅哥可以依靠某个物理的存在而表现。 I_帅哥 帅哥= new 胡歌(); 你觉着这样有错误么？完全没错误啊，难道胡歌不是帅哥么?胡歌不是一个具体物理存在帅哥实例么？

[夏天的枫]

其实真正的 还是new了一个MyBaseClass

[wanghui0380]

当然在我们软件界，有些东西也不好分 像主体+客体，物理存在+心理存在这种分析划分基本没有分歧 只是 主要矛盾+次要矛盾 内涵+外延 就不好讨论了。 因为这跟项目实施的方向有关，你可以把业务逻辑当内涵把外部表现当外延，这样发展出了MVVM（你会去继承业务逻辑，再实现数据绑定接口） 当然你倒过来看也一样，你可以把业务逻辑当外延，把通用表现当内涵，这样发展出了组件式编程（你的去继承UI控件，然后在实现业务逻辑）

[wanghui0380]

主要矛盾+次要矛盾 内涵+外延 这玩意其实真心也是目前的混乱所在，同样看一本书《DDD 领域分析》 我看完的结果是 （内涵）domain+I服务（外延）+I仓储（外延） 而XX园的一大波人的结论是 （内涵）仓储+Idomain（外延）+I服务（外延） 还得出什么单根，聚合根，单元什么区别，联系等等的东西

[wanghui0380]

像上面sp1234说的多继承问题，其实也是跟我上面说的一样的 因为设计哲学上，语言设计者其实并不参考java，而是参考哲学。他要求形式上有主体，有客体这种模式。 但是实际设计上涉及到那些有分歧的地方，比如如果按（主要矛盾，次要矛盾）（内涵和外延）来看，很多情况是形式限制的代码发挥，因为现实设计很多东西其实也没有明确的划分，多主体，多矛盾也并不是不存在，但是现在这种语法形式下，我们只能层层划分，一级一级隔离降解（必须有主体，才能有客体，环境不同需求不同，而语法形式如此，只能将到下一级在隔离封装划分）