咱们平时的编程使命不外乎便是将相同的技能套件应用到不同的项目中去，关于大多数状况来说，这些技能都是能够满意方针的。然而，有的项目或许需求用到一些特别的技能，因而工程师们得深入研究，去寻觅那些最简略但最有用的办法。在前一篇文章中，咱们讨论了必要时能够运用的四种特别技能，这些特别技能能够创立更好的Java软件；而本文咱们将介绍一些有助于处理常见问题的通用规划战略和方针完结技能，即：
只做有意图性的优化
常量尽量运用枚举
从头界说类里边的equals()办法
尽量多运用多态性
值得留意的是，本文中描绘的技能并不是适用于一切状况。别的这些技能应该什么时候运用以及在什么当地运用，都是需求运用者经过深思熟虑的。
1.只做有意图性的优化
大型软件体系必定十分重视功用问题。尽管咱们期望能够写出最高效的代码，但许多时候，假如想对代码进行优化，咱们却无从下手。例如，下面的这段代码会影响到功用吗?
publicvoidprocessIntegers(Listintegers)
{for(Integervalue:integers){
for(inti=integers.size()-1;i>=0;i--)
{value+=integers.get(i);}}}
这就得视状况而定了。上面这段代码能够看出它的处理算法是O(n)(运用大O符号)，其间n是list集合的巨细。假如n只有5，那么就不会有问题，只会履行25次迭代。但假如是10万，那或许会影响功用了。请留意，即便这样咱们也不能判定必定会有问题。尽管此办法需求履行10亿次逻辑迭代，但会不会对功用产生影响仍然有待讨论。
例如，假设客户端是在它自己的线程中履行这段代码，而且异步等待核算完结，那么它的履行时刻有或许是能够承受的。相同，假如体系布置在了出产环境上，可是没有客户端进行调用，那咱们底子没必要去对这段代码进行优化，由于压根就不会消耗体系的全体功用。事实上，优化功用今后体系会变得更加杂乱，悲剧的是体系的功用却没有因而而进步。
最重要的是天下没有免费的午饭，因而为了降低价值，咱们通常会经过相似于缓存、循环展开或预核算值这类技能去完结优化，这样反而增加了体系的杂乱性，也降低了代码的可读性。假如这种优化能够进步体系的功用，那么即便变得杂乱，那也是值得的，可是做决议之前，有必要首要知道这两条信息：
功用要求是什么
功用瓶颈在哪里
首要咱们需求清楚地知道功用要求是什么。假如最终是在要求以内，而且最终用户也没有提出什么贰言，那么就没有必要进行功用优化。可是，当增加了新功用或许体系的数据量到达必定规划今后就有必要进行优化了，否则或许会出现问题。
在这种状况下，不应该靠直觉，也不应该依靠查看。由于即便是像MartinFowler这样有经历的开发人员也容易做一些过错的优化，正如在重构(第70页)一文中解说的那样：
假如剖析了足够多的程序今后，你会发现关于功用的风趣之处在于，大部分时刻都浪费在了体系中的一小部分代码中里边。假如对一切代码进行了相同的优化，那么最终成果便是浪费了90%的优化，由于优化过今后的代码运行得频率并不多。由于没有方针而做的优化所消耗的时刻，都是在浪费时刻。
作为一名身经百战的开发人员，咱们应该认真对待这一观点。第一次猜想不只没有进步体系的功用，而且90%的开发时刻彻底是浪费了。相反，咱们应该在出产环境(或许预出产环境中)履行常见用例，并找出在履行过程中是哪部分在消耗体系资源，然后对体系进行装备。例如消耗大部分资源的代码只占了10%，那么优化其余90%的代码便是浪费时刻。
依据剖析成果，要想运用这些常识，咱们应该从最常见的状况入手。由于这将保证实践支付的努力最终是能够进步体系的功用。每次优化后，都应该重复剖析过程。由于这不只能够保证体系的功用真的得到了改进，也能够看出再对体系进行优化后，功用瓶颈是在哪个部分(由于处理完一个瓶颈今后,其它瓶颈或许消耗体系更多的全体资源)。需求留意的是，在现有瓶颈中花费的时刻百分比很或许会增加，由于剩余的瓶颈是暂时不变的，而且跟着方针瓶颈的消除，整个履行时刻应该会削减。
尽管在Java体系中想要对概要文件进行全面查看需求很大的容量，可是仍是有一些很常见的东西能够协助发现体系的功用热门，这些东西包括JMeter、AppDynamics和YourKit。别的，还能够拜见DZone的功用监测指南，获取更多关于Java程序功用优化的信息。
尽管功用是许多大型软件体系一个十分重要的组成部分，也成为产品交给管道中自动化测验套件的一部分，可是仍是不能够盲意图且没有意图的进行优化。相反，应该对现已把握的功用瓶颈进行特定的优化。这不只能够协助咱们防止增加了体系的杂乱性，而且还让咱们少走弯路，不去做那些浪费时刻的优化。
2.常量尽量运用枚举
需求用户列出一组预界说或常量值的场景有许多，例如在web应用程序中或许遇到的HTTP响应代码。最常见的完结技能之一是新建类，该类里边有许多静态的final类型的值，每个值都应该有一句注释，描绘该值的含义是什么:
publicclassHttpResponseCodes
{publicstaticfinalintOK=200;publicstaticfinalintNOT_FOUND=404;
publicstaticfinalintFORBIDDEN=403;
}if(getHttpResponse().getStatusCode()==HttpResponseCodes.OK)
{//DosomethingiftheresponsecodeisOK}
能够有这种思路就现已十分好了，但这仍是有一些缺点：
没有对传入的整数值进行严格的校验
由所以根本数据类型，因而不能调用状况代码上的办法
在第一种状况下仅仅简略的创立了一个特定的常量来表明特别的整数值，但并没有对办法或变量进行限制，因而运用的值或许会超出界说的规模。例如:
publicclassHttpResponseHandler
{publicstaticvoidprintMessage(intstatusCode){System.out.println("Recievedstatusof"+statusCode);
}
}
HttpResponseHandler.printMessage(15000);
尽管15000并不是有用的HTTP响应代码，可是由于服务器端也没有限制客户端有必要供给有用的整数。在第二种状况下，咱们没有办法为状况代码界说办法。例如，假如想要查看给定的状况代码是否是一个成功的代码，那就有必要界说一个独自的函数:
publicclassHttpResponseCodes{publicstaticfinalintOK=200;
publicstaticfinalintNOT_FOUND=404;publicstaticfinalintFORBIDDEN=403;
publicstaticbooleanisSuccess(intstatusCode){returnstatusCode>=200&&statusCode<300;
}
}if(HttpResponseCodes.isSuccess(getHttpResponse().getStatusCode()))
{//Dosomethingiftheresponsecodeisasuccesscode}
为了处理这些问题，咱们需求将常量类型从根本数据类型改为自界说类型，并只答应自界说类的特定目标。这正是Java枚举(enum)的用处。运用enum，咱们能够一次性处理这两个问题:
publicenumHttpResponseCodes
{OK(200),FORBIDDEN(403),NOT_FOUND(404);
privatefinalintcode;HttpResponseCodes(intcode)
{this.code=code;}
publicintgetCode(){returncode;}publicbooleanisSuccess(){returncode>=200&&code<300;
}}if(getHttpResponse().getStatusCode().isSuccess())
{//Dosomethingiftheresponsecodeisasuccesscode}
相同，现在还能够要求在调用办法的时候供给有必要有用的状况代码：
publicclassHttpResponseHandler{publicstaticvoidprintMessage(HttpResponseCodestatusCode){System.out.println("Recievedstatusof"+statusCode.getCode());}}HttpResponseHandler.printMessage(HttpResponseCode.OK);
值得留意的是，举这个比方事项阐明假如是常量，则应该尽量运用枚举，但并不是说什么状况下都应该运用枚举。在某些状况下，或许期望运用一个常量来表明某个特别值，可是也答应供给其它的值。例如，咱们或许都知道圆周率，咱们能够用一个常量来捕获这个值(并重用它):
publicclassNumericConstants{publicstaticfinaldoublePI=3.14;publicstaticfinaldoubleUNIT_CIRCLE_AREA=PI*PI;}publicclassRug{privatefinaldoublearea;publicclassRun(doublearea){this.area=area;}publicdoublegetCost(){returnarea*2;}}//Createacarpetthatis4feetindiameter(radiusof2feet)RugfourFootRug=newRug(2*NumericConstants.UNIT_CIRCLE_AREA);
因而，运用枚举的规则能够概括为:
当一切或许的离散值都现已提早知道了，那么就能够运用枚举
再拿上文中所提到的HTTP响应代码为例，咱们或许知道HTTP状况代码的一切值(能够在RFC7231中找的到，它界说了HTTP1.1协议)。因而运用了枚举。在核算圆周率的状况下，咱们不知道关于圆周率的一切或许值(任何或许的double都是有用的)，但一起又期望为圆形的rugs创立一个常量，使核算更容易(更容易阅览);因而界说了一系列常量。
假如不能提早知道一切或许的值，可是又期望包括每个值的字段或办法，那么最简略的办法便是能够新建一个类来表明数据。尽管没有说过什么场景应该肯定不必枚举，但要想知道在什么当地、什么时刻不运用枚举的关键是提早意识到一切的值，而且禁止运用其他任何值。
3.从头界说类里边的equals()办法
目标辨认或许是一个很难处理的问题：假如两个目标在内存中占有相同的方位，那么它们是相同的吗?假如它们的id相同，它们是相同的吗?或许假如一切的字段都持平呢?尽管每个类都有自己的标识逻辑，可是在体系中有许多西方都需求去判别是否持平。例如，有如下的一个类，表明订单购买…
publicclassPurchase{privatelongid;publiclonggetId()
{returnid;}publicvoidsetId(longid){this.id=id;}}
……就像下面写的这样，代码中必定有许多当地都是相似于的:
PurchaseoriginalPurchase=newPurchase();PurchaseupdatedPurchase=newPurchase();
if(originalPurchase.getId()==updatedPurchase.getId())
{//Executesomelogicforequalpurchases}
这些逻辑调用的越多(反过来，违背了DRY原则)，Purchase类的身份信息也会变得越来越多。假如出于某种原因，更改了类的身份逻辑(例如，更改了标识符的类型)，则需求更新标识逻辑所在的方位必定也十分多。
咱们应该在类的内部初始化这个逻辑，而不是经过体系将类的身份逻辑进行过多的传播。乍一看，咱们能够创立一个新的办法，比方isSame，这个办法的入参是一个目标，并对每个目标的id进行比较，看看它们是否相同:
publicclassPurchase{privatelongid;publicbooleanisSame(Purchaseother){returngetId()==other.gerId();}}
尽管这是一个有用的处理方案，可是疏忽了Java的内置功用:运用equals办法。Java中的每个类都是承继了Object类，尽管是隐式的，因而相同也就承继了equals办法。默许状况下，此办法将查看目标标识(内存中相同的目标)，如JDK中的目标类界说(version1.8.0_131)中的以下代码片段所示:
publicbooleanequals(Objectobj){return(this==obj);}
这个办法充当了注入身份逻辑的天然方位(经过掩盖默许的完结):
publicclassPurchase{privatelongid;publiclonggetId(){returnid;}publicvoidsetId(longid){this.id=id;}@Overridepublicbooleanequals(Objectother){if(this==other){returntrue;}elseif(!(otherinstanceofPurchase)){returnfalse;}else{return((Purchase)other).getId()==getId();}}}
尽管这个办法看起来很杂乱，但由于办法只承受类型目标的参数，所以咱们只需求考虑三个案例:
另一个目标是当时目标(即originalPurchase.equals(originalPurchase))，依据界说，它们是同一个目标，因而回来true
另一个目标不是Purchase目标，在这种状况下，咱们无法比较的id，因而，这两个目标不持平
其他目标不是同一个目标，但却是的实例,因而,是否持平取决于当时的id和其他是否持平
现在能够重构咱们之前的条件，如下:
PurchaseoriginalPurchase=newPurchase();
PurchaseupdatedPurchase=newPurchase();if(originalPurchase.equals(updatedPurchase)){//Executesomelogicforequalpurchases}
除了能够在体系中削减仿制，重构默许的equals办法还有一些其它的优势。例如，假如结构一个目标列表，并查看列表是否包括具有相同ID(内存中不同目标)的另一个目标，那么咱们就会得到true值，由于这两个值被认为是持平的:
Listpurchases=newArrayList<>();
purchases.add(originalPurchase);purchases.contains(updatedPurchase);//True
通常，不管在什么当地，假如需求判别两个类是否持平，则只需求运用重写过的办法就能够了。假如期望运用由于承继了目标而隐式具有的办法去判别持平性，咱们还能够运用==操作符，如下:
if(originalPurchase==updatedPurchase){//Thetwoobjectsarethesameobjectsinmemory}
还需求留意的是，当办法被重写今后，hashCode办法也应该被重写。有关这两种办法之间联系的更多信息，以及怎么正确界说办法，请拜见此线程。
正如咱们所看到的，重写办法不只能够将身份逻辑在类的内部进行初始化，并在整个体系中削减了这种逻辑的分散，它还答应Java语言对类做出有依据的决议。
4.尽量多运用多态性
关于任何一门编程语言来说，条件句都是一种很常见的结构，而且它的存在也是有必定原因的。由于不同的组合能够答应用户依据给定值或目标的瞬时状况改动体系的行为。假设用户需求核算各银行账户的余额，那么就能够开宣布以下的代码:
publicenumBankAccountType
{CHECKING,SAVINGS,CERTIFICATE_OF_DEPOSIT;}publicclassBankAccount{privatefinalBankAccountTypetype;
publicBankAccount(BankAccountTypetype){this.type=type;
}publicdoublegetInterestRate(){switch(type){caseCHECKING:return0.03;//3%caseSAVINGS:return0.04;//4%caseCERTIFICATE_OF_DEPOSIT:return0.05;
//5%default:thrownewUnsupportedOperationException();
}
}
publicbooleansupportsDeposits(){switch(type)
{caseCHECKING:returntrue;caseSAVINGS:returntrue;caseCERTIFICATE_OF_DEPOSIT:returnfalse;default:thrownewUnsupportedOperationException();
}
}
}
尽管上面这段代码满意了根本的要求，可是有个很明显的缺陷:用户仅仅依据给定帐户的类型决议体系的行为。这不只需求用户每次要做决议之前都需求查看账户类型，还需求在做出决议时重复这个逻辑。例如，在上面的规划中，用户有必要在两种办法都进行查看才能够。这就或许会出现失控的状况，特别是接收到增加新帐户类型的需求时。
咱们能够运用多态来隐式地做出决议计划，而不是运用账户类型用来区别。为了做到这一点，咱们将BankAccount的详细类转换成一个接口，并将决议计划过程传入一系列详细的类，这些类代表了每种类型的银行帐户:
publicinterfaceBankAccount
{publicdoublegetInterestRate();publicbooleansupportsDeposits();
}publicclassCheckingAccountimplementsBankAccount{@OverridepublicdoublegetIntestRate()
{return0.03;}@OverridepublicbooleansupportsDeposits(){returntrue;}}publicclassSavingsAccountimplementsBankAccount
{@OverridepublicdoublegetIntestRate(){return0.04;}@OverridepublicbooleansupportsDeposits(){returntrue;
}
}
publicclassCertificateOfDepositAccountimplementsBankAccount
{@OverridepublicdoublegetIntestRate(){return0.05;
}@OverridepublicbooleansupportsDeposits(){returnfalse;
}
}
这不只将每个帐户特有的信息封装到了到自己的类中，而且还支持用户能够在两种重要的办法中对规划进行改变。首要，假如想要增加一个新的银行帐户类型，只需创立一个新的详细类，完结了BankAccount的接口，给出两个办法的详细完结就能够了。在条件结构规划中，咱们有必要在枚举中增加一个新值，在两个办法中增加新的case句子，并在每个case句子下插入新帐户的逻辑。
其次，假如咱们期望在BankAccount接口中增加一个新办法，咱们只需在每个详细类中增加新办法。在条件规划中，咱们有必要仿制现有的switch句子并将其增加到咱们的新办法中。此外，咱们还有必要在每个case句子中增加每个帐户类型的逻辑。
在数学上，当咱们创立一个新办法或增加一个新类型时，咱们有必要在多态和条件规划中做出相同数量的逻辑更改。例如，假如咱们在多态规划中增加一个新办法，咱们有必要将新办法增加到一切n个银行帐户的详细类中，而在条件规划中，咱们有必要在咱们的新办法中增加n个新的case句子。假如咱们在多态规划中增加一个新的account类型，咱们有必要在BankAccount接口中完结一切的m数，而在条件规划中，咱们有必要向每个m现有办法增加一个新的case句子。
尽管咱们有必要做的改动的数量是持平的，但改变的性质却是彻底不同的。在多态规划中，假如咱们增加一个新的帐户类型而且忘掉包括一个办法，编译器会抛出一个过错，由于咱们没有在咱们的BankAccount接口中完结一切的办法。在条件规划中，没有这样的查看，以保证每个类型都有一个case句子。假如增加了新类型，咱们能够简略地忘掉更新每个switch句子。这个问题越严重，咱们就越重复咱们的switch句子。咱们是人类，咱们倾向于犯过错。因而，任何时候，只需咱们能够依赖编译器来提醒咱们过错，咱们就应该这么做。
关于这两种规划的第二个重要留意事项是它们在外部是等同的。例如，假如咱们想要查看一个支票帐户的利率，条件规划就会相似如下:
BankAccountcheckingAccount=newBankAccount(BankAccountType.CHECKING);System.out.println(checkingAccount.getInterestRate());//Output:0.03
相反，多态规划将相似如下:
BankAccountcheckingAccount=newCheckingAccount();System.out.println(checkingAccount.getInterestRate());//Output:0.03
从外部的视点来看，咱们仅仅在BankAccount目标上调用getintereUNK()。假如咱们将创立过程抽象为一个工厂类的话，这将更加明显:
publicclassConditionalAccountFactory{publicstaticBankAccountcreateCheckingAccount(https://zzzjtd.com){returnnewBankAccount(BankAccountType.CHECKING);}}publicclassPolymorphicAccountFactory{publicstaticBankAccountcreateCheckingAccount(){returnnewCheckingAccount();}}//Inbothcases,wecreatetheaccountsusingafactoryBankAccountconditionalCheckingAccount=ConditionalAccountFactory.createCheckingAccount();BankAccountpolymorphicCheckingAccount=PolymorphicAccountFactory.createCheckingAccount();//Inbothcases,thecalltoobtaintheinterestrateisthesameSystem.out.println(conditionalCheckingAccount.getInterestRate());//Output:0.03System.out.println(polymorphicCheckingAccount.getInterestRate());//Output:0.03
将条件逻辑替换成多态类是十分常见的，因而现已发布了将条件句子重构为多态类的办法。这里就有一个简略的比方。此外，马丁·福勒(MartinFowler)的《重构》(p.255)也描绘了履行这个重构的详细过程。
就像本文中的其他技能相同，关于何时履行从条件逻辑转换到多态类，没有硬性规定。事实上，如论在何种状况下咱们都是不主张运用。在测验驱动的规划中：例如，KentBeck规划了一个简略的货币体系，意图是运用多态类，但发现这使规划过于杂乱，所以便将他的规划从头规划成一个非多态风格。经历和合理的判别将决议何时是将条件代码转换为多态代码的合适时刻。
结束语
作为程序员，尽管往常所运用的惯例技能能够处理大部分的问题，但有时咱们应该打破这种惯例，自动需求一些立异。毕竟作为一名开发人员，扩展自己常识面的的广度和深度，不只能让咱们做出更正确的决议，也能让咱们变得越来越聪明。
