小白提问，关于接口
某个类继承了某接口，然后要在实现代码里写那个接口里定义的函数（方法）。这个是教材说的。

但是我一直很疑惑。所谓的类，不就是我们要根据系统的功能而写的包括字段和方法的综合体吗？假如我想要类能干某事，我直接在类里面写上这个方法就OK了，为什么先要把方法定义到其他的地方，然后再让我的类继承这个接口？

我在写程序的时候，哪里能想到A类需要干某事，B类也需要干类似的事情，从而把相似的动作提取出来弄成接口？不可能一开始就能吧什么都规划得这么好吧。

那按照面向对象的思路，我是不是在写程序的时候，写着写着，发现一些可以综合的功能了，就停下来把这些东西综合成接口，然后修改前面的程序，让他们来继承这个接口？按这样的思路，岂不是永远都没法完成了系统了啊。
------解决方案--------------------
在C#当中，类只能单一继承，接口可以多继承。互相补充。
------解决方案--------------------
我觉得初学的话不必要太在意这个，放手写程序吧，在重构过程中提炼接口，接口的出现不就是应对变化么？


------解决方案--------------------
2种情况：
一、使用已有的接口，必须遵循它的规范。
二、使用自己的接口，先写无接口的类，提取公共部分变为接口。

不要以为接口是万能的，必须的，如果只有一个类，没必要再回过来写接口，如果很多类但是不需要统一入口访问，各自单独调用，也不需要提取接口，只有当你需要一个统一入口访问，提供标准化调用的时候，才需要提取接口。
------解决方案--------------------
有所领悟是好事，你后面说的那一段，有些是应该放在抽象类里，抽象类实现接口，子类再继承抽象类（也就继承了那些被你综合了的功能），子类还可以重新实现这些功能
等你做稍微大一点的项目，就能深刻体会了

------解决方案--------------------
“面向接口编程”，这个理念听说过吗？我们有时候一个系统很大，但是我们发现很多功能是重复的。比如几乎每个系统都会有日志功能，提醒功能，权限系统等。如果我们每次开发都重新开发一套有这个必要吗？那好从现成的拿过来用就行了。就想usb接口一样，插上去就能用。
你说的是小程序，小程序是可以不用直接几行代码反而更简单，等系统大了，你会发现很难维护修改。而如果提炼成一个一个的接口，降低了程序的耦合，排除故障也好，维护也好，都是很享受的一件事。
------解决方案--------------------
额，恭喜你，你ls很多星星们都要清醒。

无论，下棋，设计，打仗还是画画，都不是所谓滴接口如何如何滴。

东西其实就像你感觉到的
1.也许一开始只是一个大概的感觉，具体怎么做其实还不太清楚。所以这时候就有抽象类，就有接口。暂时忽略具体的玩意

2.有了这些抽象的感觉以后，你可以稍微进行一些细致的演化。围棋里叫手割，艺术设计里叫草图/底稿，打仗叫沙盘推演，其他领域里一样（比如：飞机模型，大坝模型风洞测试）

3.在演化的基础上将你的抽象稳定下来

总体上设计是个动态过程，并不是大多数人认为的那就是几个死口号，死结果。哪怕一说接口，就会有一群人告诉你usb这个死结果如何如何，但是usb同样也是经过好几代的演变才稳定下来的东西


------解决方案--------------------
简单的说，接口只是方便调用者，使得调用者能使用更多的模块功能（只要这些功能模块实现了对应接口）。如果你只是一个模块内的调用，就不要用接口来做。对于被调用者（接口实现类）来说，接口只能增加代码量。
------解决方案--------------------

引用:

Quote: 引用:

面向接口这句话我也听说过，好像也很有道理。但是实际上却一直没觉得有什么用。

比如有个基类，里面有eat和walk两个方法，他派生出了很多个子孙类。现在要求为这些子孙增加sleep功能，就直接在基类里写上sleep的代码，就OK了。这样维护是很方便。

但是接口呢？如果有N多个各种各样的类继承了某接口（该接口定义了eat和walk），现在这些类都需要增加sleep功能，那我在接口里写上sleep的定义，然后呢？还不是要在这N多个类里面去写这个sleep的代码。这维护工作不简单啊。