代码中的坏味道

　　写了半年的代码，对面向对象还是只有个初步的了解，还不能达到熟练运用的地步，但是从半年的编码中，隐隐约约感觉到影响代码结构的坏味道的代码。

  1. 首先就是重复代码，一个程序中重复代码过多，导致维护时一旦修改就需要将所有重复的代码都修改一遍。尤其是一些逻辑复杂的代码或者参数过多的代码，很容易出现某个个地方的修改不对或没有修改到等问题。
  2. 属性放置的位置不对，例如UpdateUI作为UI的控制器，直接将UI中的一个Window的Panel定义为UpdateUI的属性，虽然这样做在UpdateUI中很方便的就能操作Panel，但是UpdateUI作为整个UI的控制，并不一定只针对一个Window，如果UpdateUI控制多个Window，就会导致UpdateUI中属性过重，且大部分都是对当前Window没有用的属性。
  3. 类的职责定位不清晰，如Window用来构建窗口，那么关于业务的逻辑就不应该还放在UI（Window）中，例如开启统计的方法应该属于UpdateUI，Window的作用就是创建各种UI和保存子组件的引用。

　　暂时未完，明天继续。

　　措施

时间： 2024-10-25 06:00:37

代码中的坏味道的相关文章

重构笔记——代码的坏味道（上）

在重构入门篇中,简单地介绍了重构的定义.为何重构.何时重构等.我想对于重构是如何运作的,你已经有了较好的理解了.但是对于代码中的坏味道,你可能 知道的并不多.坏味道可能是无形中产生的,也可能是开发人员偷懒造成的,还可能是其它某些因素导致的.不管怎么样,代码中的坏味道对程序没有半点好处,它 会促使程序腐烂,甚至变质.对于开发人员,真的是很有必要对这些坏味道进行了解和熟悉,理解它们产生的场景.针对当前程序,发现坏味道,对代码进行重构, 以消除坏味道,提高代码质量,提高自己水平. 下面让我们一起来熟悉

解析大型.NET ERP系统 代码的坏味道

1  对用户输入做过多的约定和假设 配置文件App.config中有一个设定报表路径的配置节: <add key="ReportPath" value="C:\Users\Administrator"/> .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monosp

吐槽一下项目中的代码坏味道：滥用java常量

我们的项目中是否充斥着类似下面的代码呢?定义一个专门存放常量的java类(接口),很多其他类依赖该常量类. public interface IConstant { int ZERO = 0; String EMPTY_STRING = ""; } 使用该常量的代码,大致具有如下形式: List<String> list = new ArrayList<String>(IConstant.ZERO); if(IConstant.ZERO == list.size

代码坏味道特征重复的代码

重复的代码开发,在作为初级的程序员是经常遇见的,因为被要求做一些很固定且比较简单通用的模块,所以很容易就遇上功能相同的代码进行重复的开发了. 1.为什么会有重复的代码 重复的代码可能会出现编写人员抽象公有模块抽象公有功能的能力,可能来自我们开发方式过于老化固定了类之间的相互应用所以导致编写的某一个功能只适用一个特定的系统使用,可能来自我们的设计人员对项目框架设计考虑不够仔细,没有重用性的设计过程. 2.怎样避免出现重复的代码 使用完善的SOA框架,我认为至少在我们内网程序开发中可以节约一大部分的

22种代码的坏味道，一句话概括

22种代码的坏味道,一句话概括: 假设一段代码是不稳定或者有一些潜在问题的,那么代码往往会包括一些明显的痕迹. 正如食物要腐坏之前,常常会发出一些异味一样. 我们管这些痕迹叫做"代码异味". 參考资料: http://blog.csdn.net/sulliy/article/details/6635596 http://sourcemaking.com/refactoring/bad-smells-in-code Code smells Duplicated Code --------

重构摘要3_代码的坏味道

如果尿布臭了,就换掉它. 1.Duplicated Code 重复代码 Extract Method Pull Up Method Form Template Method --> Template Method 模式 Substitute Algorithm --> 函数算法替代 2.Long Method 过长的函数 "间接层"所带来的全部利益--解释能力.共享能力.选择能力--都是有小函数支持的. 真正关键在于一个好名字. 每当感觉需要以注释来说明点什么的时候,我们就

『重构--改善既有代码的设计』读书笔记----代码坏味道【3】

星期六了,适当出去放松了下,回来继续我们重构的话题.今天是坏味道[3]了,很多朋友跟我私信,叫我把坏味道出完,再出手法.其实这是有道理的,很多时候,"发现"远比"怎么做"重要的多.就拿设计模式来讲,GoF里面的设计模式相信有很多人都了解过.具体的设计模式应该怎么实现啊相信有很多人都背的滚瓜烂熟,但问题的难点往往在于你应该什么时候用这个设计模式.重构也一样,手法步骤都是死的,关键在于应该发现什么时候应该重构.所以,我还是决定继续出坏味道,把坏味道全部出完我们再去学手法

代码的坏味道之二——译自《重构》

巨型类 当一个类尝试做的太多,它常常展示出过多的实例变量.当一个类有太多实例变量,重复代码的出现就不远了. 你可以提取类来打包一部分变量.选择在部件中有意义的变量放在一起.例如,“存款总量”和“存款货币”很可能在同一部件中.更宽泛的说,在一个类中变量的某个子集共同的前缀和后缀预示着组成同一个部件的机会.如果这个部件有成为子类的意义,你会发现提取子类往往更容易. 有时一个类不会一直使用它全部的实例变量.如果如此,你可能可以提取类或者提取子类若干次. 相比于一个类有太多实例变量,一个类有太多代码是重

22 种代码的坏味道

1.Duplicated Code(反复的代码) 臭味行列中首当其冲的就是Duplicated Code.假设你在一个以上的地点看到同样的程序结构,那么当可肯定:设法将它们合而为一,程序会变得更好. 最单纯的Duplicated Code就是［同一个class内的两个方法含有同样表达式(expression)］. 这时候你须要做的就是採用Extract Method提炼出反复的代码,然后让这两个地点都调用被提炼出来的那一段代码. 还有一种常见情况就是[两个互为兄弟(sibling)的subcla