接口和抽象类的理解1

接口类似契约（合同），既然是契约（合同）必然有合同双方

接口的几个要素：1提供者（甲方）2使用者（乙方）3 接口（合同）4 目的 （原因）

接口的制定者 多数为甲方，少数为甲乙双方共同约定，决不会是乙方单独制定。

比如要实现foreach迭代，类就必须继承IEnumerable 和 IEnumerator 接口，这样类必须有 GetEnumerator、MoveNext、Reset 和 Current 方法，否则就编译不过。而这些方法又是foreach语法器所必需的
制定者：微软，使用者：程序员 ，接口： IEnumerable 和 IEnumerator ，目的：实现foreach语法

就像小红必须要戴红领巾（这是接口），为什么？因为小红是一个少先队员（这是实现接口的原因）。 其实你的主要目的是当少先队员，戴红领巾是你被动和必须接受的。
制定者：少先队，使用者：小红 ，接口：戴红领巾，目的：加入少先队

再比如你申请连锁店，被要求资金，店面装修，培训，押金等，其实你的目的是申请连锁店，资金，店面装修，培训，押金等都是你不愿意也要愿意的条件，（如果你是确定要开这个连锁店）。
制定者：总店，使用者：分店，接口：资金，店面装修等 目的：加盟
同样我们给别的程序员一个接口，或接受别的程序员一个接口。都是提供者为了必需的目的提供接口，实现者是“无奈”的实现。
所以程序集合内部建议用抽象类，程序集合外部的或第三方参与的建议用接口。

我们对接口和抽象类的理解不能只说接口能干什么抽象类不能干，或抽象类能干什么接口不能干，什么单继承和多继承，方法有没有代码体，有没有构造函数等等，这些其实都是果，是表象，找到因，才是我们的追求，找到因，自然也就明白为什么是这样一个结果了。

关理解接口和抽象类这两个事物各自存在的原因，还是要从需求的角度去思考，面向对象的大师们是遇见了什么难题才想出接口这个概念，遇见了什么困难才创造了抽象类这个概念。

不能为了接口而接口。就好多设计模式的书里都是在工厂模式用接口实现后绑定，我个人认为，如果在类内部使用，完全可以用抽象类来代替接口。

那些自己给自己写接口的，或没有什么目的而存在的接口，有必要好好想想那些接口可以换成抽象类，那些接口是可以去掉的，那些接口是真正需要保留的。

个人的理解 对于接口和类的关系，应该叫 接口被 类 实现更合适，那些叫继承和多继承的，我不认同。

类实现多个特定功能，自然是合情合理的。

至于那些说接口支持多继承的书，你抄我来，我抄你的，我觉得抄来抄去的完全没有新意。

说 “继承接口”的人压根就是 读死书。

类和结构可以在不实现接口时就先存在了，怎么能叫继承？
小红是先当人，还是先当团员（团员比喻为接口）？
他不当团员了会死吗？

虽然现实中有些类就是为了某个接口才存在的，但去掉这个接口类还是完整的，只是受了某些限制。
意思是所有的功能都还在，但因为没了合同，所以有功能也要受限制。

类去掉IEnumerable 和 IEnumerator 接口后
GetEnumerator、MoveNext、Reset 和 Current 方法还在（功能还在）
但就是不能用foreach语法器。
要实现foreach迭代，就必须继承IEnumerable 和 IEnumerator 接口，这叫按合同办事
你光有大学的能力，没有文凭，你可能拿更高的工资，但你就是不能叫大学生。