最近在改造一些历史的代码,发现一个很明显的特点,大部分代码是记叙文,按照事件的发展过程将故事平铺直叙的讲解出来。
这种方式的好处是比较符合人类的思维习惯,一条主线讲到底,代码阅读起来没有太大难度,只要顺着藤就能摸到瓜,但是缺点也很明显,一旦故事线中需要插入一些新的元素,比如:加入一个新的人物角色、新的时间线,都会需要大量更改故事线以配合这个新元素的融入,甚至对原有文章造成破坏性的影响。
为了解决这个问题,人们总结出了很多种文章结构,例如:总-分结构,并列结构,总-分-总结构等等,有了这些结构,在加入新元素的时候,甚至不必考虑新元素与原故事情节的关联性,直接单拉一个分支故事线独立去讲就好了,只要能够在整体故事结束前,与汇聚到主线故事就可以了(是不是很像git?)。
在软件开发领域,也有很多这样的非常有用的实践总结,我们称之为设计模式。对于设计模式,大家都不陌生,随便找个人,估计都能讲出N个设计模式来,但是除了这些设计模式的概念,很多人不知道如何灵活运用这些设计模式。所以借这篇文章和大家共同学习设计模式的思想。
我尽量用最通俗易懂的示例和语言来讲述我理解的设计模式,希望能对大家有所帮助。
另外也无需精通所有的设计模式,只要能够融汇贯通常见的设计模式,就能让你的代码变得优雅。就像程咬金只会三板斧,但是熟练度无人能及,照样能横行天下。
1 工厂模式(Factory)
简单工厂(Simple Factory)
小明追妹子的时候,请她喝了不少咖啡,她爱喝卡布奇诺,每次去咖啡店,只要跟服务员说“来杯卡布奇诺”就行了,虽然各家的口味有些不同,但是不管是星爸爸还是Costa,都能够提供卡布奇诺这种咖啡。这里的星爸爸和Costa就是生产咖啡的工厂。
(1)简单工厂模式结构
简单工厂模式包含如下角色:
(2)优缺点
工厂方法(Factory Method)
以前经常带老婆去优衣库(简单工厂)买衣服,就那么多款式,逛的次数多了,她就烦了。后来我改变策略,带老婆去逛商场(抽象工厂),商场里有各式品牌的店铺,不用我管,她自己就能逛上一整天。
区别于简单工厂,核心工厂类(商场)不再负责所有产品的创建,而是将具体创建的工作交给子类(服装店)去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口(门店),而不接触哪一个产品类应当被实例化这种细节。
(1)工厂方法模式结构
工厂方法模式包含如下角色:
工厂模式总结
(1)适用场景
输出的产品是标准品,谁来做都可以。
(2)举例
常见的数据库连接工厂,SqlSessionFactory,产品是一个数据库连接,至于是oracle提供的,还是mysql提供的,我并不需要关心,因为都能让我通过sql来操作数据。
(3)注意事项
项目初期,软件结构和需求都没有稳定下来时,不建议使用此模式,因为其劣势也很明显,增加了代码的复杂度,增加了调用层次,增加了内存负担。所以要注意防止模式的滥用。
(4)简单实现