代码坏味道特别篇————Long parameter List 过长的参数列表

刚开始学习编程时,老师说:讲方法所需要的东西都以参数的形式传入,那是我们好像还没学OO这个东东,要不就弄成全局变量,我擦,全局变量可牛逼了,刚开始学习的时候我们都在用全局变量,可是后来工作了,经理说不要用全局变量,我当时就有些醉了,突然间觉得就不会写代码了,其实我们可以用对象来解决这个问题,这样我们就不会开到过长的参数列表了

 1     private DataTable getSentInfo(string Pno, string Pname, string Psytle, string SentTime,string DealerNo,string DealerName)
 2     {
 3         string sqlStr = "select convert(decimal(18,2),round(sum(sc.Price*srd.SentNum ),2))as countPrice,sum(srd.SentNum) as num "
 4             + "from  LB_Sent_Rec sr inner join LB_Sent_RecDetail srd "
 5            + "on sr.SentID=srd.SentID inner join LB_Sale_Rec sc "
 6            + "on sc.SaleID=srd.SaleID where sc.cid=‘" + cidH.Value + "‘ and sc.Pno=‘" + Pno + "‘ and sc.Pname=‘" + Pname + "‘ and sc.PStyle=‘" + Psytle + "‘ "
 7            + "and sc.DealerNo=‘" + DealerNo + "‘ and sc.DealerName=‘" + DealerName + "‘ "
 8            + "and sr.SentTime between ‘" + SentTime + " 00:00:00‘ and ‘" + SentTime + " 23:59:59‘";
 9         return DbHelperSQL.GetDataTable(sqlStr);
10     }

使用对象后的代码

 1 public class Product
 2 {
 3     public Product()
 4     {
 5         //
 6         //TODO: 在此处添加构造函数逻辑
 7         //
 8     }
 9
10     public string Pno { get; set; }
11     public string Pnamr { get; set; }
12     public string Psytle { get; set; }
13     public string SentTime { get; set; }
14     public string DealerNo{get;set;}
15     public string DealerName { get; set; }
16 }

 1  private DataTable getSentInfo(Product pr)
 2     {
 3     string  sqlStr = "select convert(decimal(18,2),round(sum(sc.Price*srd.SentNum ),2))as countPrice,sum(srd.SentNum) as num "
 4             + "from  LB_Sent_Rec sr inner join LB_Sent_RecDetail srd "
 5            + "on sr.SentID=srd.SentID inner join LB_Sale_Rec sc "
 6            + "on sc.SaleID=srd.SaleID where sc.cid=‘" + cidH.Value + "‘ and sc.Pno=‘" + pr.Pno + "‘ and sc.Pname=‘" + pr.Pnamr + "‘ and sc.PStyle=‘" + pr.Psytle + "‘ "
 7            + "and sc.DealerNo=‘" + pr.DealerNo + "‘ and sc.DealerName=‘" + pr.DealerName + "‘ "
 8            + "and sr.SentTime between ‘" + pr.SentTime + " 00:00:00‘ and ‘" + pr.SentTime + " 23:59:59‘";
 9         return DbHelperSQL.GetDataTable(sqlStr);
10     }

这样是不是更容易理解传入参数所表示的内容呢?

这种方法书中叫 introduce Parameter Object

时间: 2024-10-03 02:20:17

代码坏味道特别篇————Long parameter List 过长的参数列表的相关文章

吐槽一下项目中的代码坏味道:滥用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框架,我认为至少在我们内网程序开发中可以节约一大部分的

代码坏味道之令人迷惑的暂时字段

为什么我们随意命名变量会是灾难性的决定? 随意命名变量是编写代码的灾难性决定,我这里说的比较严重,但是为了强调编程过程中不要随意命名我们的变量.因为从以下三方面的理由是不允许我们在程序中随意命名变量的.首先在编程过程中,随意命名的变量会导致我们编写代码中弄乱数据传输的关系,因为人们通过混乱的字段会把字段的本意理解错误的,理解错误字段的意思就会把该字段用在本不该她使用的地方.其次,当你费尽千辛万苦程序终于能够运行了,但是面对需求变更或代码给其他人阅读的时候,会给阅读人带来很大的难度,因为当别人来阅

代码坏味道之过大的类

1.为什么会出现过大的类 我们的编码过程中,不知不觉的就把一个类编写的非常的庞大.为什么会这样子呢?我想无非由两个理由,首先是编码过程中为了贪图一时的方面不想动手去添加一个类用来管理不属于原先这个类的职责.其次整个系统使用了太多的继承关系,无形中就会造成子类变得异常庞大.总之,如果想利用一个类做太多的事情,往往就会造成这个类变得异常庞大.8 2.过大的类会照成什么严重后果 既然出现了过大的类,那么他到底会造成什么严重的后果呢?首先很明显一点过大的类在开发中难以调试并且在后期维护中可能因为功能的变

代码坏味道之过长的参数列

1.为什么会出现过长的参数的函数呢? 出现过长的参数列,我们在编写程序的时候职责划分不清晰,一个函数做了太多的事情,可能会让调用者传入更多的参数进行功能的实现.第二函数封装不合理,导致调用函数的内部变量成为封装函数的参数. 2.当我们遇上了过长的参数函数怎么办? 当我们遇上了过长的参数列的函数有两种方法来解决,第一,通过重载参数把程序中暂时不需要的函数的参数进行封装,减少过长的参数列.第二,通过封装参数列对象,在封装的时候尽量将职责相近的参数放在一起,这样做提高了封装对象的内聚性. 3.怎样避免

代码坏味道之夸夸其谈的未来性

1.为什么会有夸夸奇谈的未来性呢? 当我们谈到这个问题的时候,我们就要反思在需求理解和设计的时候对程序变动性的理解出现了偏差."哦,我想我们总有一天炫耀做这事儿的"常常是一念之差导致的代码坏味道.总结有以下四点原因是经常导致出现夸夸奇谈未来性的原因.第一.经常在理解需求的时候主观的认为需求变动非常大,那么在设计过程中就会出现过度的设计.第二.追求设计模式的使用,经常对程序的不必要的地方进行设计模式的使用,导致代码不易理解.第三.程序的设计过程中封装变化混乱,没有将封装变化进行到底.最后

代码坏味道

肿胀 代码,方法或类膨胀到难以维护,一般是长期积累形成,从未人尝试瘦身. 这包括: 长方法,大类,长的参数列表,偏爱使用原始类型,数据块 对 OO 的滥用 对面向对象原则的不正确或一知半解. switch 语句, 临时字段, 拒绝继承,Alternative classes with different interfaces 阻碍改变 修改一处,要同时修改很多处.程序开发变得越来越复杂和麻烦. Divergent Change , Shortgun Surgery, Parallel Inher

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

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

代码坏味道 - 耦合

耦合 Feature Envy 症状: 方法访问其他类的对象的属性,而不是自己的. 成因: 最常见的问题就是由数据类引起的. 治疗: 多数时候,同时需要做出改变的code 应该在一起. 收益: 不合适的亲密 症状: 一个类有大量的访问另一个类的属性和方法,类之间的联系千丝万缕. 成因: 治疗: 变双向依赖为单向 单点接触 收益: 消息链 症状: a.b().c().d() 有什么不好吗? 客户对这关系知道的太多了,修改关系就意味着修改所有客户. 成因: 治疗: 隐藏委托,变单点接触.a 通过b