用模式思考

文中内容收集整理自《Head First 设计模式 中文版 》，版权归原书所有

设计模式的目的

管理软件的复杂度和变化.

如何正确的使用模式

当你确信你的设计中有一个问题需要解决的时候,或者当你确信未来的需求可能会改变时,都可以采用模式.然而模式可能带来复杂性,如果没有必要,我们绝不需要这样的复杂性.
1. 应该保持简单, 在实际的开发中, 目的是以简单的方式解决某个问题, 而为了模式而模式, 这样只会让系统更加复杂.我们应该在有更简单的办法的时候果断采用这个办法, 以达到既解决问题又不给系统增加任何的复杂度.
2. 不要假想任何改变而加入不必要的模式, 应该以实际业务为主, 不要去假想着业务将来如何改变, 这同时也要求开发人员能够熟练的掌握业务.
3. 重构, 重构是面向对象开发中非常常见的事情.当我们在重构时,就说明既有设计不够好,代码结构已经比较混乱, 这个时候可以思考设计模式所能带来的帮助, 这是一个使用模式很好的时机
4. 不要害怕删除模式, 如果一个系统足够复杂, 在有些地方不需要预留弹性而且删除模式能够使系统结构趋向于清晰简单时, 果断删除模式.
5. 现在不需要, 就别做! 要抗拒”创建漂亮的架构以应对任何方向的改变”这样的诱惑! 不要假想任何理由去添加一个设计模式, 这样只会让系统越来越复杂

以下为书本原文:

保持简单(Keep It Simple/KISS)

在设计时,尽可能的用最简单的方式解决问题. 目标应该是简单而不是”如何在这个问题中应用模式”.千万不要认为:如果没有使用某个模式解决某个问题,就不是经验丰富的开发人员.如果你能够保持简单的设计,那么你将会得到其他开发人员的欣赏和尊敬.正确的说法是,为了让你的设计简单且有弹性,有时候使用模式是最好的方法.

何时需要模式

当你在设计的时候,如果确定在你的设计中可以利用某个模式解决某个问题,那么就使用这个模式! 如果有更简单的解决方案,那么在决定使用模式之前应该先考虑这个方案.
如何知道何时使用一个模式,这就需要经验和知识.一旦你确定一个简单的解决方案无法满足你的需要,应该考虑这个问题以及相关的约束–这可以帮你将问题对应到一个模式中.如果你对于模式有很深的认知,就可能知道有什么模式适合这样的情况.否则,就花时间调查一下可能会解决这个问题的模式,模式类目中的意图和应用部分会特别有用.一旦找到了一个看起来适合的模式,要先确定你是否能接受这个模式所带来的后果,以及对设计其他部分的影响.如果一切看起来都很好, 就用它吧!
有一种情况, 即使有更简单的解决方案,你仍然想要使用模式,这种情况就是: 你预期系统在未来会发生改变.正如我们所见过的,找出你的设计中会改变的区域,通常这是需要模式的迹象.但是务必要确定一件事:加入模式是要应对可能发生的实际改变,而不是假想的改变.

重构(refactoring)的时间就是模式的时间

重构是通过改变你的代码来改进它的组织方式的过程.目标是要改善其结构, 而不是行为.这是一个很好的时机,可以重新检查你的设计来看看是否能够利用模式让他拥有更好的结构.比方说,代码内如果充满了条件语句,这可能意味着需要使用状态模式,或者意味着,应该利用工厂模式将这些具体的依赖消除掉.

拿掉你所不需要的,不要害怕将一个设计模式从你的设计中删除

何时应该删除模式呢?当你的系统变得非常复杂,而且不需要预留任何弹性的时候,就不要使用模式.换句话说,也就是当一个较简单的解决方案比使用模式更恰当的时候

如果你现在不需要, 就别做

设计模式威力很强大,你很容易就可以在当前设计中看到模式的各种应用方式.开发人员天生就热爱创建漂亮的架构以应对任何方向的改变.
要抗拒这样的诱惑呀!如果你今天在设计中有实际的需要去支持改变,就放手采用这个模式去处理这个改变吧~然而,如果说理由只是假想的,就不要添加这个模式,因为这只会将你的系统越搞越复杂,而且很可能你永远都不需要它!