设计模式浅薄理解

45 阅读3分钟

我正在参加「掘金·启航计划」

我相信大部分开发都会设计模式,但每个人在学习过程中理解到的或多或少存在差异,本文就谈谈个人对设计模式的一些浅薄理解。注:本篇并不会谈论设计原则。

本文主要针对以下问题进行展开:

  1. 何为设计模式?
  2. 设计模式是否一成不变?
  3. 有何优缺点?
  4. 用还是不用?

何为设计模式

如果只谈设计模式这个词,那范围还是挺广的。设计模式由Design Patterns翻译而来。Patterns(模式)表示一种可复制,可重复使用的流程结构或解决方案,如:

  1. 影视剧大多都是邪不胜正,各种主角光环,这可以看作是一种“剧情模式”。
  2. 你每天上下班,周末休息,这也属于一种模式。
  3. 流程层层审批,对应的又是一种模式。

生活中的模式还是挺多的,这些模式都是不断尝试,演进出来的,从而形成“可重复使用”。

Design意为设计,设计又分动词和名词。名词在我看来是一种宏观的概念,动词则是微观下的概念;比如:办公类别下设计模式,宏观:办公下设计模式有哪些,微观则是具体的每一个模式(朝九晚六是一种模式,996也是一种)。

小总结:设计模式并不是开发独享,生活中随处可见。在开发角度来看,宏观上设计模式指的就是GOF,微观上来看,23个“模式”都是GOF设计模式的一种。

设计模式是否一成不变?

自然不是一成不变的。从上述理解中,设计模式中的“模式”有多种,这些都是可复制,可重复使用的,但难免这些通用的模式中并不能说兼容所有业务。还是举例来说:大部分办公模式都是朝九晚六的,但这不适用所有公司,则会在这基础上魔改,转而变成符合业务架构的模式。

这种魔改后的也算是一种模式,但适用范围窄,使用条件可能相对苛刻,在我看来算是一种模式的“变形”。

有何优缺点?

优点就不细说了,什么可重用,方便扩展之类的,网上比比皆是。这里谈谈缺点。

  1. 对新手来说可能不太友好,不如形如if...else上手得快。“菜是原罪”,但我还是放到了缺点中。
  2. 可能会导致类的数量成倍上升,代码复杂性也会相对上升(同第一点一样)。
  3. 某些模式为了增加动态性,可能对性能会有一定影响。

综上所述,设计模式并不是完美无瑕的,但大部分都和个人水平相关。

用还是不用?

既然有优点,也有缺点,那到底该不该用?或者什么时候需要用?我的理解是:合理运用。

在利大于弊的时候可以使用,虽然会损耗些许性能,但收益可以弥补的。同时可以以其他方式减少性能的损耗,例如缓存。

对于以下情况:

public  void doSomeing(char sex){
    if(?sex){
        // xxx
    }else if(?sex){
        //xxx
    }
}

如上伪代码,我是不推荐使用设计模式的。有些开发看到可能会直接策略一把梭或者其他方式,但其实是没必要的,性别撑死就几种,是完全没有必要使用设计模式的。这种情况下还使用的话,在我认为可能是炫技行为。

总结

以上是我对设计模式的浅薄理解,或许存在理解有误,欢迎指正~

设计模式虽好,可不要贪杯,千万别为了用而用,也不要照搬模式结构,进行适当变更,组合灵活运用才是王道~