抽象类和接口的区别(不仅仅是概念)
我觉得抽象类除了只能单继承(不如接口)，其他完全可以代替接口啊，接口能干的，抽象类也能啊，为什么我们经常推荐使用接口，而不提倡说面向抽象类编程，接口和抽象类到底有哪些区别啊？求指教！！
------解决方案--------------------
呵呵，有些东西可以互换，有些东西不能互换

就像我上面说滴
“我们只能说他本质是上人，只是实现了一些变态滴接口”
但是我们不好说
“他本质上就是变态，只是批了一幅人皮”（好吧虽然这句话也有人说，不过嘛你是知道滴，这个只是强调他是变态，而不是真滴说这厮根本上就是变态这种属滴）
------解决方案--------------------
有很多事情其实你得自己去悟。

我不喜欢用什么生活中的事情打比喻，因为那样比喻越比越糟。我想说的是，当你用一种编程语言解决特定的编程任务的时候，你会有一些纯粹的需求，这种编程语言提供了这样的语法特性去满足这样的需求，这无法用什么好处、替换之类的去描述。就好比一个山洞里面跑出来的野蛮人跑到你家，什么都没有见过，盯着你问，碟子和碗相比有什么好处，筷子有什么好处之类的问题，你也很难去回答他一样。因为这个根本就不干好处的事。

你不是面向一种虚无缥缈的概念编程，你是面向一种实实在在的语言。接口这种语法特性不是必须的，C++没有，Go也没有，Javascript也没有。如果你要问“好处”，那是不是这些语言就不好了呢？不是这样。C#是一种静态的，强类型的语言，这意味着，当你调用一个对象的方法，编译器很在意你的对象是什么类型，它有没有这个方法，并且在编译阶段就将这种调用关系确定下来，即便是虚拟方法，也将查找虚拟方法的逻辑给确定下来。在这样一种语言上编程，你也必须很重视类型，你自然就有需求，需要一种方式表达一种类型，它拥有某种方法，用它代表一些具体的类型，而这些类型本身又没有任何关系，那么接口就是最好的选择。

你脱离了这个具体的场景，光根据比喻去理解，就发生问题了。我们说，js就没有接口。因为不需要。js是脚本语言，并不重视类型，如果一个对象有这样一个匹配的方法，那么它就可以被如此调用。对象自己描述了自己的类型，这就是弱类型语言的价值观。

你说哪一种正确呢？这个无解。特定的编程语言是为了解决特定的编程任务而设计的，同时也受到当时客观条件的制约。
------解决方案--------------------

引用:

我觉得抽象类除了只能单继承(不如接口)，其他完全可以代替接口啊，接口能干的，抽象类也能啊，为什么我们经常推荐使用接口，而不提倡说面向抽象类编程，接口和抽象类到底有哪些区别啊？求指教！！

设计上所谓的面向接口编程，包括任何一种class。因为class只是实现，它们在设计上都是完成了接口的功能（只不过各有各的扩展）。

不要把低级的东西代替高级的东西，就好像有人整天死抠什么“.net本质论”，但是要知道，拿一个.net1.0的书根本代表不了.net1.1，也代表不了更高级版本，以及同一版本在不同目标平台上的实现。要能分清楚所谓“本质论”的缺点，死抠底层“本质”并不能保证你理解了早在这不同的底层实现出现之前所追求的设计概念。

当你纠结于某一个编程语言的“接口”概念的时候，可能你没有没有见过别的语言的“接口概念”。例如c++根本没有接口，甚至有的语言根本就叫做“面向合同”而不是“面向接口”，甚至更早的一些优秀的编程语言根本就只有类型系统而已。但是那些软件设计师以及同时代的资料，都出现了接口的设计概念。

在设计上，接口根本不是特指.net或者java的接口。这是起码的道理