原文地址: PHP 杂谈<重构-改善既有代码的设计>之一 重新组织你的函数 思维导图   点击下图,可以看大图.    介绍   我把我比较喜欢的和比较关注的地方写下来和大家分享.上次我写了篇<php 跟老大的对话>.还是有很多疑问,这书帮了我不少的忙.   如果你比较繁忙,或者懒得看文字,建议你直接看截图,也会有很大的收获的.你可以通过比较截图中的代码就能知道孰优孰劣了.   代码部分我为什么用图呢?因为我经常用手机看代码,博客园的代码在手机里乱七八糟的,还是看图比较舒服.  …

此文写得有点晚,记得去年7月读完的这本书,只是那时没有写文章的意识,也无所谓总结了,现在稍微聊一下吧. 想起写这篇感想,还是前几天看了这么一篇文章 研究发现重构软件并不会改善代码质量 先从一个大家都有的经历说起吧. 刚开始学编程时,比如,要统计数字出现的次数,我们会这么定义变量 int i=0;//统计次数 老师看了说,代码要有可读性,见名知意; 于是,我们把它改成 int count=0; 后来才知道,原来这么一手这就是重构的第一式,重命名 (eclipse快捷键 alt+shift+R,最近…

<重构--改善既有代码的设计>[PDF]下载链接: https://u253469.ctfile.com/fs/253469-231196358 编辑推荐 重构,一言以蔽之,就是在不改变外部行为的前提下,有条不紊地改善代码.多年前,正是<重构:改善既有代码的设计>原版的出版,使重构终于从编程高手们的小圈子走出,成为众多普通程序员日常开发工作中不可或缺的一部分.<重构:改善既有代码的设计>也因此成为与<设计模式>齐名的经典著作,被译为中.德.俄.日等众多语言,…

14.总结 首先,这是一本太老的书,很多观点已经被固化或者过时了.但核心观点没有问题,虽然大多数观点已经被认为是理所当然的事情了.   重构的定义 重构分几种: 1.狭义的代码重构   就是本书讲的,在不改变软件可观察行为的前提下,改变其内部结构.这就是完全不改变程序的功能,只是改变代码的组织方式,也就是只是整理代码而已,目的是优化代码架构,而不是优化行为.算法.逻辑或流程. 2.普通意义的重构 事实上,我们一般很少会去做纯粹的重构,所以,了解了软件行为,从行为.算法.逻辑或流程上进行优化,,往…

第1章 重构, 第一个案例 1.1 起点 1.2 重构的第一步 1.3 分解并重组 statement() 1.4 运用多态取代与价格相关的条件逻辑 1.5 结语 第2章 重构原则 2.1 何谓重构 2.2 为何重构 2.3 何时重构 2.4 怎么对经理说 2.5 重构的难题 2.6 重构与设计 2.7 重构与性能 2.8 重构与性能 2.9 重构起源何处 第3章 代码的坏味道 3.1 Duplicated Code (重复代码) 3.2 Long Method (过长函数) 3.3 Large…

明确函数所在类的位置是很重要的.这样可以避免你的类与别的类有太多耦合.也会让你的类的内聚性变得更加牢固,让你的整个系统变得更加整洁.简单来说,如果在你的程序中,某个类的函数在使用的过程中,更多的是在和别的类进行交互,调用后者或者被后者调用,那么你就要注意了,你要去判断这个类是否真正适合他原来所在的类. 简单来说,这套手法就是在该函数最常引用的新类中建立一个有着类似行为的新函数,让旧函数变成一个单纯的委托函数或者完全删掉. Move Method是重构理论的支柱.如果一个类的责任太多,或者一个类和…

在面向对象中,对于类这个概念我们应该有一个清晰的责任认识,就是每个类应该只有一个变化点,每个类的变化应该只受到单一的因素,即每个类应该只有一个明确的责任.当然了,说时容易做时难,很多人可能都会和我一样,一开始建立类的时候信心满满,牢记SRP原则,但随着开发进度的不断进行,很有可能你会给你原本设计好的类增加新字段或者增加新函数,对于少量的增加你可能会因为麻烦,考虑不去单独做一个新类来分解.久而久之,你这个类会变得越来越臃肿,所掌管的责任也会越来越多.这样的类往往还有大量的数据和函数,往往太大而不易…

在编程中,比较忌讳的一件事情就是长函数.因为长函数代表了你这段代码不能很好的复用以及内部可能出现很多别的地方的重复代码,而且这段长函数内部的处理逻辑你也不能很好的看清楚.因此,今天重构第一个手法就是处理长函数--Extract Method,抽取成一个独立的小函数. 我个人来说也很喜欢短小函数,因为他们代表了高强度的复用与灵活性.对于短小函数来说最最关键的就是短小函数的命名,其实你就是给了这些短小函数自我解释的机会,所以你如果给这些短小函数起一个接近其语义的名字,那当你读起长函数来说,就像是阅读…

当MVC出现的时候,极大的推动了Model与View分离的潮流.然而对于一些已存在的老系统或者没有维护好的系统,你都会看到当前存在大把的巨大类----将Model,View,Controller都写在了一个widget中.一个分层良好的系统,应该将处理用户界面和处理业务逻辑的代码分开.原因如下 如果你此时需要用不同的用户界面来展示数据,比如微软Excel中的饼状图和折线图,他其实内部展示的数据是一样的,但如果你把这两层用户界面逻辑都放在一个widget中去的话,你就会让这个wiget变得复杂无比…

如果你有一个数组,其中的元素各自代表不同东西,比如你有一个 QList<QString> strList; 其中strList[0]代表选手姓名,strList[1]代表选手家庭住址,很显然这个数组表示的含义已经太多,你需要用对象来替换数组,并且对于数组中的每个元素,以一个字段来表示. 数组是一种常见的用以组织数据的数据结构,不过,它们应该只用于“以某种顺序容纳一组相似对象”.对于上面的例子你可以看到一个数组容纳了不同对象,这会给使用数组的客户带来麻烦,因为他们很难记住数组的第一个元素是姓名,…