为什么很多讲设计模式的博客，讲解的代码例子都是基于“继承抽象类或实现接口“，设计模式规范很严格么？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1561 天前的主题，其中的信息可能已经有所发展或是发生改变。

为什么大部分讲 java 的设计模式，还有 c#的设计模式的博客的代码例子都是基于实现接口或继承抽象类？

设计模式不是脱离语言的么，除去必须要考虑继承抽象类，实现接口的设计模式，其他的设计模式与继承抽象类或继承接口有什么必然联系么？我怎么感觉老是用实现接口继承抽象类的例子去讲设计模式有点误导人的感觉？还是习惯了，或者继承接口抽象类的代码例子很合适？还是说设计模式的规范真的很严格？还是抄袭 csdn 博客？那些博客讲设计模式不用“实现接口继承抽象类的代码“的该类例子讲解不行么。

举一个例子，装饰器模式，一些讲装饰器这种设计模式的很多博客，代码例子基本都是实现接口走起，可在我看来，装饰器模式，即使用代码例子说明，有必要搞得这么复杂啰嗦么？我要扩展一个类的功能，我直接创建一个普通类作为装饰类，通过构造函数传入即可，并扩展装饰类的功能，除非有需求必要，不然不会“先写个接口再去实现接口”这种罗里吧嗦的步骤。

难道是“为了接口而写接口”的这个习惯传染了很多人？

接口

模式

抽象

继承

17 条回复 • 2020-08-14 14:18:48 +08:00

shenwu35

2020-08-14 10:01:13 +08:00

其实设计模式就像一把剑，最高境界是手中无剑，心中有剑
接口爆炸不是闹着玩的。

zjsxwc

2020-08-14 10:10:11 +08:00

这只能说明你对使用接口没有需求，你的业务也不够复杂。

murmur

2020-08-14 10:11:58 +08:00

等你用 spring 的时候不自觉的就这么做了，框架帮你做了设计模式你用就可以了

tctc4869

2020-08-14 10:14:58 +08:00

@zjsxwc 这是另一个问题，需不需要设计接口，我自有考虑，开发复杂的项目肯定是要会有考虑要接口的情况，

SurfaceView

2020-08-14 10:17:57 +08:00

不同开发经验和不同开发经历去看这个 interface 的概念肯定是不同的.
面向接口编程和完成类底层实现是两回事，互相并不冲突.
接口更多的是你对一个业务的理解，我这个东西需要有什么功能，你这个业务系统跟别的系统打交道的时候，
或者你的一个模块跟其他模块交互的时候，没人关心你的 impl，别人只需要关心你的 interface 就好了

gdtdpt

2020-08-14 10:37:44 +08:00

设计模式的目的主要是解耦，让用户使用抽象的与细节无关的东西，不是为了接口而写接口。
这样做的好处是
1.对调用方只需要在意抽象的东西，不需要管理具体实现，具体来说就是我不用在意通过依赖注入或工厂方法拿到的一个东西它到底是 AImpl 还是 BImpl，总之它是这个抽象(interface)的 Impl 我就都能用。
2.对服务提供方我只需要在正确的地方提供相同抽象的不同实现，调用方代码都是一样的，只需要维护服务提供方的代码。
3.调用方和服务提供方都只需要遵守抽象的规则(interface)，两方之间不需要沟通。

在 C 井和 Java 中，最没有细节的抽象就是 interface，基于 Java 、C 井这种纯面向对象的语言就会变成“基于 interface 编程”。

当然现在很多教程都是照本宣科，到底需不需要 interface 我个人的看法是看代码是不是真的需要抽象，比如 MVC 结构的 web 项目，我的 Service 层就这么一套逻辑，一般我是不创建 interface 的，因为我觉得这里我不需要抽象，如果业务需要一个 Service 内的方法存在不同的实现，那么我才会创建 interface 。

jones2000

2020-08-14 12:03:42 +08:00

自己一个人开发，什么设计模式都可以，反正就你 1 个人，爱怎么玩就怎么玩，能实行功能就可以了。

多人开发的时候，接口定义就重要了, 大家都是根据接口设计同步开发的，你把对外的接口定义好了，在接口实现的地方，返回假数据，这样其他人直接就可以用你的接口继续开发下去。而不是等你开发完，他再开发。大家都是并行的开发，而不是串行的。

一般场景是这样的。
老板问：这个项目你一个人要几天完成？
你回答：60 天，
老板说：太久了，这个项目客户很急，我给你加 10 个人，你 6 天完成。
你回答: ........

namelosw

2020-08-14 12:13:07 +08:00 via iPhone

说了半天都是面向 Java 的.

Go 就简单很多. 抽象就抽象，不一定非得是接口.

另外像函数式风格抽象的第一选择是参数化而非接口.

另外泛型也叫参数化多态. 是对泛型的抽象.

只用 Java 或者类似的语言，抽象思维就只限制在子类多态上了（接口，继承）. 导致僵化和过度设计必须二选一.

nl101531

2020-08-14 12:29:47 +08:00 via iPhone

都是中间层。。。写不写接口看你业务需要不需要

las917vki

2020-08-14 12:30:57 +08:00

要从最底层了解设计模式，接口抽象复用耦合关系，二进制分层。
请去看微软的 COM 。

taowen

2020-08-14 12:51:27 +08:00

因为书上举的例子都不是实际的业务场景。如果给一些相对真实点的例子会好一些。接口是次要的，那只是一个解决方案。得先从问题入手，你要接什么样的需求，为什么这些需求会导出你要使用接口这个解决方案。我在文章中给了一些这样的例子 https://gitee.com/taowen/modularization-examples