大话重构 之 消除过长方法
在面向对象程序中活的最好最长久的是短方法。对于新手而言，很困恼面向对象的程序中完全找不到计算逻辑，反而是无穷无尽的方法调用，但是当你习惯面向对象后就会了解到短方法的价值所在。 短方法的价值 从较早 ...
原文：大话重构 之 消除巨无霸类
当你看到别人写的超过千行的巨无霸类，以及随着时间的累积，自己写的类也稳步迈向巨无霸的时候，是不是既恐惧又无奈 一码今天就带小伙伴们征服巨无霸，打造属于自己的成就感。 过长类的缘由 当业务逻辑随着时间累积，并且越来越复杂时，这个类由本来的清秀怡人非常容易变得满脸横肉。 一个类中业务逻辑越来越多，首先它的职责就不再单一，一说这，小伙伴们都明白。 其次逻辑越多，涉及的状态越多，即实例变量越多，实例变量一 ...
2015-06-03 09:16 11 2484 推荐指数：
相关推荐
大话重构 之 答读者问
越来越多人关注《大话重构》系列，一码感谢大家的支持。从系列开始到现在，有提出疑问的，有说好的，有说坏的，一码在此一并回答。 问：单篇篇幅长，知识点多，看起来很吃力 答：如果觉得有难度，不要气馁，你学习的机会就在眼前。《大话重构》的每篇文章都针对一种代码坏味道，务求讲清“坏”在哪儿，有哪些方法 ...
大话重构 之 防止“加个需求，到处改代码”
上一篇《职责单一原则真的简单吗》中我们认识了 发散式变化 ，它是一个类包含多个维度的变化，职责不单一。本文讨论的代码坏味道是 散弹式修改 ，与 发散式变化 恰好相反，一个维度的变化涉及到多个类。 在商业项目开发过程中，经常会碰到“加个需求，到处改代码”的情况，也就是 散弹式修改 ，典型后果是漏改 ...
大话重构 之 原来反OO天天见
在OO（面向对象）时代长大的小伙伴们一定记得： 面向对象的基石：把数据和依赖该数据的行为封装在一起。 但我们经常遇到一个类依赖其它类的数据的情况。不多的话，正常，对象间势必存在交互，毕竟完全独立的类无法构建出复杂的业务系统。 太多依赖外部数据的话，可能是问题，也可能不是问题 ...
代码重构(二)：类重构规则
在上篇博客《代码重构(一)：函数重构规则（Swift版）》中，详细的介绍了函数的重构规则，其中主要包括：Extract Method, Inline Method, Inline Temp, Replace Temp with Query, Introduce Explaining ...
重构的秘诀：消除重复，清晰意图
11年前有幸阅读了《重构——改善既有代码的设计》第一版，当时是一口气读完的，书中的内容直接惊艳到我了。 今年读了该书的第二版，再次震撼到我了，并且这次的示例代码用的JavaScript，让我更有亲切感。 全书共有12章，前面5章是在讲解重构的原则、测试、代码的坏味道等内容，后面7章 ...
重构学习2-消除过长参数
个原因是一旦需要更多数据，就可能要增加参数或者重载这个方法。所以消除过长参数往往能提高代码的可读性。 方 ...
大话重构连载14：我们是这样自动化测试的
说了那么多，让我们用示例看看，系统重构是应该怎样做自动化测试的。还是回到前面那个HelloWorld的例子（详见 3.3 小步快跑是这样玩的），该类中有一个sayHello()方法，只要我们输入当前的时间与用户名，就返回对该用户的问候语。如果当前时间是上午，则返回“Hi, XXX. Good ...