Java编程准则

核心提示：java编程准则内容摘录自：《Java 编程思想》第2版《附录C J a v a 编程准则》/(美) 埃克尔(Eckel,B)著；候捷译的,机械工业出版社，2002.9 版权归原作者和原出版社，Java编程准则， 这份附录所提供的建议，可以帮助你进行低阶的程序设计， 15． 从设计观点来看，请找出变动的事物，并帮助你写

　　java编程准则内容摘录自：《Java 编程思想》第2版《附录C J a v a 编程准则》/(美) 埃克尔(Eckel,B)著；候捷译的,机械工业出版社，2002.9 版权归原作者和原出版社。 这份附录所提供的建议，可以帮助你进行低阶的程序设计，并帮助你写码。 当然，这些都只是一种方针而不是硬性规则。你应该视它们为一种灵感来源。记住，某些情况下你需要加以变通或甚至打破规则。设计 1． 优雅需要付出代价。从短期利益来看，对某个问题提出优雅的解决方法，似乎可能花你更多的时间。但当它终于能够正确执行并可轻易套用于新案例中，不需要花上数以时计，甚至以天计或以月计的辛劳代价时，你会看得到先前所花功夫的回报（即使没有人可以衡量这一点）。这不仅给你一个可更轻易开发和调试的程序，也更易于理解和维护。这正是它在金钱上的价值所在。这一点有赖某种人生经验才能够了解，因为当你努力让某一段程序代码变得比较优雅时，你并不是处于一种具生产力的状态下。但是，请抗拒那些催促你赶工的人们，因为那么做只会减缓你的速度罢了。 2． 先求能动，再求快。即使你已确定某段程序代码极为重要，而且是系统的重要瓶颈，这个准则依然成立。尽可能简化设计，让系统能够先正确动作。假如程序的执行不够快，再量测其效能。几乎你总是会发现，你所认为的"瓶颈"其实都不是问题所在。把你的时间花在刀口上吧。 3． 记住"各个击破"的原理。假如你所探讨的问题过于混杂，试着想像该问题的基本动作会是什么，并假设这一小块东西能够神奇地处理掉最难的部分。这"一小块"东西其实就是对象--请撰写运用该对象的程序代码，然后检视对象，并将其中困难的部分再包装成其他对象，依此类推。 4． 区分class开发者和class使用者（使用端程序员）。Class使用者扮演着"客户"角色，不需要（也不知道）class的底层运作方式。Class开发者必须是class设计专家，并撰写class，使它能够尽可能被大多数新手程序员所用，而且在程序中能够稳当执行。一套程序库只有在具备通透性的情况下，使用起来才会轻易。 5． 当你撰写class时，试着给予明了易懂的名称，减少不必要的注解。你给客户端程序员的接口，应该保持概念上的单纯性。不了这个目的，当函数的重载（overloading）适合制作出直觉、易用的接口时，请善加使用。 6． 也必你的分析和设计必须让系统中的classes保持最少，须让其Public interfaces保持最少，以及让这些classes和其他classes之间的关联性（ 尤其是base classes）保持最少。假如你的设计所得结果更甚于此，请问问自己，是否其中每一样东西在整个程序生命期中都饶富价值？假如并非如此，那么，维护它们会使你付出代价。开发团队的成员都有不维护"无益于生产力提升"的任何东西的倾向；这是许多设计方法无法解释的现象。 7． 让所有东西尽量自动化。先撰写测试用的程序代码（在你撰写class之前），并让它和class结合在一起。请使用makefile或类似工具，自动进行测试动作。通过这种方式，只要执行测试程序，所有的程序变动就可以自动获得验证，而且可以立即发现错误。由于你知道的测试架构所具备的安全性，所以当你发现新的需求时，你会更勇于进行全面修改。请记住，程序语言最大的改进，是来自型别检查、异常处理等机制所赋予的内置测试动作。但这些功能只能协助你到达某种程度。开发一个稳固系统时，你得自己验证自己的classes或程序的性质。 8． 在你撰写class之前先写测试码，以便验证你的class 是否设计完备。假如你无法撰写测试码，你便无法知道你的class 的可能长相。撰写测试码通常能够显现出额外的特性（features）或限制 ( constraints)__它们并不一定总是能够在分析和设计过程中出现。测试码也可做为展示class 用法的示例程序。 9． 所有软件设计上的问题，都可以通过"引入额外的概念性间接层（conceptual indirection）"加以简化。这个软件工程上的基础法则是抽象化概念的根据，而抽象化概念正是面向对象程序设计的主要性质。 10． 间接层(indirection)应该要有意义（和准则-9致）。这里所指的意义可以像"将共用程序代码置于惟一函数"这么简单。假如你加入的间接层（或抽象化、或封装等等）不具意义，它可能就和没有适当的间接层一样糟糕。 11． 让class尽可能微小而无法切割（atomic）。赋予每个class单一而清楚的用途。假如你的classes或你的系统成长得过于复杂，请将复杂的classes切割成比较简单的几个classes。最明显的一个判定指针就是class的大小：假如它很大，那么它工作量过多的机会就可能很高，那就应该被切割。重新设计class的建议线索是： 1） 复杂的switch语句：请考虑运用多态（Polymorphism）。 2） 许多函数各自处理类型极为不同的动作：请考虑切割为多个不同的（classes）。 12． 小心冗长的引数列（argument lists）。冗长的引数列会使函数的调用动作不易撰写、阅读、维护。你应该试着将函数搬移到更适当的class中，并尽量以对象为引数。 13． 不要一再重复。假如某段程序代码不断出现于许多derived class函数中，请将该段程序代码置于某个base class 函数内，然后在derived class函数中调用。这么做不仅可以省下程序代码空间，也可以让修改该段程序代码动作更易于进行。有时候找出此种共通程序代码还可以为接口增加实用功能。 14． 小心switch语句或成串的if-else 子句。通常这种情况代表所谓的"type-check coding"。也就是说究竟会执行哪一段程序代码，乃是依据某种型别信息来做抉择（最初，确切型别可能不十分明显）。你通常可以使用继续和多态来取代此类程序代码；Polymorphical method （多态函数）的调用会自动执行此类型别检验，并提供更可靠更轻易的扩充性。 15． 从设计观点来看，请找出变动的事物，并使它和不变的事物分离。