RefactoringtoPatterns——简介

模式是面向对象设计的基石，而测试优先的编程方法和大刀阔斧的重构则是进化式设计的基石。为了避免过分设计或者设计不足，我们有必要学习如何让模式适应新的、渐进式的软件开发节奏。

——Joshua Kerievsky

软件模式的伟大之处就在于：它们传递了许多有用的设计思想。那么，如果学了一大堆模式，你就能成为一个相当优秀的软件设计师，对吗？当我学了、用了几十个模式之后，我也这样想过。这些模式帮助我开发了更灵活的框架，建造了更坚固、更具扩展性的软件系统。但是，两年以后，我发现：对模式的了解和使用常常让我陷入过分设计的境地。

设计技能再提升一个档次之后，我发现自己开始以另一种方式使用模式：重构以得到模式，而不是在前期设计中使用模式，也不过早地把它们引入代码之中。这种新的方式来自于极限编程（XP）的设计实践，它使我的设计不多不少，恰到好处。

什么是过分设计？

当你把代码搞得比需要的还要复杂、还要灵活时，你就是在过分设计。有些人这样做，是因为他们相信自己知道系统未来的需求。他们认为：最好是今天就把设计做得灵活些、复杂些，这样它就能适应明天的需要。听起来很美，如果你能未卜先知的话。

但是，如果你的预言错了，你就是在浪费宝贵的时间和金钱。花上几天乃至几周的时间去给设计增加不必要的灵活性，这种情况很常见——结果，给系统加新功能、排除错误的时间就少了。

如果你按照预先的设想写出了代码，但是预想的需要却没有出现，怎么办？你不会删掉它，因为删掉它会比较麻烦，或者你还希望以后能用上这些东西。不管出于什么原因吧，反正这些过分灵活、过分复杂的代码越积越多，你和团队中其他的程序员就不得不在越来越多、越来越复杂的代码基础上工作。

为了补偿这一切，人们决定把系统分成独立的小块，各自负责一块。这看起来能让他们的工作轻松些，但是却有副作用：每个人都按照自己的想法去写代码，很少看看别人是不是已经做过了自己需要的工作，所以就产生很多的重复代码。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有