|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
一个很大的类库。应用程序之所以难以跨平台,在于直接调用了特定平台的接口,而一个巨大的类库,就能极大地减少应用程序对平台的依赖。16,封装前提
观点:本文中的“封装前提”是指前提干系对照庞大时,代码的可读性会对照差,以是这时候我们应该依据前提表达式是不是必要参数将前提表达式提取成可读性更好的属性大概办法,假如前提表达式不必要参数则能够提取成属性,假如前提表达式必要参数则能够提取成办法。
总结:这个重构在很年夜水平上能改良代码的可读性,特别是在一个逻辑很庞大的使用中,把这些前提判别封装成一个成心义的名字,如许很庞大的逻辑也会立即变得复杂起来。
17,提取父类
观点:本文中的“提取父类”是指类中有一些字段或办法,你想把它们提取到父类中以便统一承继条理的别的类也能够会见他们,这个和之前的良多重构有殊途同归的地方。
总结:这个重构是典范的承继用法,良多程序员城市选择如许做,可是要注重准确的利用,不要形成过分利用了承继,假如过分利用了,请思索用接口、组合和聚合来完成。
18,利用前提判别取代非常
观点:本文中的“利用前提判别取代非常”是指把没有需要利用非常做判别的前提只管改成前提判别。
总结:这个重构在项目代码中也常常用到,由于关于一部分程序员,是很难掌控甚么时分用trycatch,甚么中央该用trycatch。记得之前人人还专门会商过这些,好比怎样用好和在年夜中型项目中应当把它放在哪个组件中等。
19,提取工场类
观点:本文中的“提取工场类”是指假如要创立的工具良多,则代码会变的很庞大。一种很好的办法就是提取工场类。
总结:这个重构常常会在项目中利用,假如要创立的工具是一个,你能够接纳复杂工场,可是这类体例仍是会存在良多依附,保护起来也对照不便利。以是保举利用工场办法形式,把实例化提早到子类。假如你要创立一系列的工具,那末就保举你利用笼统工场形式,可是要注重不要过分计划,只需能满意不休变更的需乞降赐与后的保护和重构带来便利便可。
20,提取子类
观点:本文中的”提取子类”是指把基类中的一些不是一切子类都必要会见的办法调剂到子类中。
总结:这个重构办法常常用来标准类的职责,和之前的一些重构办法也有些相似。
21,兼并承继
观点:本文中的”兼并承继”是指假如子类的属性和办法也合适于基类,那末就能够移除子类,从而削减依附干系。
注释:上一篇我们讲到“提取子类”重构是指当基类中的一个义务不被一切的子类所必要时,将这些义务提取到符合的子类中。而我们明天所要讲的的“兼并承继”重构一样平常用在当我们以为不必要子类的时分。
总结:这篇和上篇实在最次要叙述了子类和父类的承继干系和怎样判别甚么时分必要利用承继,一样平常我们都能处置好这些干系,以是绝对对照复杂。
22,分化办法
观点:本文中的”分化办法”是指把我们所做的这个功效一直的分化办法,直到将一个小气法分化为名字成心义且可读性更好的多少个小办法。
总结:实在这个重构和我们后面讲的“提取办法”和“提取办法工具”一模一样,特别是“提取办法”,以是人人只需晓得用这类头脑重构就行。
23,引进参数工具
观点:本文中的“引进参数工具”是指当一个办法的参数过量大概过为庞大时,能够思索把这些参数封装成一个独自的类。
注释:假如一个办法所必要的参数年夜于5个,了解该办法的署名就变得对照坚苦,由于如许感到参数很长、款式欠好而且没有分类,以是我们有需要把参数举行封装。
总结:这类重构很主要,特别是当一个办法的参数对照多的时分,不论是年夜中型项目仍是小型项目,城市碰到这类场景,以是倡议人人多利用这个重构。这类封装的头脑在SOA内里也常常使用到,封装输出Message,封装输入Message,动静来和动静往和动静间的交互就组成了全部使用系统。
24,分化庞大判别
观点:本文中的”分化庞大判别”是指把本来庞大的前提判别等语句用尽快前往等体例简化代码。
注释:复杂的来讲,当你的代码中有很深的嵌套前提时,花括号就会在代码中构成一个长长的箭头。我们常常在分歧的代码中看到这类情形,而且这类情形也会侵扰代码的可读性。那末重构很复杂,假如有大概的话,我们让代码在做处置义务之前先反省前提,假如前提不满意就尽快前往,不持续实行。
总结:这个重构很主要,它和前面讲的”尽快前往“有些相似,我们在做庞大的处置历程时,要常常思索这个重构,用好了它,会对我们的匡助很年夜。
25,引进左券式计划
观点:本文中的”引进左券式计划”是指我们应当对输出和输入举行考证,以确保体系不会呈现我们所设想不到的非常和得不到我们想要的了局。
注释:左券式计划划定办法应当对输出和输入举行考证,如许你即可以包管你失掉的数据是能够事情的,统统都是按预期举行的,假如不是按预期举行,非常或是毛病就应当被前往。
总结:微软在处置代码以致产物的时分,很喜好使用此重构,你假如仔细看它的代码库,仔细看一下WCF的计划,就不难发明了。这个重构倡议人人常常利用,这会加强全部体系的不乱性和强健性。
26,制止两重否认
观点:本文中的”制止两重否认”是指把代码中的两重否认语句修正成复杂的一定语句,如许即让代码可读,同时也给保护带来了便利。
注释:制止两重否认重构自己十分简单完成,但我们却在太多的代码中见过由于两重否认下降了代码的可读性乃至于十分让人简单曲解真正企图。存在两重否认的代码具有十分年夜的伤害性,由于这类范例的代码简单引发毛病的假定,毛病的假定又会招致誊写堕落误的保护代码,终极会招致bug发生。
举个例子:某类中有个属性IsNotFlagged,意义就是“是不是没有标志”,那末我们在判别“有标志”时,就要if(!IsNotFlagged),这很让人隐晦,由于!就代表否认的意义,而这里的!IsNotFlagged却代表一定。准确的做法是将IsNotFlagged属性改成IsFlagged。
总结:”两重否认“很简单让人发生毛病的判别,也很难让人了解你的代码,以是这个重构在我们的代码中是很主要的,特别是在判别前提良多且营业庞大的时分。
27,往除天主类
观点:本文中的”往除天主类”是指把一个看似功效很强且很难保护的类,依照职责把本人的属性或办法分拨到各自的类中或分化乐成能明白的类,从而往失落天主类。
注释:我们常常能够在一些本来的代码中见到一些类明白违背了SRP准绳(单一准绳),这些类一般以“Utils”或“Manager”或“Tools”后缀开头,但偶然这些类也没有这些特性,它仅仅是多个类多个办法的组合。另外一个关于天主类的特性是一般这些类中的办法被用正文分开为分歧的分组。那末一朝一夕,这些类被转换为那些没有人乐意举行合并到符合类的办法的会萃地,对这些类举行重构是将类中的代码依照职责分拨到各自的类中,如许就排除了天主类,也加重了保护的包袱。
总结:“往除天主类”是我们常常简单酿成的,第一是由于烦琐,看到有一个现成的类,人人城市喜好把代码往内里写,最初招致越写越年夜,而且声明功效都有,如许即下降了可读性,也形成了保护的包袱。
28,为布尔办法定名
观点:本文中的”为布尔办法定名”是指假如一个办法带有大批的bool参数时,能够依据bool参数的数目,提掏出多少个自力的办法来简化参数。
注释:我们如今要说的重构并非一般字面意义上的重构,它有良多值得会商的中央。当一个办法带有大批的bool参数时,会招致办法很简单被曲解并发生非预期的举动,
publicclassBankAccount
{
publicvoidCreateAccount(Customercustomer,boolwithChecking,boolwithSavings,boolwithStocks)
{
//dowork
}
}
我们能够将下面的bool参数以自力办法的情势表露给挪用端以进步代码的可读性,同时我们还必要将本来的办法改成private以限定其可会见性。明显我们关于要提取的自力办法会有一个很年夜的分列组合,这是一年夜弱点,以是我们能够思索引进”参数工具“重构。
publicclassBankAccount
{
publicvoidCreateAccountWithChecking(Customercustomer)
{
CreateAccount(customer,true,false);
}
publicvoidCreateAccountWithCheckingAndSavings(Customercustomer)
{
CreateAccount(customer,true,true);
}
privatevoidCreateAccount(Customercustomer,boolwithChecking,boolwithSavings)
{
//dowork
}
}
总结:“为布尔办法定名”这个重构在良多时分都不经常使用,假如用户的参数可列举,我们一样平常会列举它的值,不外利用这类重构也有优点,就是分化开来今后,办法多了,参数少了,代码保护起来便利了一些。
29,往除两头人工具
观点:本文中的”往除两头人工具”是指把在两头联系关系而不起任何其他感化的类移除,让有干系的两个类间接举行交互。
注释:有些时分在我们的代码会存在一些”鬼魂类“,计划形式大家Fowler称它们为“两头人”类,“两头人”类除挪用其余工具以外不做任何事变,以是“两头人”类没有存在的需要,我们能够将它们从代码中删除,从而让交互的两个类间接联系关系。
总结:“往除两头人工具”良多时分城市很有感化,特别是在误用计划形式的代码中最简单见到,计划形式中的适配器形式和代办署理形式等都用两头的类是二者举行联系关系,这是对照公道的,由于两头类做了良多事变,而关于没有任何感化的两头类应当移除。
30,尽快前往
观点:本文中的”尽快前往”是指把本来庞大的前提判别等语句用尽快前往的体例简化代码。
注释:如起首声明的是后面讲的”分化庞大判别“,复杂的来讲,当你的代码中有很深的嵌套前提时,花括号就会在代码中构成一个长长的箭头。我们常常在分歧的代码中看到这类情形,而且这类情形也会侵扰代码的可读性。
有些隐形的判别,大概良多情形下看不出来,也必要多注重,以下示例:
publicclassOrder
{
publicCustomerCustomer{get;privateset;}
publicdecimalCalculateOrder(Customercustomer,IEnumerable<Product>products,decimaldiscounts)
{
Customer=customer;
decimalorderTotal=0m;
if(products.Count()>0)
{
orderTotal=products.Sum(p=>p.Price);
if(discounts>0)
{
orderTotal-=discounts;
}
}
returnorderTotal;
}
}
重构后以下:
publicclassOrder
{
publicCustomerCustomer{get;privateset;}
publicdecimalCalculateOrder(Customercustomer,IEnumerable<Product>products,decimaldiscounts)
{
if(products.Count()==0)
return0;
Customer=customer;
decimalorderTotal=products.Sum(p=>p.Price);
if(discounts==0)
returnorderTotal;
orderTotal-=discounts;
returnorderTotal;
}
}
总结:这个重构很主要,它和后面讲的”分化庞大判别“有些相似,我们在做庞大的处置历程时,要常常思索这个重构,用好了它,会对我们的匡助很年夜。
31,利用多态取代前提判别
观点:本文中的”利用多态取代前提判别”是指假如你必要反省工具的范例大概依据范例实行一些操纵时,一种很好的举措就是将算法封装到类中,并使用多态性举行笼统挪用。
注释:本文展现了面向工具编程的基本之一“多态性”,偶然你必要反省工具的范例大概依据范例实行一些操纵时,一种很好的举措就是将算法封装到类中,并使用多态性举行笼统挪用。
以下面示例:
publicabstractclassCustomer
{}
publicclassEmployee:Customer
{}
publicclassNonEmployee:Customer
{}
publicclassOrderProcessor
{
publicdecimalProcessOrder(Customercustomer,IEnumerable<Product>products)
{
decimalorderTotal=products.Sum(p=>p.Price);
TypecustomerType=customer.GetType();
if(customerType==typeof(Employee))
{
orderTotal-=orderTotal*0.15m;
}
elseif(customerType==typeof(NonEmployee))
{
orderTotal-=orderTotal*0.05m;
}
returnorderTotal;
}
}
该示例我们在OrderProcessor类的ProcessOrder办法中判别客户的范例,然后依据范例赐与分歧的扣头。
重构后的代码以下:
publicabstractclassCustomer
{
publicabstractdecimalDiscountPercentage{get;}
}
publicclassEmployee:Customer
{
publicoverridedecimalDiscountPercentage
{
get{return0.15m;}
}
}
publicclassNonEmployee:Customer
{
publicoverridedecimalDiscountPercentage
{
get{return0.05m;}
}
}
publicclassOrderProcessor
{
publicdecimalProcessOrdedr(Customercustomer,IEnumerable<Product>products)
{
decimalorderTotal=products.Sum(p=>p.Price);
orderTotal-=orderTotal*customer.DiscountPercentage;
returnorderTotal;
}
}
重构后我们每品种型的客户就已包括了本人的扣头率,对利用者ProcessOrdedr来讲,就复杂多了。
总结:“利用多态取代前提判别”这个重构在良多时分会呈现计划形式中(罕见的工场家属、战略形式等都能够看到它的影子),由于使用它能够省往良多的前提判别,同时也能简化代码、标准类和工具之间的职责。兄弟们,想来你们都看过了昨天的比赛了。我现在的痛苦状跟当时应该差不多。希望本版.net老师不吝赐教,为小弟这一批迷途的羊羔指一条阳光之道!您也知道:学习技术如果只有一个人摸索,那是一件多么痛苦的事情!还有,如果万辛能得名师或长者指点,那又是多么一件幸福和快乐的事情! |
|