Java开拓者必知：开拓中常见的伤害信号

　　过于伟大的软件凡是是一种常见的开拓者失调举动的功效。为了代码的乖巧而损失可读性，或是存眷于机动性及举办没须要的过早优化而造成可读性的低落经常会导致其他题目的发生。太过工程化的开拓者经常会这么做，看看可否用点什么新玩儿意，不外这对付高质量的软件来说却并没有什么甜头。一旦软件变得过于伟大而且难以领略，那么维护起来就不是那么轻易的工作了，并且经常会导致修改时呈现题目。

　　举个例子，在阅读代码时你也许想知道为什么开拓者没有采纳越发直接的方法来实现。一方面，你也许叹息于开拓者可以或许行使一些越发高级的特征，但另一方面，你也许又会认为这么做要比正常环境越发伟大了。有许多究竟可以证明这是一个伤害信号，不外我只在几个处所看到有人会这么做。一种环境是将原来用静态Java代码实现好好的浩瀚成果改用反射、Spring或是其他依靠注入、动态署理、调查者模式等方法来实现。假如用得好的话虽然没什么题目，不外我常常看到有人太过行使或是滥用这些特征，这直接导致其他开拓者很难领略代码的意图与浸染。

　　将日记动静直接输出到节制台

　　Java中的日记框架由来已久，现在已经有为数不少的日记框架(有些框架构建在此外框架之上)，这包罗传统的Log4j 1.2、Log4j 2、java.util.logging(Java Logging API)、Apache Commons Logging及SLF4J等。既然有这么多的日记框架，因此我会很稀疏为什么许多Java代码中尚有System.out与System.err语句。

　　Java代码中存在着向尺度输出与尺度错误中举办输出也许有许多缘故起因。个中一个缘故起因就是有些代码还不太成熟，后头还会修改，改成输出到日记，不外到最后也没有改。行使尺度输出与尺度错误的另一个破绽就是这些日记动静并不会被写到日记文件中，而行使日记框架的日记动静则会被写到文件中，这样就会呈现纷歧致的环境。第3个题目就是日记框架提供了不少优越的特征，假如直接写到尺度输出或是尺度错误中就无法行使这些特征了。这些特征包罗轻松节制日记动静的级别、轻松将捕捉到的非常关联到一个日记错误动静上、轻松将输出重定向到差异的方针及行使差异的名目等。固然在直接行使输出与错误流时这些都可以通过手工来实现，不外这必要本身编写代码而不是“开箱即用的”。

　　除了直接行使System.out与System.err外，有些Java代码照旧会将信息写到尺度输出与尺度错误上(凡是也是隐含行使了System.out与System.err)。好比说，Throwable.printStackTrace()(在处理赏罚非常时经常会用到)就会这么做，按照Javadoc的声名，它会将非常与仓库信息打印到尺度错误流中。

　　行使StringBuffer而非StringBuilder

　　率直地说，这只是个小题目罢了，不外却能标识出过期的Java代码(StringBuffer是JDK 1.0引入的，而StringBuilder则是J2SE 5引入的)或是开拓者并没有真正领略他们之间的区别。在大大都环境下，这两者之间的机能不同对付应用来说是微乎其微的，但因为StringBuilder更得当于大大都行使了StringBuffer的场景，因此我们照旧可以从StringBuilder得到机能上的细小晋升。 我很少发明行使StringBuffer而不能行使StringBuilder的环境。

　　要领与结构要领中行使了过多的参数

　　当要领与结构要领拥有太多的参数时，我老是担忧客户端无法正确地行使他们，出格是有些参数是沟通范例的环境。假如一个要领吸取了3个字符串和3个布尔值，那么客户端就很轻易搞混转达进去的值。编译器在这种环境下也无能为力，检测题目的独一步伐就是在运行期(通过单位测试或是其他测试)查察挪勤奋效。过多的参数表白了不起当的计划。

　　过多的显式范例转换

　　显式范例转换最有也许是个伤害信号，由于范例转换自己并不会影响到任何成果或是逻辑，不外这却表白环境与预想的纷歧致。范例转换表白了不太好的计划决定(好比说没有正确操作许多几何态、在不吻合的处所行使了担任、或是逼迫将一些本不应放在一些的对象放到了一路)。虽然了，显式范例转换在许多环境下是适当和须要的(好比说在获取Spring框架的Bean时)，不外偶然也表白计划上呈现了题目。范例转换还表白API界说的范畴过大或是API中行使的接口范畴过大。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!