《重构-改善既有代码的设计》笔记
读完《重构——改善既有代码的设计》，感觉写得真是非常得好，非常的细腻而且深入，建议还没有读过的找时间读一读，肯定受益良多。
之前写程序也总是不停的重构、重构，读完这本书之后才发现对于重构的理解以前是很肤浅的，很不成体系的。《重构》真是一本好书！
下面粗略地概括一下对重构的理解，也整理一下之前不是很清楚的概念。
１、《重构》有一个很好的动机，也可以说是价值观，就是程序第一是写给人看的，而不是写给机器看的。
根据这一价值观，其他多种利益纷至沓来，比如当程序有了良好的可读性和可理解性，程序中隐藏的Bug便很容易浮出水面，开发进度也更加顺畅，并且对于系统将来的结构变更和扩展，程序也更加具有灵活性。
２、《重构》与《设计模式》的关系，在《设计模式》和《重构》中都有提出“设计模式为重构提供了目标”，在之前对这句话的理解总是朦朦胧胧，觉得有道理但又不是很深刻，现在觉得有两个词非常的关键：目标和目的。
设计模式为重构提供了目标，但不是目的。
设计模式是经过证实的在一定场景下解决一般设计问题的解决方案的核心，通过设计模式我们很好得解决了某种问题，并且便于我们思考和交流，降低沟通之间的理解误差，此外同样重要的，设计模式增强了可复用性，便于将来扩展和维护。
而重构是对程序内部结构的一种调整，其目的是在不改变“软件之可察行为”的前提下，提高其可理解性，降低其修改成本（《重构》的名词性定义）。
所以如果我们把软件开发比作在大海中航行，设计模式就是遍布在大海中的航标，他可以引导我们驶向目的地——高可读性、可理解性、可扩展性、可维护性。所以设计模式是重构的目标（航标）而不是目的，设计模式可以帮助我们更好更快的抵达目的地（准确地说是无止境的），而避免触礁或偏离航向
３、重构和优化，在之前的开发中，优化的意识要比现在（看完《重构》之后）强的多，如果遇到在一个循环中可以做多个事情的时候，决定把每件事情分开放到单独的循环中是要鼓起很大的勇气的，而现在便可以轻松的决定，因为清晰的代码在需要性能优化时有更宽的道路可以选择，并且往往这种决定不会造成真正的性能影响。
public void handle(User user)
这样了解这个接口 是比较好用
并且接口也不用经常修改
但是如果不了解 又 user属性比较多
那么我怎么知道 需要的user 只要 id 和name 这两个属性就可以了
可以通过提高方法名字的表达能力，即这正是 Rename method 重构手法的用武之地
修改函数名称可能会影响系统的多态性吧
不会影响，有这个担心可能是把重载和覆盖的差异混淆了，试想两个子类的多态方法是面对相同的请求进行不同的具体处理的，如果一个类中的方法只需要user中的id，而另一个类中的方法却需要user中的id和name，那么我感觉这是一个重载的场景，而不是覆盖下的多态。 38 楼 hbcui1984 2007-04-17 大家讨论如此热烈，我也好买一本来读读了！ 39 楼 hyhongyong 2007-04-17 xly_971223 写道hyhongyong 写道看完这本，再看《重构与模式》，会有更深的理解。
《重构与模式》翻译的太烂了 读着太累
呵呵，能读原版的更好。
关键在于体会其中的道理。 40 楼 sopestar 2007-07-10 《重构--改善既有代码的设计》是本好书。值得研究，收藏 41 楼 experience 2007-07-20 qinysong 写道刑天战士 写道说句实在话，设计原则，设计模式，重构的终极思想，就是要忘掉这些模式，譬如张无忌学太极剑，忘光了就是学会了。死啃书本，不在项目中领会这些知识，等于没学，甚至等于邯郸学步。
呵呵，我觉得终极思想不是忘掉这些模式，而是通过实践的磨炼，经验的积累，达到对设计理念的心领神会，对设计决策的信手拈来，以无招应有招，而这里的无是心领神会，随心所欲的无，而不是忘光的无
这其中最大的差别是忘光的无，是可以在一知半解的时候就可以忘光的，而随心所欲的无，是需要对招数达到一定熟练程度，对更好层次的理念达到融会贯通之后才能做到的
忘掉设计模式的言论似乎颇有市场，但是你问他每个模式的精髓是什么，却一问三不知。模式的具体招数是如此重要，GOF，bob，Martin都在不同的场合说过dp这本书最重要的是总结了社区中的众多经验。而且模式本身就是形式（不要死板理解这个形式并不是指DP这本书上面的类图和协作图）嘛。
说终极思想是OCP、DRY等等还有情可原，说终极思想就是忘掉XXX，分明是受金庸影响太深了。 42 楼 xly_971223 2007-07-20 引用忘掉设计模式的言论似乎颇有市场，但是你问他每个模式的精髓是什么，却一问三不知。模式的具体招数是如此重要，GOF，bob，Martin都在不同的场合说过dp这本书最重要的是总结了社区中的众多经验。而且模式本身就是形式（不要死板理解这个形式并不是指DP这本书上面的类图和协作图）嘛。
说终极思想是OCP、DRY等等还有情可原，说终极思想就是忘掉XXX，分明是受金庸影响太深了。
规则是用来打破的 但是有个前提 你必须在充分的理解了规则之后才能去打破 同样设计模式也是如此 43 楼 kaguvivian 2007-08-09 qinysong 写道而且我觉得现在有一种现象，当然这种现象只是从我身边来看，可能不完全具有代表性，就是现在的开发人员不像几年前那样对于设计具有那样大的热情，起码热情的普遍性很差。
那些大佬们，象Robbin，cookoo，buaawhl以及老庄等等可以现在不谈论设计，不谈论模式，但是这不是说他们以前没谈论（反而是谈论的太多了，谈的没感觉了，即到了无的境界了），更不能说明现在不需要谈论
可能这有几方面的原因：
1）敏捷方法的突起，一方面要求简化设计，另一方面重构可以帮我们容易的改变设计；
2）框架（Struts,webwork,spring,hibernate）的日益丰富，使的在一般需求下，只按照框架规定的模式就可以顺利进行开发
对于现在初探架构的java朋友来说，感受设计模式的存在恐怕大多是从（Struts,webwork,spring,hibernate）等等的框架开始的，不乏一些对之前SunJavaCenter时期的设计模式一无所知。同意楼主的观点，希望朋友们日后读到架构方面的好书多做些笔记拿出来与大家讨论和分享！
