首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  程序员

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

  •  
  •   ZhengZW · 61 天前 · 4132 次点击
    这是一个创建于 61 天前的主题,其中的信息可能已经有所发展或是发生改变。

    除了工厂和单例和代理,有没有用到其他的,工作到现在用最多就工厂和单例,想问问你们用过哪些,应用啥场景?

    34 回复  |  直到 2019-08-18 10:12:25 +08:00
        1
    yule111222   61 天前   ♥ 1
    挺多的,适配器最多,调用远程接口或者接口变换的时候用
    长业务流程责任链
    构建复杂对象建造者
    迭代一个自定义复杂数据结构,迭代器
    生产消费者(生产令牌,IP,线程等各种资源提供给消费者使用)
    接口聚合,门面模式
    工厂和单例和代理就不说了,你也用了
        2
    cwjokaka   61 天前
    模板方法,最近写了个服务初始化配置的脚本,把一些固定的流程 /异常处理写在抽象类中,达到代码的最大重用
        3
    Caballarii   61 天前
    学过设计模式至少能让你有好好组织拆分代码的意识,动手之前多想想后面的事
        4
    taogen   61 天前 via Android   ♥ 3
    时间紧,先 Ctrl C, V 把功能实现完,打算有时间优化,然后就没有然后了。造成大量代码冗余 🤣
        5
    IsaacYoung   61 天前 via iPhone
    我用的最多的是 todo 模式

    //TODO: DRY
        6
    nekoyaki   61 天前
    也分语言,在某语言里需要长篇累牍,特意起一个高端大气上档次的名词,包装成一个设计模式,可能在另一个语言里一行就完事儿了。
        7
    skypyb   61 天前
    多,策略、责任链、工厂、建造者 都有用到
        8
    mirrorman   61 天前
    记得前段时间找实习面我的 Leader 让我写 Observer 模式和 Builder 模式,然后对我说一看就没看过源码,一脸懵逼
        9
    Raymon111111   60 天前
    模板应该是比较多的
        10
    orzorzorzorz   60 天前   ♥ 1
    设计模式这玩意从来都是水到渠成的事,强行上虽然解渴,但是不甜
    是的,我几乎用不到设计模式
        11
    stevenkang   60 天前
    请教大家一下,这算不算一种模式呀?

    原来的
    ```
    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   60 天前
    主要用到过适配器模式,还是在子类型比较多的时候总体优化了一下才用的
        13
    12tall   60 天前
    挺多的,但是刻意学却总也记不住,直到有一天业务需要了,马上就明白了,大概是这个样子
    一些重构的骚操作大概也是这个样子
        14
    freebird1994   60 天前
    @stevenkang 用策略模式更好,你这个维护的时候还是会修改原有的代码,策略模式只对扩展开放,对修改关闭。
        15
    Joyboo   60 天前
    设计模式非常常用
        16
    javaWeber   60 天前   ♥ 1
    我学了几次。。但是学了又忘了。

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

    一直处于理论阶段,没有实操过。
        17
    yukong   60 天前
    @stevenkang #11 建议使用策略模式使用策略模式 之后如果有新的规则 只需要实现策略接口 重写策略方法 不会对原代码进行修改
        18
    Takamine   60 天前 via Android
    @stevenkang 虽然改了一下形式,但是感觉耦合度还是差不多的。比如添加一个 A4 的时候,依然还是要在这里做操作。
        19
    MeteorCat   60 天前 via Android
    单例模式最多
        20
    zjsxwc   60 天前 via Android
    也就拼 sql 时 builder 模式天天用
        21
    Shiyq   60 天前
    都是大佬,我最多继承几个基类搞搞,也不知道那是不是设计模式
        22
    JerryCha   60 天前
    没具体看过设计模式,看 Google 官方的 Android 案例看得挺懵的
        23
    oneisall8955   60 天前 via Android
    @stevenkang 类似策略模式
        24
    justin2018   60 天前
    先完成需求 然后等有时间了在重构~~

    一般有时间的情况非常少~~ 😔
        25
    justfortest   60 天前
    一般单例、工厂、适配器之类的都会用到
        26
    BigDogWang   60 天前
    @yukong 我思量着策略模式新增策略不是也要修改工厂类吗
        27
    pastgift   60 天前   ♥ 2
    设计模式是编码经验的总结,所以实际上是现有代码,后有设计模式。

    代码写多了,写出来的代码自然就带这某种设计模式。
    而不是说为了用某个设计模式然后照着写代码,模式就是套路( pattern ),是一种指导,不要搞成 template 了
        28
    BigDogWang   60 天前
    @yukong 新增策略不需要改动工厂类吗
        29
    ChefIsAwesome   60 天前 via Android   ♥ 1
    最常见的,套一层模式。例如写 API,调 API 的时候,通常在真正的实现前面加一层,这里头有可能有 proxy,有可能有装饰器,有可能有适配器。
    所有的封装,都是 facade。
    现在做界面,都是 mvc。
    队列,错误回滚,是 command。
    俩模块通过共享的父模块通信,是中间人模式。
    各种配置初始化的过程,都包括 template method。
    有些做游戏的,为了帧数稳定,会搞个内存池,自己控制内存释放。
    做响应式开发的 rx,有迭代器,有 observer,有 command,有惰性求值。rx 是个函数式编程的产物。
    做前端写 react 的应该熟悉:HOC 是装饰器。各种 life cycle 的配置是模板方法。对比以前的 mixin 和现在的 hook,是明显的 Composition over inheritance 的设计思维。

    设计模式是问题+解决策略+实现方法。有的问题是面向对象独有的,有的是不分编程语言的。那些个模式到处都在用,死记硬背没意义。
        30
    fredshao   60 天前
    其实并没有严格按照书本上的设计模式什么的,那只是一种思路,只要逻辑清晰,顺手,不影响性能,怎么写都可以,没有必要严格按照书本上的代码模式写
        31
    q397064399   60 天前   ♥ 2
    1. 不必严格按照模式去做,去生搬硬套
    2. 关键掌握设计模式的或者说是各种模式的真正精髓 SOLID 原则
    其实在我看来就 Bob Martin 在敏捷软件开发中讲的那样
    面向对象或者套用各种模式 最终的目的是 -- 隔离变化,我们创建抽象的本质是将不易变的跟容易变的部分隔离开来

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

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

    swap(a,b)

    compare(a,b)

    get(a,b)

    当这个约定被解构出来的时候,我们双重 for 循环的冒泡算法就再也不用修改了,这样会大大减少程序员的心智负担,对于新增的排序需求,我们只要让它符合中抽象就可以了
        32
    Solace202   60 天前 via Android
    马士兵老师说过,如果学习设计模式的难度是 50,那么用到项目中的难度就是 300,这个我是一只赞同的
        33
    LeeSeoung   60 天前
    其实写的很多代码都是设计模式的变种或者组合
        34
    hhhsuan   58 天前
    @stevenkang #11 算是一点策略模式再加一点数据驱动吧。还可以写的更好一点,比如做成动态注册的形式,这样添加新的 type 就不需要修改那个 static 代码块。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4282 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 26ms · UTC 06:41 · PVG 14:41 · LAX 23:41 · JFK 02:41
    ♥ Do have faith in what you're doing.