您的位置:首页 > 编程语言 > C#

C#编码简单性之函数篇(如何编写简短的C#代码,随时更新)

2011-04-29 23:36 585 查看
作者:陈勇

出处:blog.csdn.net/cheny_com

这是编码简单性系列中的其中一篇,之前几篇包括代码篇和语义篇。

因为要积累案例,会随时更新。

之前提到:编码简单性的“心法”就是:只要屏幕上有任何两部分代码看上去相似,则一定有合并办法。
但在代码层面,无论如何简化,都常常剩下一堆相似代码,这时候就需要编写函数了。

这里指的函数,包括HtmlHelper这类用C#解决Html的函数。

应随时关注代码中的“不简洁”现象,一旦放任其发生,软件将很难维护。

案例1 从Html代码抽取MVC HtmlHelper

为了在屏幕上显示一些大按钮(下方显示其文字),编写了这些代码。为了对齐/消除边框/Hover效果等,动用了几个class来设置格式。按钮很多,所以需要相当数量的拷贝粘贴,其中文字-alt-title还是重复的,每次都要改动三个地方……

这些,都是代码正在变复杂的坏味道。

以其中两次重复为例,说明修改方法:

<td class = "noborder nopaddingv">
<div class = "aligncenter">
<a href="/Home/Index">
<img src="../../Resouces/Images/Agile/Menu/Campass48.png" alt = "站点地图" title = "站点地图" class = "imagelink"/></a><br />
站点地图
</div>
</td>
<td class = "noborder nopaddingv">
<div class = "aligncenter">
<a href="/Home/Index" target = "_blank">
<img src="../../Resouces/Images/Agile/Help/Help48.png" alt = "帮助" title = "帮助" class = "imagelink"/></a><br />
帮助
</div>
</td>

手段就是做HtmlHelper(以前没做过复杂的,所以推到现在才做),结果是:

@Html.MenuImageButtonV("站点地图", false, "/Home/Index", "../../Resouces/Images/Agile/Menu/Campass48.png")
@Html.MenuImageButtonV("帮助", true, "/Home/Index", "../../Resouces/Images/Agile/Help/Help48.png")

Helper的内容就不展示了,网上一查都会。唯一说明的就是class变成了style,因为在函数内部引用class是危险的,不能保证被复用后class也在。

突然想起来当年曾经写过一句话很好地概括了这种技法:当两段代码相同时,可以变成一个函数和两次调用,相同的部分就是函数,不同的部分就是调用参数。

可以看到本例中,只有文字(title/alt)、是否新窗口打开、链接、图片不同,所以就是一个有四个参数的函数。

案例2 2011-05-04 函数接口的简洁性

不是编写了函数就万事大吉了,不好的函数接口依然不简洁。下面是一个刚改好的例子:

@Html.ImageLink("燃烧图", true, "../../Resouces/Images/Agile/CurrentSprint/BurndownData16.png", "icons", false, "/Agile/CurrentSprint/BurndownData", null, null)

@Html.ImageLink("迭代计划", true, "../../Resouces/Images/Agile/Sprints/Index16.png", "icons", false, "/Agile/Sprints/Index", null, null)

...

像这样的函数重复上几回也很让人头痛的,关键臭长的函数还看不到尾部,很容易出错或影响阅读。

这时候的技法是:如果函数在重复调用时有些参数变化,有些参数基本不变("icons", true, false, null....),后者应该变成一些可选参数并设置缺省值。

修改后的结果(另外一段代码):

@Html.ImageLink("迭代计划", "/Agile/Sprints/Index", true) //这个true有些地方不太一样所以留下了。
@Html.ImageLink("迭代故事", "/Agile/Sprints/SprintStories", true)

...
唯一的不太好理解的是图片的链接哪去了。我在后台目录做了一套命名规则,若imgPath为缺省值null,则会根据命名规则生成默认图片名称,保证图片可以用Area/Controller/Actoin定位。这样也简化了实现和维护,不用去在脑海里便维护一套图片与链接的对应关系,也是编码简单性的一种体现。

案例3 2011-05-04 MS Chart Winform版本与MVC3 Razor Helper的比较

在Winform版本中,一个Chart除了要在aspx中放置控件外,还要这样设置参数:

Chart1.Series["Series1"].ChartType = (SeriesChartType) Enum.Parse( typeof(SeriesChartType);

Chart1.Series["Series2"].ChartType = (SeriesChartType) Enum.Parse( typeof(SeriesChartType); ChartTypeList.SelectedItem.Text, true );

Chart1.Series["Series1"].IsValueShownAsLabel = true;
Chart1.Series["Series2"].IsValueShownAsLabel = true;
Chart1.Series["Series1"]["LabelStyle"] = PointLabelsList.SelectedItem.Text;
Chart1.Series["Series2"]["LabelStyle"] = PointLabelsList.SelectedItem.Text;
...

这是非常难读的代码,至少相当的不直观,MVC3的程序员显然要厉害得多(应该是MS意识最好的程序员了,要不做好不MVC),他们的代码长得这个样子:

new Chart(400, 200, ChartTheme.Blue)
.AddTitle(title)
.DataBindTable(data, "X")
.Write("png");
看来是由于工作量问题,beta版本实际上只实现了很有限的几个函数,但实现得却很漂亮。按照这种风格写上面那个Chart1,应该是(仅展示风格):

new Chart()

.AddSeries( new Series("Series1",

ChartType: (SeriesChartType) Enum.Parse( typeof(SeriesChartType)),

IsValueShownAsLabel: true)

.AddLable( new Label(

LableStyle:PointLabelsList.SelectedItem.Text)

....

这种风格很类似JQuery中的风格,是一种“写得少,做得多”的风格,其心法就是:代码里边没有任何两个地方看上去相似。

案例4 2011-05-05 函数接口不简洁的深层原因

01年左右曾经有一家国内排名前3的家电厂商做了一款机顶盒在我们公司联合测试。此机顶盒稳定性很差,其程序员长驻现场有问题就改,而问题也从不停息,比同期测试的其他几家机顶盒差很多。一年后有一个偶然的机会被请去评价一段机顶盒代码是否可用,从函数名称等蛛丝马迹判断就是这个厂家的代码,答案是:不可用。

那些代码外观的第一感觉是像一篇小说,每行都很长,能自成段落的都有,有点像案例3中开始不好的代码且更甚之,最后对代码进行了局部改造,量化评价的结果是实际所需代码大概是已有代码的1/6。

怎么才能变成案例3里边后面那种长得像诗词而不是小说的代码呢?

当时我们分析那段机顶盒代码,问题出在类的封装上,总结一下包括:

1. 类的内聚性不好,多数函数属于哪个类都不好,因为哪个类的变量都不足以支撑计算,只得在单独声明一个函数(当时是用C++,C#不允许了),传入大量类。

2. 类的封装不好,多数类都使用public的内部数据,很容易出现Chart1.Series["Series2"]["LabelStyle"] = ...这种从chart挖到Series,从Series挖到LableStyle才能干活的情况,所以函数调用臭长。

再深入挖掘一下形成这种结果的原因,在于多数程序员(本人也一样)都喜欢先从类的变量而非类的函数开始设计,最终导致类更适合存放数据而不适合做事。一种解决办法就是所谓调用驱动开发,就是先把要调用的代码写出来,打桩,再实现

点击下载免费的敏捷开发教材:《火星人敏捷开发手册



内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