各位在工作中设计模式到底用得多吗？

工厂

问问

代理

场景

34 条回复 • 2019-08-18 10:12:25 +08:00

1

yule111222

2019-08-15 11:57:00 +08:00

1

挺多的，适配器最多，调用远程接口或者接口变换的时候用
长业务流程责任链
构建复杂对象建造者
迭代一个自定义复杂数据结构，迭代器
生产消费者（生产令牌，IP，线程等各种资源提供给消费者使用）
接口聚合，门面模式
工厂和单例和代理就不说了，你也用了

2

cwjokaka

2019-08-15 12:02:08 +08:00

模板方法，最近写了个服务初始化配置的脚本，把一些固定的流程 /异常处理写在抽象类中，达到代码的最大重用

3

Caballarii

2019-08-15 12:11:37 +08:00

学过设计模式至少能让你有好好组织拆分代码的意识，动手之前多想想后面的事

4

taogen

2019-08-15 12:12:13 +08:00 via Android

4

时间紧，先 Ctrl C, V 把功能实现完，打算有时间优化，然后就没有然后了。造成大量代码冗余 🤣

5

IsaacYoung

2019-08-15 12:14:33 +08:00 via iPhone

我用的最多的是 todo 模式

//TODO: DRY

6

nekoyaki

2019-08-15 12:26:08 +08:00

也分语言，在某语言里需要长篇累牍，特意起一个高端大气上档次的名词，包装成一个设计模式，可能在另一个语言里一行就完事儿了。

7

skypyb

2019-08-15 12:44:19 +08:00

多，策略、责任链、工厂、建造者都有用到

8

mirrorman

2019-08-15 12:50:55 +08:00

记得前段时间找实习面我的 Leader 让我写 Observer 模式和 Builder 模式，然后对我说一看就没看过源码，一脸懵逼

9

Raymon111111

2019-08-15 14:48:50 +08:00

模板应该是比较多的

10

orzorzorzorz

2019-08-15 14:52:05 +08:00

1

设计模式这玩意从来都是水到渠成的事，强行上虽然解渴，但是不甜
是的，我几乎用不到设计模式

11

stevenkang

2019-08-15 14:53:33 +08:00

请教大家一下，这算不算一种模式呀？

原来的
```
void typeProfcess(type) {
if (type == 'A1') {
// todo something
} else if (type == 'B2') {
// todo something
} else {
// todo something
}
}
```
改造后
```
static {
typeprocess.put('A1', a1TypeProcessListener)
typeprocess.put('A2', b2TypeProcessListener)
default = defaultTypeProcessListener
}

void typeProfcess(type) {
listener = typeprocess.containsKey(type) ? typeprocess.get(type) : default
listener.exec()
}

```
这样无论以后的 type 多复杂，只需要初始化的时候 put 进去对应的处理就好了。
特别是第三方系统各种报文 type，以前用 if 或者 switch 处理，这样改造了会不会更好？

12

airfling

2019-08-15 14:56:51 +08:00

主要用到过适配器模式，还是在子类型比较多的时候总体优化了一下才用的

13

12tall

2019-08-15 15:55:23 +08:00

挺多的，但是刻意学却总也记不住，直到有一天业务需要了，马上就明白了，大概是这个样子
一些重构的骚操作大概也是这个样子

14

freebird1994

2019-08-15 16:12:21 +08:00

@stevenkang 用策略模式更好，你这个维护的时候还是会修改原有的代码，策略模式只对扩展开放，对修改关闭。

15

Joyboo

2019-08-15 17:16:20 +08:00

设计模式非常常用

16

javaWeber

2019-08-15 17:19:12 +08:00

1

我学了几次。。但是学了又忘了。

重构代码时，发现很多重复代码。但是又不知道用哪个设计模式。

一直处于理论阶段，没有实操过。

17

yukong

2019-08-15 17:19:39 +08:00

@stevenkang #11 建议使用策略模式使用策略模式之后如果有新的规则只需要实现策略接口重写策略方法不会对原代码进行修改

18

Takamine

2019-08-15 18:38:20 +08:00 via Android

@stevenkang 虽然改了一下形式，但是感觉耦合度还是差不多的。比如添加一个 A4 的时候，依然还是要在这里做操作。

19

MeteorCat

2019-08-15 19:03:52 +08:00 via Android

单例模式最多

20

zjsxwc

2019-08-15 19:19:03 +08:00 via Android

