重构笔记批注

                   批注：《<重构-改善既有代码的设计>笔记》

http://www.javaeye.com/topic/65257

图例：赞同，不赞同。

ID	时间	内容
qinysong	2007-03-24	读完《重构——改善既有代码的设计》，感觉写得真是非常得好，非常的细腻而且深入，建议还没有读过的找时间读一读，肯定受益良多。   之前写程序也总是不停的重构、重构，读完这本书之后才发现对于重构的理解以前是很肤浅的，很不成体系的。《重构》真是一本好书！ 下面粗略地概括一下对重构的理解，也整理一下之前不是很清楚的概念。   １、《重构》有一个很好的动机，也可以说是价值观，就是程序第一是写给人看的，而不是写给机器看的。 根据这一价值观，其他多种利益纷至沓来，比如当程序有了良好的可读性和可理解性，程序中隐藏的Bug便很容易浮出水面，开发进度也更加顺畅，并且对于系统将来的结构变更和扩展，程序也更加具有灵活性。   ２、《重构》与《设计模式》的关系，在《设计模式》和《重构》中都有提出“设计模式为重构提供了目标”，在之前对这句话的理解总是朦朦胧胧，觉得有道理但又不是很深刻，现在觉得有两个词非常的关键：目标和目的。   设计模式为重构提供了目标，但不是目的。   设计模式是经过证实的在一定场景下解决一般设计问题的解决方案的核心，通过设计模式我们很好得解决了某种问题，并且便于我们思考和交流，降低沟通之间的理解误差，此外同样重要的，设计模式增强了可复用性，便于将来扩展和维护。   而重构是对程序内部结构的一种调整，其目的是在不改变“软件之可察行为”的前提下，提高其可理解性，降低其修改成本（《重构》的名词性定义）。   所以如果我们把软件开发比作在大海中航行，设计模式就是遍布在大海中的航标，他可以引导我们驶向目的地——高可读性、可理解性、可扩展性、可维护性。所以设计模式是重构的目标（航标）而不是目的，设计模式可以帮助我们更好更快的抵达目的地（准确地说是无止境的），而避免触礁或偏离航向   ３、重构和优化，在之前的开发中，优化的意识要比现在（看完《重构》之后）强的多，如果遇到在一个循环中可以做多个事情的时候，决定把每件事情分开放到单独的循环中是要鼓起很大的勇气的，而现在便可以轻松的决定，因为清晰的代码在需要性能优化时有更宽的道路可以选择，并且往往这种决定不会造成真正的性能影响。 声明：JavaEye文章版权属于作者，受法律保护。没有作者书面许可不得转载。 推荐链接
qinysong	2007-03-24	此外代码的坏味道Bad smells一章，真是一顿营养丰富的大餐。Duplicated Code是代码腐化的万恶之源，Long Method、Large Class、Long Parameter List这些几乎就是旧社会臭婆娘的裹脚布，Divergent Change、Shotgun Surgery、Feature Envy、Inappropriate Intimacy这些简直就是指责不清勾肩搭背。等等。。。   重构，它为我们清除这些坏味道指明了方向，并且《重构》通过强调“重构是一种有纪律的、经过训练的、有条不紊的程序整理方法”，保证了重构过程的安全性和高效性。   在重构的手法中有相当一大部分是双向的、互逆的，也就是说在某种时候是你找我，而在另一些时候是我找你，比如Pull Up Field和Push Down Field，Pull Up Method和Push Down Method等，而另一些则是强调单向的、勇往直前的，比如Encapsulate Field、Remove Control Flag、Remove Parameter、Remove Assignments to Parameters、Replace Conditional with Polymorphism等。 在双向的、护逆的重构手法中，强调的是一种平衡，是职责清晰，角色明确。 而在强调单向的、勇往直前的重构手法中，突出的是使代码更容易理解、更容易扩展，更加具有面向对象性。   为了对比双向可逆的重构手法，以便突出其侧重点和权衡内容，下面进行列举 重新组织你的函数章节中 Extract Method——Inline Method Inline Temp——Introduce Explaining Variable   在对象之间搬移特性章节中 Extract Class——Inline Class Hide Delegate——Remove Middle Man Introduce Foreign Method——Introduce Local Extension   重新组织数据章节中 Change Value to Reference——Change Reference to Value Change Unidirectional Association to Bidirectional——Change Bidirectional Association to Unidirectional   简化条件表达式章节中 无   简化函数调用章节中 Add Parameter——Remove Parameter Parameterize Method——Replace Parameter with Explicit Methods   处理概括关系章节中 Pull Up Field——Push Down Field Pull Up Method——Push Down Method Extract Subclass（Extract Superclass）——Collapse Hierarchy Replace Inheritance with Delegation——Replace Delegation with Inheritance   在看这本书的过程中感觉这种互逆的挺多，列举之后发现没有之前感觉多。
jamesby	2007-03-25	我觉得设计原则(OCP等)，设计模式，重构是软件设计的三个重要组成部分。 大家怎么看？
qinysong	2007-03-25	我也这么觉得，设计原则，设计模式和重构三者相互联系，互为补充，共同组成软件设计的整体过程   设计原则是软件设计的指南，借以可以指导设计出优秀的软件（具有清晰、可扩展、可维护等等特性）；   设计模式是设计原则在某种场景下的事例体现，是已证实的符合设计原则的某种解决方案的核心，可以重复拿来使用；   而重构则是在后期对现有代码的整理，通过进一步组织函数、数据、类结构和等等，使代码更加清晰设计更加优秀；
feygo	2007-03-26	Bad smells一章 可以当作程序员的自我修养来读
刑天战士	2007-03-26	说句实在话，设计原则，设计模式，重构的终极思想，就是要忘掉这些模式，譬如张无忌学太极剑，忘光了就是学会了。死啃书本，不在项目中领会这些知识，等于没学，甚至等于邯郸学步。
andyandyandy	2007-03-26	自从看了重构这本书后，逐渐的在项目开发当中应用，确实改善了程序的阅读性，结构性，优化性等，感觉很有用，虽然有些东西还没有理解的特别深刻
qinysong	2007-03-26	说句实在话，设计原则，设计模式，重构的终极思想，就是要忘掉这些模式，譬如张无忌学太极剑，忘光了就是学会了。死啃书本，不在项目中领会这些知识，等于没学，甚至等于邯郸学步。   呵呵，我觉得终极思想不是忘掉这些模式，而是通过实践的磨炼，经验的积累，达到对设计理念的心领神会，对设计决策的信手拈来，以无招应有招，而这里的无是心领神会，随心所欲的无，而不是忘光的无   这其中最大的差别是忘光的无，是可以在一知半解的时候就可以忘光的，而随心所欲的无，是需要对招数达到一定熟练程度，对更好层次的理念达到融会贯通之后才能做到的
qinysong	2007-03-26	而且我觉得现在有一种现象，当然这种现象只是从我身边来看，可能不完全具有代表性，就是现在的开发人员不像几年前那样对于设计具有那样大的热情，起码热情的普遍性很差。   那些大佬们，象Robbin，cookoo，buaawhl以及老庄等等可以现在不谈论设计，不谈论模式，但是这不是说他们以前没谈论（反而是谈论的太多了，谈的没感觉了，即到了无的境界了），更不能说明现在不需要谈论   可能这有几方面的原因： 1）敏捷方法的突起，一方面要求简化设计，另一方面重构可以帮我们容易的改变设计； 2）框架（Struts,webwork,spring,hibernate）的日益丰富，使的在一般需求下，只按照框架规定的模式就可以顺利进行开发
andyandyandy	2007-03-26	楼上说得很有道理
刑天战士	2007-03-26	错错错，大大们不谈Design Pattern，是因为Design Pattern已经融汇贯通在他们脑子里了，他们可以随意YY模式，so~~~~
jianfeng008cn	2007-03-26	刑天战士 写道 错错错，大大们不谈Design Pattern，是因为Design Pattern已经融汇贯通在他们脑子里了，他们可以随意YY模式，so~~~~     大大们不用谈论了，不表示所有人该不谈了，反而该多谈谈，好让大大们给些指点：）
qinysong	2007-03-26	刑天战士 写道 错错错，大大们不谈Design Pattern，是因为Design Pattern已经融汇贯通在他们脑子里了，他们可以随意YY模式，so~~~~   对对对，是“融汇贯通在他们脑子里”，而不是从他们的脑子里忘掉
cozone_柯中	2007-03-26	书到是有,只是没时间读.
jamesby	2007-03-26	这个帖是发在新手区域的，怎么跑到这里来了？ 我觉得这个是评论高手还是低手的一个主要因素。 如果融会贯通应该是架构师级别的吧！
qinysong	2007-03-26	在《重构》中，Martin Fowler按照重构所针对的代码内容进行了分类，包括对函数的重构、对对象特性的重构、对数据组织的重构、对条件表达式的重构以及对类层次的重构，并按照这种分类组织了章节。   除了按照重构所针对的代码内容进行分类外，按照采用手法进行分类，我觉得也可以从另一个角度帮助我们更进一步理解重构的进行方式。   通过整理，按照采用手法分类如下：   １、提炼 就是对某个过程的一部分，或某个事物的一部分进行抽象并概念化，以减小所表达的目的（要做什么）和实现（做什么，如何做）之间的语义差距。   运用提炼的重构手法包括 Extract Method、 Split Temporary Variable、 Extract Class、 Extract Subclass、 Extract Superclass、 Extract Interface等   ２、内联 就是用其直接实现替换原来的间接调用，通过内联可以去掉意义不大的间接性。   运用内联的重构手法包括 Inline Method、 Inline Temp、 Inline Class   3、移动 在类之间（包括父类和子类之间）移动属性和方法，以使类之间职责更明确更清晰。   运用移动的重构手法包括 Move Method、 Move Field、 Pull Up Field、 Pull Up Method、 Pull Up Constructor Body、 Push Down Method、 Push Down Field   4、替换 将一种实现方式用另一种实现方式替代，以便于更直接更集中和更灵活   运用替换的重构手法包括 Replace Temp with Query、 Replace Method with Method Object、 Replace Date Value with Object、 Replace Array with Object、 Replace Magic Number with Symbolic Constant、 Replace Record with Data Class、 Replace Type Code with Class、 Replace Type Code with Subclasses、 Replace Type Code with State/Strategy、 Replace Subclass with Fields、 Replace Nested Conditional with Guard Clauses、 Replace Conditional with Polymorphism、 Replace Paramether with Explicit Methods、 Replace Parameter with Method、 Replace Constructor with Factory Method、 Replace Error Code with Exception、 Replace Exception with Test、 Replace Inheritance with Delegation、 Replace Delegation with Inheritance   ５、改变 改变和替换语义上有些类似，其间的差别还不是很清楚   运用改变的重构手法包括 Change Value to Reference, Change Reference to Value, Change Unidirectional Association to Biderectional Change Biderectional Association to Unidirectional   ６、其他 包括增加Add、移除Remove、隐藏Hide、引入Introduce、封装Encapsulate、合并Consolidate等等
newbin	2007-03-26	我最近找了本电子版的也在看，看了前三章，虽然我刚开始写代码，不过这本书感觉的确很经典
xly_971223	2007-03-28	重构和设计模式怕的就是为了重构而重构 为了模式而模式 凡事太刻意了 就会偏离了方向 我的体会是从TDD到重构，然后从重构中发现模式 直接用模式可能会出现过度设计等问题
jamesby	2007-03-28	如果是学习阶段无论怎么过渡设计我觉得都不过分， 反而越过渡学习到的东西越多， 就像开始学习武功总是先学习这个拳法，那门功夫，等学习多了， 某天忽然发现原来这些东西外形各异却有着相似的东西， 于是传说中的无招胜有招出现了。
qinysong	2007-03-30	xly_971223 写道 重构和设计模式怕的就是为了重构而重构 为了模式而模式 凡事太刻意了 就会偏离了方向 我的体会是从TDD到重构，然后从重构中发现模式 直接用模式可能会出现过度设计等问题   为了模式而模式其实在过度设计中所占的比重并不大，过度设计大部分是为满足“对将来可能需求”的扩展性灵活性而预先设计的，之后这些可能需求并没有成为真正的需求，但是设计却保留下来了   所以“从TDD到重构，然后从重构中发现模式”固然是一个非常好的编码过程，可以最大限度避免过度设计，但是另一个相反的过程——利用重构去除不必要的预先设计模式，其实我觉得也是很好的，只要看预先设计及后来的重构不是非常困难。   所以过度设计不是非常的可怕，而且在一定范围、尺寸内存在也是经常会出现，而且我感觉也是值得鼓励的。
zeng1980	2007-04-08	我书也是早买了，没时间看，看了上边的对重构的讨论，感觉很值得一看。
Sharong	2007-04-09	也在看这本书，说老实话，书写的还可以，就是太浅，不够深入，80%的重构方法我还没看这本书前就会了，因为eclipse,idea等IDE已经提供了重构选项，还是不要迷信大师的好。
xly_971223	2007-04-09	迷信？ 重构里面的东西都是迷信吗？
温柔一刀	2007-04-09	好书我喜欢不停的重复看 这本书我也是没事的时候就喜欢翻翻
Huangpengxiao	2007-04-10	中关村图书大厦居然没有此书 需要订购~
xly_971223	2007-04-10	huangpengxiao 写道 中关村图书大厦居然没有此书 需要订购~   中关村图书大厦卖的太贵 我一般上当当买
hyhongyong	2007-04-10	看完这本，再看《重构与模式》，会有更深的理解。
dovecat	2007-04-10	sharong 写道 也在看这本书，说老实话，书写的还可以，就是太浅，不够深入，80%的重构方法我还没看这本书前就会了，因为eclipse,idea等IDE已经提供了重构选项，还是不要迷信大师的好。   晕!那是eclipse写得好,让你在使用IDE的时候不知不觉就理解了大师的想法.我个郁闷!感觉有点象教会了徒弟,打师父...
realreal2000	2007-04-10	学习的过程就是提高的过程，看书是对自己认识的总结
xly_971223	2007-04-10	hyhongyong 写道 看完这本，再看《重构与模式》，会有更深的理解。   《重构与模式》翻译的太烂了 读着太累
zeng1980	2007-04-16	qinysong 写道 lzmhehe 写道 还有一个就是方法的参数不应该过长 可以使用class 代替   比如 Java代码 复制代码      1. public void handle(long userid,String userName)    public void handle(long userid,String userName)       要写成   Java代码 复制代码      1. public void handle(User user)    public void handle(User user)       这样了解这个接口 是比较好用 并且接口也不用经常修改   但是如果不了解 又 user属性比较多 那么我怎么知道 需要的user 只要 id 和name 这两个属性就可以了   可以通过提高方法名字的表达能力，即这正是 Rename method 重构手法的用武之地   修改函数名称可能会影响系统的多态性吧
qinysong	2007-04-16	zeng1980 写道 qinysong 写道 lzmhehe 写道 还有一个就是方法的参数不应该过长 可以使用class 代替   比如 Java代码 复制代码      1. public void handle(long userid,String userName)    public void handle(long userid,String userName)       要写成   Java代码 复制代码      1. public void handle(User user)    public void handle(User user)       这样了解这个接口 是比较好用 并且接口也不用经常修改   但是如果不了解 又 user属性比较多 那么我怎么知道 需要的user 只要 id 和name 这两个属性就可以了   可以通过提高方法名字的表达能力，即这正是 Rename method 重构手法的用武之地   修改函数名称可能会影响系统的多态性吧   不会影响，有这个担心可能是把重载和覆盖的差异混淆了，试想两个子类的多态方法是面对相同的请求进行不同的具体处理的，如果一个类中的方法只需要user中的id，而另一个类中的方法却需要user中的id和name，那么我感觉这是一个重载的场景，而不是覆盖下的多态。
hbcui1984	2007-04-17	大家讨论如此热烈，我也好买一本来读读了！
hyhongyong	2007-04-17	xly_971223 写道 hyhongyong 写道 看完这本，再看《重构与模式》，会有更深的理解。   《重构与模式》翻译的太烂了 读着太累   呵呵，能读原版的更好。 关键在于体会其中的道理。
wangx1949	2007-07-09	刚买此书并且看完第一章,觉得书上讲的东西平时自己也在尝试做,只是没形成一个体系. 总体来说是一本好书.
sopestar	2007-07-10	《重构--改善既有代码的设计》是本好书。值得研究，收藏
experience	2007-07-20	qinysong 写道 刑天战士 写道 说句实在话，设计原则，设计模式，重构的终极思想，就是要忘掉这些模式，譬如张无忌学太极剑，忘光了就是学会了。死啃书本，不在项目中领会这些知识，等于没学，甚至等于邯郸学步。   呵呵，我觉得终极思想不是忘掉这些模式，而是通过实践的磨炼，经验的积累，达到对设计理念的心领神会，对设计决策的信手拈来，以无招应有招，而这里的无是心领神会，随心所欲的无，而不是忘光的无   这其中最大的差别是忘光的无，是可以在一知半解的时候就可以忘光的，而随心所欲的无，是需要对招数达到一定熟练程度，对更好层次的理念达到融会贯通之后才能做到的   忘掉设计模式的言论似乎颇有市场，但是你问他每个模式的精髓是什么，却一问三不知。模式的具体招数是如此重要，GOF，bob，Martin都在不同的场合说过dp这本书最重要的是总结了社区中的众多经验。而且模式本身就是形式（不要死板理解这个形式并不是指DP这本书上面的类图和协作图）嘛。 说终极思想是OCP、DRY等等还有情可原，说终极思想就是忘掉XXX，分明是受金庸影响太深了。
xly_971223	2007-07-20	引用 忘掉设计模式的言论似乎颇有市场，但是你问他每个模式的精髓是什么，却一问三不知。模式的具体招数是如此重要，GOF，bob，Martin都在不同的场合说过dp这本书最重要的是总结了社区中的众多经验。而且模式本身就是形式（不要死板理解这个形式并不是指DP这本书上面的类图和协作图）嘛。 说终极思想是OCP、DRY等等还有情可原，说终极思想就是忘掉XXX，分明是受金庸影响太深了。   规则是用来打破的 但是有个前提 你必须在充分的理解了规则之后才能去打破 同样设计模式也是如此。
kaguvivian	2007-08-09	qinysong 写道 而且我觉得现在有一种现象，当然这种现象只是从我身边来看，可能不完全具有代表性，就是现在的开发人员不像几年前那样对于设计具有那样大的热情，起码热情的普遍性很差。   那些大佬们，象Robbin，cookoo，buaawhl以及老庄等等可以现在不谈论设计，不谈论模式，但是这不是说他们以前没谈论（反而是谈论的太多了，谈的没感觉了，即到了无的境界了），更不能说明现在不需要谈论   可能这有几方面的原因： 1）敏捷方法的突起，一方面要求简化设计，另一方面重构可以帮我们容易的改变设计； 2）框架（Struts,webwork,spring,hibernate）的日益丰富，使的在一般需求下，只按照框架规定的模式就可以顺利进行开发     对于现在初探架构的java朋友来说，感受设计模式的存在恐怕大多是从（Struts,webwork,spring,hibernate）等等的框架开始的，不乏一些对之前SunJavaCenter时期的设计模式一无所知。同意楼主的观点，希望朋友们日后读到架构方面的好书多做些笔记拿出来与大家讨论和分享！