外文翻译-Java 编程指南

外文原文JavaProgrammingGuidelinesThisappendixcontainssuggestionstohelpguideyouinperforminglow-levelprogramdesignandinwritingcode.Naturally,theseareguidelinesandnotrules.Theideaistousethemasinspirationsandtorememberthatthereareoccasionalsituationswheretheyshouldbebentorbroken.Elegancealwayspaysoff.Intheshorttermitmightseemlikeittakesmuchlongertocomeupwithatrulygracefulsolutiontoaproblem,butwhenitworksthefirsttimeandeasilyadaptstonewsituationsinsteadofrequiringhours,days,ormonthsofstruggle,youllseetherewards(evenifnoonecanmeasurethem).Notonlydoesitgiveyouaprogramthatseasiertobuildanddebug,butitsalsoeasiertounderstandandmaintain,andthatswherethefinancialvaluelies.Thispointcantakesomeexperiencetounderstand,becauseitcanappearthatyourenotbeingproductivewhileyouremakingapieceofcodeelegant.Resisttheurgetohurry;itwillonlyslowyoudown.Firstmakeitwork,thenmakeitfast.Thisistrueevenifyouarecertainthatapieceofcodeisreallyimportantandthatitwillbeaprincipalbottleneckinyoursystem.Dontdoit.Getthesystemgoingfirstwithassimpleadesignaspossible.Thenifitisntgoingfastenough,profileit.Youllalmostalwaysdiscoverthat“your”bottleneckisnttheproblem.Saveyourtimeforthereallyimportantstuff.Rememberthe“divideandconquer”principle.Iftheproblemyourelookingatistooconfusing,trytoimaginewhatthebasicoperationoftheprogramwouldbe,giventheexistenceofamagic“piece”thathandlesthehardparts.That“piece”isanobjectwritethecodethatusestheobject,thenlookattheobjectandencapsulateitshardpartsintootherobjects,etc.Separatetheclasscreatorfromtheclassuser(clientprogrammer).Theclassuseristhe“customer”anddoesntneedorwanttoknowwhatsgoingonbehindthescenesoftheclass.Theclasscreatormustbetheexpertinclassdesignandwritetheclasssothatitcanbeusedbythemostnoviceprogrammerpossible,yetstillworkrobustlyintheapplication.Thinkoftheclassasaserviceproviderforotherclasses.Libraryusewillbeeasyonlyifitstransparent.Whenyoucreateaclass,attempttomakeyournamessoclearthatcommentsareunnecessary.Yourgoalshouldbetomaketheclientprogrammersinterfaceconceptuallysimple.Tothisend,usemethodoverloadingwhenappropriatetocreateanintuitive,easy-to-useinterface.Youranalysisanddesignmustproduce,atminimum,theclassesinyoursystem,theirpublicinterfaces,andtheirrelationshipstootherclasses,especiallybaseclasses.Ifyourdesignmethodologyproducesmorethanthat,askyourselfifallthepiecesproducedbythatmethodologyhavevalueoverthelifetimeoftheprogram.Iftheydonot,maintainingthemwillcostyou.Membersofdevelopmentteamstendnottomaintainanythingthatdoesnotcontributetotheirproductivity;thisisafactoflifethatmanydesignmethodsdontaccountfor.Automateeverything.Writethetestcodefirst(beforeyouwritetheclass),andkeepitwiththeclass.AutomatetherunningofyourteststhroughabuildtoolyoullprobablywanttouseAnt,thedefactostandardJavabuildtool.Thisway,anychangescanbeautomaticallyverifiedbyrunningthetestcode,andyoullimmediatelydiscovererrors.Becauseyouknowthatyouhavethesafetynetofyourtestframework,youwillbebolderaboutmakingsweepingchangeswhenyoudiscovertheneed.Rememberthatthegreatestimprovementsinlanguagescomefromthebuilt-intestingprovidedbytypechecking,exceptionhandling,etc.,butthosefeaturestakeyouonlysofar.Youmustgotherestofthewayincreatingarobustsystembyfillingintheteststhatverifyfeaturesthatarespecifictoyourclassorprogram.Writethetestcodefirst(beforeyouwritetheclass)inordertoverifythatyourclassdesigniscomplete.Ifyoucantwritetestcode,youdontknowwhatyourclasslookslike.Inaddition,theactofwritingthetestcodewilloftenflushoutadditionalfeaturesorconstraintsthatyouneedintheclassthesefeaturesorconstraintsdontalwaysappearduringanalysisanddesign.Testsalsoprovideexamplecodeshowinghowyourclasscanbeused.Allsoftwaredesignproblemscanbesimplifiedbyintroducinganextralevelofconceptualindirection.Thisfundamentalruleofsoftwareengineering122isthebasisofabstraction,theprimaryfeatureofobject-orientedprogramming.InOOP,wecouldalsosaythisas:“Ifyourcodeistoocomplicated,makemoreobjects.”Anindirectionshouldhaveameaning(inconcertwithguideline9).Thismeaningcanbesomethingassimpleas“puttingcommonlyusedcodeinasinglemethod.”Ifyouaddlevelsofindirection(abstraction,encapsulation,etc.)thatdonthavemeaning,itcanbeasbadasnothavingadequateindirection.Makeclassesasatomicaspossible.Giveeachclassasingle,clearpurposeacohesiveservicethatitprovidestootherclasses.Ifyourclassesoryoursystemdesigngrowstoocomplicated,breakcomplexclassesintosimplerones.Themostobviousindicatorofthisissheersize;ifaclassisbig,chancesareitsdoingtoomuchandshouldbebrokenup.Cluestosuggestredesignofaclassare:1)Acomplicatedswitchstatement:considerusingpolymorphism.2)Alargenumberofmethodsthatcoverbroadlydifferenttypesofoperations:considerusingseveralclasses.3)Alargenumberofmembervariablesthatconcernbroadlydifferentcharacteristics:considerusingseveralclasses.4)OthersuggestionscanbefoundinRefactoring:ImprovingtheDesignofExistingCodebyMartinFowler(Addison-Wesley1999).Watchforlongargumentlists.Methodcallsthenbecomedifficulttowrite,read,andmaintain.Instead,trytomovethemethodtoaclasswhereitis(more)appropriate,and/orpassobjectsinasarguments.Dontrepeatyourself.Ifapieceofcodeisrecurringinmanymethodsinderivedclasses,putthatcodeintoasinglemethodinthebaseclassandcallitfromthederived-classmethods.Notonlydoyousavecodespace,butyouprovideforeasypropagationofchanges.Sometimesthediscoveryofthiscommoncodewilladdvaluablefunctionalitytoyourinterface.Asimplerversionofthisguidelinealsooccurswithoutinheritance:Ifaclasshasmethodsthatrepeatcode,factorthatcodeintoacommonmethodandcallitfromtheothermethods.Watchforswitchstatementsorchainedif-elseclauses.Thisistypicallyanindicatoroftype-checkcoding,whichmeansthatyouarechoosingwhatcodetoexecutebasedonsomekindoftypeinformation(theexacttypemaynotbeobviousatfirst).Youcanusuallyreplacethiskindofcodewithinheritanceandpolymorphism;apolymorphicmethodcallwillperformthetypecheckingforyouandallowformorereliableandeasierextensibility.Fromadesignstandpoint,lookforandseparatethingsthatchangefromthingsthatstaythesame.Thatis,searchfortheelementsinasystemthatyoumightwanttochangewithoutforcingaredesign,thenencapsulatethoseelementsinclasses.YoucanlearnmuchmoreaboutthisconceptinThinkinginPatterns(withJava)atwww.BruceE.Dontextendfundamentalfunctionalitybysubclassing.Ifaninterfaceelementisessentialtoaclassitshouldbeinthebaseclass,notaddedduringderivation.Ifyoureaddingmethodsbyinheriting,perhapsyoushouldrethinkthedesign.Lessismore.Startwithaminimalinterfacetoaclass,assmallandsimpleasyouneedtosolvetheproblemathand,butdonttrytoanticipateallthewaysthatyourclassmightbeused.Astheclassisused,youlldiscoverwaysyoumustexpandtheinterface.However,onceaclassisinuse,youcannotshrinktheinterfacewithoutbreakingclientcode.Ifyouneedtoaddmoremethods,thatsfine;itwontbreakcode.Butevenifnewmethodsreplacethefunctionalityofoldones,leavetheexistinginterfacealone(youcancombinethefunctionalityintheunderlyingimplementationifyouwant).Ifyouneedtoexpandtheinterfaceofanexistingmethodbyaddingmorearguments,createanoverloadedmethodwiththenewarguments;thisway,youwontdisturbanycallstotheexistingmethod.Readyourclassesaloudtomakesuretheyrelogical.Refertotherelationshipbetweenabaseclassandderivedclassas“is-a”andmemberobjectsas“has-a.”Whendecidingbetweeninheritanceandcomposition,askifyouneedtoupcasttothebasetype.Ifnot,prefercomposition(memberobjects)toinheritance.Thiscaneliminatetheperceivedneedformultiplebasetypes.Ifyouinherit,userswillthinktheyaresupposedtoupcast.Usefieldsforvariationinvalue,andmethodoverridingforvariationinbehavior.Thatis,ifyoufindaclassthatusesstatevariablesalongwithmethodsthatswitchbehaviorbasedonthosevariables,youshouldprobablyredesignittoexpressthedifferencesinbehaviorwithinsubclassesandoverriddenmethods.Watchforoverloading.Amethodshouldnotconditionallyexecutecodebasedonthevalueofanargument.Inthiscase,youshouldcreatetwoormoreoverloadedmethodsinstead.UseexceptionhierarchiespreferablyderivedfromspecificappropriateclassesinthestandardJavaexceptionhierarchy.Thepersoncatchingtheexceptionscanthenwritehandlersforthespecifictypesofexceptions,followedbyhandlersforthebasetype.Ifyouaddnewderivedexceptions,existingclientcodewillstillcatchtheexceptionthroughthebasetype.Sometimessimpleaggregationdoesthejob.A“passengercomfortsystem”onanairlineconsistsofdisconnectedelements:seat,airconditioning,video,etc.,andyetyouneedtocreatemanyoftheseinaplane.Doyoumakeprivatemembersandbuildawholenewinterface?Nointhiscase,thecomponentsarealsopartofthepublicinterface,soyoushouldcreatepublicmemberobjects.Thoseobjectshavetheirownprivateimplementations,whicharestillsafe.Beawarethatsimpleaggregationisnotasolutiontobeusedoften,butitdoeshappen.Considertheperspectiveoftheclientprogrammerandthepersonmaintainingthecode.Designyourclasstobeasobviousaspossibletouse.Anticipatethekindofchangesthatwillbemade,anddesignyourclasssothatthosechangeswillbeeasy.Watchoutfor“giantobjectsyndrome.”ThisisoftenanafflictionofproceduralprogrammerswhoarenewtoOOPandwhoendupwritingaproceduralprogramandstickingitinsideoneortwogiantobjects.Withtheexceptionofapplicationframeworks,objectsrepresentconceptsinyourapplication,nottheapplicationitself.Ifyoumustdosomethingugly,atleastlocalizetheuglinessinsideaclass.Ifyoumustdosomethingnonportable,makeanabstractionforthatserviceandlocalizeitwithinaclass.Thisextralevelofindirectionpreventsthenonportabilityfrombeingdistributedthroughoutyourprogram.(ThisidiomisembodiedintheBridgePattern,amongothers).Objectsshouldnotsimplyholdsomedata.Theyshouldalsohavewell-definedbehaviors.(Occasionally,“dataobjects”areappropriate,butonlywhenusedexpresslytopackageandtransportagroupofitemswhenageneralizedcontainerisinnappropriate.)Choosecompositionfirstwhencreatingnewclassesfromexistingclasses.Youshouldonlyuseinheritanceifitisrequiredbyyourdesign.Ifyouuseinheritancewherecompositionwillwork,yourdesignswillbecomeneedlesslycomplicated.Useinheritanceandmethodoverridingtoexpressdifferencesinbehavior,andfieldstoexpressvariationsinstate.Anextremeexampleofwhatnottodoistoinheritdifferentclassestorepresentcolorsinsteadofusinga“color”field.Watchoutforvariance.Twosemanticallydifferentobjectsmayhaveidenticalactions,orresponsibilities,andthereisanaturaltemptationtotrytomakeoneasubclassoftheotherjusttobenefitfrominheritance.Thisiscalledvariance,buttheresnorealjustificationtoforceasuperclass/subclassrelationshipwhereitdoesntexist.Abettersolutionistocreateageneralbaseclassthatproducesaninterfaceforbothasderivedclasses;itrequiresabitmorespace,butyoustillbenefitfrominheritanceandwillprobablymakeanimportantdiscoveryaboutthedesign.Watchoutforlimitationduringinheritance.Theclearestdesignsaddnewcapabilitiestoinheritedones.Asuspiciousdesignremovesoldcapabilitiesduringinheritancewithoutaddingnewones.Butrulesaremadetobebroken,andifyouareworkingfromanoldclasslibrary,itmaybemoreefficienttorestrictanexistingclassinitssubclassthanitwouldbetorestructurethehierarchysoyournewclassfitsinwhereitshould,abovetheoldclass.Usedesignpatternstoeliminate“nakedfunctionality.”Thatis,ifonlyoneobjectofyourclassshouldbecreated,dontboltaheadtotheapplicationandwriteacomment“Makeonlyoneofthese.”Wrapitinasingleton.Ifyouhavealotofmessycodeinyourmainprogramthatcreatesyourobjects,lookforacreationalpatternlikeafactorymethodinwhichyoucanencapsulatethatcreation.Eliminating“nakedfunctionality”willnotonlymakeyourcodemucheasiertounderstandandmaintain,butitwillalsomakeitmorebulletproofagainstthewell-intentionedmaintainersthatcomeafteryou.Watchoutfor“analysisparalysis.”Rememberthatyoumustusuallymoveforwardinaprojectbeforeyouknoweverything,andthatoftenthebestandfastestwaytolearnaboutsomeofyourunknownfactorsistogotothenextstepratherthantryingtofigureitoutinyourhead.Youcantknowthesolutionuntilyouhavethesolution.Javahasbuilt-infirewalls;letthemworkforyou.Yourmistakesinaclassorsetofclasseswontdestroytheintegrityofthewholesystem.Whenyouthinkyouvegotagoodanalysis,design,orimplementation,doawalkthrough.Bringsomeoneinfromoutsideyourgroupthisdoesnthavetobeaconsultant,butcanbesomeonefromanothergroupwithinyourcompany.Reviewingyourworkwithafreshpairofeyescanrevealproblemsatastagewhenitsmucheasiertofixthem,andmorethanpaysforthetimeandmoney“lost”tothewalkthroughprocess.中文翻译Java编程指南这份附录包含了一些建议，在你进行详细设计和编写代码的时候可以提供帮助。就这些建议本身而言，它们只是一些指南而不是规定。你要把它们视作灵感的来源。记住，在某些情况下你要进行妥协，甚至打破这些指南的规定。1.优雅终将得到回报。从短期利益来看，要想对问题提出优雅的解决方案，似乎需要投入更多的时间，不过一旦它能够工作，就能够很容易地适应新的环境，而不是要花上数以时计，甚至以天计或以月计的辛苦代价时，这时你将得到回报（尽管没人能够准确衡量这些回报）。你得到的程序不仅易于编写和调试，而且还易于理解和维护，这就是其价值所在。明白这一点需要经验，因为你在精心设计程序的时候生产率不会很高。要抵抗住浮躁心态的诱惑；欲速则不达。2.先能运行，再求快速。即使你确信某段代码非常重要，它将成为整个系统的瓶颈，也必须遵守这一点。别着急。先尽可能简化设计，让系统运转起来。如果性能不够理想，再求助于性能分析工具。你几乎总会发现，你“以为的”那些瓶颈，其实都不是真正的问题所在。要把时间用在刀刃上。3.谨记“分而治之”原则。如果待解决的问题过于复杂，先设想一下程序的基本操作，并且假定已经有一小段“神奇代码”能够处理最困难的部分。这段“神奇代码”可以看成一个对象，你可以编写程序使用它，然后再回过头来研究这个对象，把它最困难的部分包装成其它对象，依此类推。4.区分类的编写者和使用者（客户端程序员）。作为“客户”，类的使用者不需要也不希望知道类的底层工作方式。类的编写者必须是程序设计方面的专家，这样编写出来的类有才可能在新手使用的情况下，仍然能够稳定运行。请把类想象成对其它类的“服务提供者”。程序库只有在内部实现对用户来说是透明的情况下，才会易于使用。5.编写类的时候，类的名称要非常清晰，使得注释成为多此一举。你的目标应该是提供给客户端程序员简单明了的接口。为此，在恰当的时候可以考虑方法重载，以得到直观且易于使用的接口。6.你的分析和设计所产生的系统中的类、它们的公共接口，以及类之间（尤其是与基类之间）的联系，必须达到最少。如果你在设计中产生了过多的类，请回顾一下，这些代码在程序的整个生命周期中能产生效益吗？如果并非如此，你就要付出维护的代价。对于不能提高生产率的任何东西，开发团队的成员不会自觉地进行维护；这也是许多设计方法无能为力的地方。7.尽量让所有东西自动化。首先编写测试代码（在你编写类之前），并把它和要测试的类放在一起。你可以使用某种构建工具，来自动运行测试。你也许会用到Ant，它是Java构建工具的事实标准。这样，只要执行测试程序，所有改动就可以自动获得验证，有了错误也可以立刻发现。因为你信赖测试框架所具的安全性，所以当你发现新的需求时，会大胆地进行全面修改。请记住，程序语言最大的改进，来自类型检查、异常处理等机制所赋予的内置测试行为。但这些功能只能协助你到达某种程度，其它工作还需要你自己完成。要开发一个健壮的系统，你得自己编写测试用例来验证类或程序的性质。8.在编写类之前先编写测试代码，以验证这个类是否设计完备。如果你写不出测试代码，就说明其实你还不清楚类的功能。此外，在编写测试代码的过程中，通常还能够发现类需要具有的额外特性或限制。而这些特性和限制并不总是能够通过分析和设计得到。测试代码也可作为使用类的范例。9.所有软件设计中的问题，都可以通过“从概念上引入额外的概念上的间接层次”得到简化。这是软件工程领域的基本原则1，也是抽象的依据。而抽象正是面向对象程序设计的主要性质。在面向对象编程中，我们也可以这么说：“如果代码过于复杂，那么就引入更多的对象。”10.引入的间接层次要有意义（与准则9相应）。这里所指的意义可以像“将常用代码放入一个方法内”这么简单。如果你加入了无意义的间接层次（通过抽象或封装等等），那就会和没有引入间接层一样糟糕。11.尽可能使类原子化。每个类要具有简单明了的用途，用它来向别的类提供服务。如果类或系统设计得过于复杂，请将它分割成几个较简单的类。一个最明显的判断依据就是类的大小：如果类很大，那它很可能负担太重，就应该被分割。建议重新设计类的线索有：1)复杂的switch语句：请考虑使用多态。2)有许多方法，各自处理类型极为不同的操作：请考虑划分成不同的类。3）有许多成员变量，用来表示类型极为不同的属性：请考虑划分成不同的类。12.当心冗长的参数列表。参数列表过长将使得方法调用变得难以编写、阅读和维护。你应该试着将方法放到更合适的类中，并/或使用对象作为参数。13.不要一再重复。如果某段代码不断出现于许多派生类方法中，应将该段代码置于基类的某个方法中，然后在派生类方法中进行调用。这样不仅可以减少代码数量，也易于修改。有时候，找出这种通用代码还可以为接口增加实用的功能。在不牵涉继承的情况下，也可能会遇到这种情况：如果类中的几个方法使用了重复的代码，请把这些代码移到某个AndrewKoenig为我解释了这一原则。方法里，然后在别的方法中进行调用。14.小心switch语句或嵌套的if-else语句。这通常预示着“以编程方式判断类型”的代码，也就是说究竟会执行哪一段程序代码，将依据某种类型信息来判断（开始的时候，可能不清楚确切的类型）。通常可以使用继承和多态机制来替代此类代码；多态方法在调用时会自动进行类型检查，这样更可靠，扩展起来也更容易。15.从设计观点来看，要找出变动的因素，并使它和不变的因素分离。也就是说，找出系统中可能会改变的元素，将它们封装于类中，这样就不会被迫重新设计系统。你可以在ThinkinginPatterns（withJava）（从www.BruceE下载）学习到大量的此类技术。16.不要依靠子类化来扩展基础功能。如果类接口中的某个元素非常重要，那么它应该被放进基类，而不是在继承时添加。如果你依靠派生来添加方法，也许你应该重新考虑整个设计。17.更少意味着更多。从类的最小接口开始，尽量在能够解决问题的前提下让它保持简单明了。先别急着考虑类被使用的所有方式。一旦它被实际使用，你自然会明白该如何扩展接口。不过，一旦类被使用后，你就不能在不影响用户代码的情况下缩减接口。不过加入更多方法倒没什么问题，这不会对用户代码造成影响，它们只需重新编译即可。即使用新方法取代了旧方法的功能，也请你保留原有接口（如果你愿意的话，可以在底层实现中将功能进行合并）。如果你要通过“加入更多参数”来扩充原有接口，可以用新参数写一个重载的方法；这样，就不会影响对原有方法的调用。18.大声朗读你的类，确保它们符合逻辑。使得基类和派生类之间保持“是一个”（is-a）的关系，让类和成员对象之间保持“有一个”（has-a）的关系。19.在判断应该使用继承还是组合的时候，考虑一下是否需要向上转型成基础类型。如果不需要，请优先考虑组合（也就是使用成员对象）。这样可以消除对多个基类的需求。如果你采用继承，用户会假定它们可以被向上转型。20.采用字段来表示数值的变化，使用方法重载来表示行为的变化。也就是说，如果你发现某个类中含有一些状态变量，而类的方法会根据这些状态变量表现出不同的行为，那么或许你就应该重新设计，在子类和方法的重载中表达这种行为上的差异。21.小心重载。方法不应该把参数值作为执行代码的条件。在这种情况下，你应该编写两个或多个重载方法作为替代。22.使用异常体系最好是从Java标准异常体系中派生出特定的异常类。这样，处理异常的用户便可以在捕获基本异常之后，编写处理程序来捕获指定的异常。即使你派生了新的异常类，以前的客户端代码仍然能通过基础类