也就拼 sql 时 builder 模式天天用

21

Shiyq

2019-08-15 19:56:58 +08:00

都是大佬，我最多继承几个基类搞搞，也不知道那是不是设计模式

22

JerryCha

2019-08-15 20:11:59 +08:00

没具体看过设计模式，看 Google 官方的 Android 案例看得挺懵的

23

oneisall8955

2019-08-15 20:53:09 +08:00 via Android

@stevenkang 类似策略模式

24

justin2018

2019-08-15 20:59:12 +08:00

先完成需求然后等有时间了在重构~~

一般有时间的情况非常少~~ 😔

25

justfortest

2019-08-15 21:56:05 +08:00

一般单例、工厂、适配器之类的都会用到

26

BigDogWang

2019-08-15 22:34:54 +08:00

@yukong 我思量着策略模式新增策略不是也要修改工厂类吗

27

pastgift

2019-08-15 22:35:49 +08:00

2

设计模式是编码经验的总结，所以实际上是现有代码，后有设计模式。

代码写多了，写出来的代码自然就带这某种设计模式。
而不是说为了用某个设计模式然后照着写代码，模式就是套路（ pattern ），是一种指导，不要搞成 template 了

28

BigDogWang

2019-08-15 22:38:06 +08:00

@yukong 新增策略不需要改动工厂类吗

29

ChefIsAwesome

2019-08-15 23:41:22 +08:00 via Android

2

最常见的，套一层模式。例如写 API，调 API 的时候，通常在真正的实现前面加一层，这里头有可能有 proxy，有可能有装饰器，有可能有适配器。
所有的封装，都是 facade。
现在做界面，都是 mvc。
队列，错误回滚，是 command。
俩模块通过共享的父模块通信，是中间人模式。
各种配置初始化的过程，都包括 template method。
有些做游戏的，为了帧数稳定，会搞个内存池，自己控制内存释放。
做响应式开发的 rx，有迭代器，有 observer，有 command，有惰性求值。rx 是个函数式编程的产物。
做前端写 react 的应该熟悉：HOC 是装饰器。各种 life cycle 的配置是模板方法。对比以前的 mixin 和现在的 hook，是明显的 Composition over inheritance 的设计思维。

设计模式是问题+解决策略+实现方法。有的问题是面向对象独有的，有的是不分编程语言的。那些个模式到处都在用，死记硬背没意义。

30

129ykx733D016U2n

2019-08-16 00:21:01 +08:00

其实并没有严格按照书本上的设计模式什么的，那只是一种思路，只要逻辑清晰，顺手，不影响性能，怎么写都可以，没有必要严格按照书本上的代码模式写

31

q397064399

2019-08-16 06:03:12 +08:00

2

1. 不必严格按照模式去做，去生搬硬套
2. 关键掌握设计模式的或者说是各种模式的真正精髓 SOLID 原则
其实在我看来就 Bob Martin 在敏捷软件开发中讲的那样
面向对象或者套用各种模式最终的目的是 -- 隔离变化，我们创建抽象的本质是将不易变的跟容易变的部分隔离开来

举个简单的栗子：
我们有一个冒泡排序算法通常的写法是
for ..
for ..

但是你想过一个问题没有，冒泡排序的算法框架大致上是不变的，变化的是什么，被排序的数据结构，
你可能要为一群人这个集合排序有可能要为一堆数字排序，它们这些抽象的数据表示可能存在不同的数据结构里面
有可能是 Map 有可能是 Set 有可能是 List
那么隔离它们的这些变化的方式就是提供一个抽象的约定，将高层次的逻辑与低层次的数据隔离开来

swap(a,b)

compare(a,b)

get(a,b)

当这个约定被解构出来的时候，我们双重 for 循环的冒泡算法就再也不用修改了，这样会大大减少程序员的心智负担，对于新增的排序需求，我们只要让它符合中抽象就可以了

32

Solace202

2019-08-16 08:02:56 +08:00 via Android

马士兵老师说过，如果学习设计模式的难度是 50，那么用到项目中的难度就是 300，这个我是一只赞同的

33

LeeSeoung

2019-08-16 14:01:00 +08:00

其实写的很多代码都是设计模式的变种或者组合

34

hhhsuan

2019-08-18 10:12:25 +08:00

@stevenkang #11 算是一点策略模式再加一点数据驱动吧。还可以写的更好一点，比如做成动态注册的形式，这样添加新的 type 就不需要修改那个 static 代码块。