[url]http://chengkehan.wordpress.com/2010/05/16/%E6%8A%B5%E5%BE%A1%E6%A8%A1%E5%BC%8F%E8%AF%B1%E6%83%91/[/url]
在我们看了很多设计模式,认为自己已经掌握或有所了解时,总是想把这些新学到的东西应用到自己的实践中。导致在预先就计划好了很多模式将会被使用,尽管还没有看到具体的需求。等到具体编码的时候,草草的认为这里应该使用这个模式,那里应该使用那么模式,这就造成了生搬硬套。结果要么是一个模式大纠集大混乱,要么是设计过度了代码复杂度高。
面对这种情况,很多框架就有了用武之地。因为已经有了一个半成品,我们只需要在那基础上进行开发,这就避免了再最初的阶段的过度设计和设计混乱。
那如果我们不想使用这些现有的框架或者不想杀机用宰牛刀的话呢。那么最好的方式不是在最初的设计阶段预想好各种模式,而是要保持代码的结构清晰,这时不需要考虑任何的模式,当你写着写着觉得哪里不对劲的时候,或者现有的设计无法满足扩展需求的时候,再来考虑重构,考虑模式。这样就避免了设计过度和设计混乱。你的代码永远是最适合当前情况的并且很容易应付未来的改变。
其实就是在重构中实现模式。只有在重构的时候,我们才会真正的体会到,为什么这里需要这么写,为什么这个模式会这么用。
在我们看了很多设计模式,认为自己已经掌握或有所了解时,总是想把这些新学到的东西应用到自己的实践中。导致在预先就计划好了很多模式将会被使用,尽管还没有看到具体的需求。等到具体编码的时候,草草的认为这里应该使用这个模式,那里应该使用那么模式,这就造成了生搬硬套。结果要么是一个模式大纠集大混乱,要么是设计过度了代码复杂度高。
面对这种情况,很多框架就有了用武之地。因为已经有了一个半成品,我们只需要在那基础上进行开发,这就避免了再最初的阶段的过度设计和设计混乱。
那如果我们不想使用这些现有的框架或者不想杀机用宰牛刀的话呢。那么最好的方式不是在最初的设计阶段预想好各种模式,而是要保持代码的结构清晰,这时不需要考虑任何的模式,当你写着写着觉得哪里不对劲的时候,或者现有的设计无法满足扩展需求的时候,再来考虑重构,考虑模式。这样就避免了设计过度和设计混乱。你的代码永远是最适合当前情况的并且很容易应付未来的改变。
其实就是在重构中实现模式。只有在重构的时候,我们才会真正的体会到,为什么这里需要这么写,为什么这个模式会这么用。