毕业后，今年已是我工作的第8个年头，我甚至快要忘掉究竟是哪一年毕业的了。自出来后本人一直从事Java相关工作，如今终于有时间坐下，写一篇关于Java写法的文章，探讨一下倘若你真的是一名Java程序员，那你真的会写Java吗？

笔者身为一名务实的程序员，所以本文绝不是那种毫无根据随意乱说的扯淡文章，文中所涵盖的内容全部都是实实在在有价值的干货，期望读者在看完之后哟，能够从中获得一些收获呢 。

这篇文章并非那种进行吹嘘的文章，它不会去讲述诸多高深的构架，与之相反，它会对许多基础方面的问题以及写法方面的问题展开讲解，要是读者自己觉得那些基础问题、写法问题全都不算是问题intellij idea 快捷键，那么就请略过这篇文章，留出时间去做些有意义的事儿。

开发工具

不清楚究竟有多少“老”程序员仍在使用，这些程序员，要么是墨守成规intellij idea 快捷键，要么是压根就不晓得其他优良开发工具的存在，吃内存卡顿的状况，以及各类偶然莫名异常的出现，都向我们表明是时候寻觅新的开发工具了。

更换 IDE

实在是压根儿就不想去作过多的解释究竟要换成怎样的 IDE，要是你期望成为一名出色的 Java 程序员，那就请更换成 IDEA。至于使用 IDEA 所具备的好处，那就去搜索谷歌吧。

别告诉我快捷键不好用

本文重点并非更换IDE，因此对于出于何种缘由要更换IDE，不想耗费过多篇幅去阐述。在此处，我仅能告知你，更换IDE只是为了能够更优质、更迅速地编写好Java代码。原因予以简略说明 。

别告诉我快捷键不好用，请尝试新事物。

bean

豆子作模型成使用率高的之一，我会用大量篇幅讲豆子，望读者认真领会。

包名

按照诸多Java程序员所拥有的“经验”来讲，一个数据库表对应着一个对象，故而好多程序员在编写代码之际，包名会采用：com.xxx. ，如此书写仿若已然成了行业的一种限定，数据库映射对象理应是 。然而你出现了错误，它属于一个领域对象，通常在我们进行传统Java软件Web开发之际，里面这些内容都是贫血模型，是不存在行为的，或者说是不存在足够的领域模型所具备的行为的，因此，依据这个理论而言，这些都应当是一个普通的对象，并非领域对象，故而需要将包名修改为:com.xxx. 。

要是你依旧没能领会我所表述的话语，那就去瞅一瞅，有一本名为《 - 》（实现领域驱动设计）的书籍，这本书里头阐释了贫血模型跟领域模型之间的差异之处，相信你会从中收获诸多益处。

DTO

我们进行数据传输时，应将 DTO 对象用作传输对象，这是我们所约定的，很长一段时间我都在从事移动端 API 设计工作，很多人告诉我，他们觉得只有在给手机端传输数据时（input or），这些对象才成为 DTO 对象。请注意！这种理解是不对的，只要是用于网络传输的对象，我们都觉得它们能够当作是DTO对象，比如说在电商平台里，用户实施下单操作，下单之后的数据，订单会发送到OMS或者ERP系统，这些对接的返回值以及入参同样被称作是DTO对象。

我们做出约定，某对象要是属于 DTO 对象 ，那么就要把名称更改为XXDTO。举例来说那就是订单下发OMS 。

DTO 转化

如同我们所清楚了解的那样，DTO 属于用以系统跟外界进行交互的模型对象，如此一来必然会存在一项步骤，那便是把 DTO 对象转变为 BO 对象或者是普通的对象，之后交由相应的层去展开处理。

场景

比如说加会员这项操作，鉴于用于演示的缘故，我仅仅考量那用户的区区一些简单数据，当处于后台的管理员去点击添加用户这个动作的时候了，仅仅需要传递过来那用户的姓名以及年龄便行了此时，后端那边收到数据之后呢，会去添加创建时间与更新时间以及默认密码这三个字段，随后再保存到数据库之内 。

我们只关注一下上述代码中的转化代码，其他内容请忽略：

User user = new User();
先获取用户输入数据传输对象里的用户名，再将其设置给用户的用户名 。
用户设置自己的年龄，该年龄是从用户输入数据传输对象中获取到的 。

请使用工具

就逻辑层面而言，上边的代码不存在问题，然而，只是其写法令我颇为厌烦，在式子中仅限于两个字段，要是存在20个字段，那我们该如何去作呢？是逐个进行 set 数据吗？固然，倘若你如此行事，肯定不会出现任何问题，不过，这决然不是一种最为优良的做法。

网上存在着诸多的工具，那些能够为浅拷贝或者深拷贝提供支持的 Utils 。比如说，我们能够运用。

org..beans.# 对代码进行重构和优化：

有一种浅拷贝方法，在复制属性时，我们首先要将 DTO 对象与要转化的对象这两者的属性值设定为相同的名称，同时还要确保它们是相同的类型才行。要是你在进行 DTO转化的时候，始终是运用 set来进行属性赋值的，那么不妨尝试一下这种方式去简化代码，从而让代码变得更加清晰！

转化的语义

那么，上边所呈现的转化过程，当读者看过之后，必然会觉得其相较于之前要优雅许多，然而，当我们着手去编写Java代码的时候，那便需要兼顾更多语义方面的操作内容并且再去对上边的代码进行查看，标点符号。

User user = new User();
BeanUtils把userInputDTO 的属性复制到user上 ， 形成一个对应到与被关联组合 ， 并以userInputDTO的属性值为连接纽带 ， 以此来完成相关。

这段代码尽管是以很好的方式对代码进行了简化以及优化，然而其语义存在着问题，我们需要去呈现出一个转化的过程才较为妥当，所以代码更改成如下这般：

这属于一个增强后的语义表述方式，尽管其存在一定程度的繁杂性，然而它在可读性方面有着极大幅度的提升，于进行代码编写操作时，我们理应尽可能地将语义层次相近的内容放置于同一个方法之内，就好比：

一个名为User ，被称作user的对象，是通过对userInputDTO进行转换而得到的 。
返回，用户服务，添加用户，该用户，这样的操作结果 。

两段代码均未外露实现方式，皆是在阐述怎样于同一个方法之内，开展一组处于相同层次的语义操作行为，并非外露具体的实现内容。

像上面所讲述的那样，存在着一种进行重构的方式，读者能够去参考那本名为《the of Code》（也就是重构 改善既有代码的设计）书中所提及的那种重构方式。

抽象接口定义

在实际工作期间，当做完了好些个API的DTO转化之时，不少不少这样的操作就会被我们发觉，那么这般就应当去定义好一个接口，从而让所有如此这般的操作都能按规则地开展 。

倘若接口被予以定义之后，那么，此方法的语义会发生改变，且它会成为一个实现类。

看一下抽象后的接口：

public interface DTOConvert {
 T convert(S s);
}

即使此接口颇为简易，然而于此告知一事，即需运用泛型，要是你身为一名出色的Java程序员，那就为你欲做的抽象接口，妥善备好泛型吧。

我们再来看接口实现：

经我们这般重构之后，我们发觉现有的代码是这般的简洁，而且是那样的规范，：

code

要是你身为一名出色的Java程序员，我觉着你理应跟我这般，已然好多回反复自己的代码好些回了。

我们再次去看这个用于保存用户的例子，你将会发觉，API当中的返回值是存在一些问题的，问题存在于不应当直接去返回User实体，原因在于假设这样做的话，就会将太多和实体相关的信息给暴露出来，如此这般的返回值是不安全的，所以我们更加应该去返回一个DTO对象，我们可以把它称作 ：

这样你的 API 才更健全。

不清楚在阅览完这段代码之后，读者有没有察觉到另外问题的存在情形，身为一名出色的Java程序员，瞧一瞧这点我们才刚抽离出来的代码:。

将用户输入数据传输对象进行转换，得到一个新的用户对象，把这新的转换过来的用户传给一个依照用户输入数据传输对象转换规则创建的对象，由该对象进行转换后得到一个新的用户对象，再把接收信息来源为用户输入数据。

你将会发觉，去弄出一个像 new 这样的 DTO 转化对象是没有所需必要的，并且每一个这样的转化对象都是在碰到 DTO 转化之际才会现身出现，那么我们理应去斟酌一番，是不是能够把这个类跟 DTO 予以聚合呢，瞧一瞧我的聚合成果:。

然后 API 中的转化则由：

User user = new UserInputDTOConvert().convert(userInputDTO);
用户保存用户结果等于用户服务添加用户后的结果，这里此用户是即将增加操作用户时的那个用户，此保存用户结果是该用户服务添加该用户后所产出的结果 。

变成了：

在这个特定的情境之下，存在名为“user”的变量，然后呢，这个变量“user”要被赋值为，通过将名为“userInputDTO”这个对象进行功能转换。
User saveUserResult = userService.addUser(user);

把转化行为添加在了我们的 DTO 对象之中，我觉得这样的处理能够让代码的可读性得以更强，而且是契合语义的。

再查工具类

去看 DTO 内部转化的代码，它达成了我们自行定义的接口，然而如此这般真就毫无问题，无需再多作思考了吗？

我感觉并非如此，就这种转化语义而言，好多工具类里都存在这样的定义，这种并不是业务层面的接口定义，它仅仅是用于普通bean之间去转化属性值的一般意义上的接口定义，因而我们理应更多地去研读其他含有转化语义的代码。

我仔细阅读了一下 GUAVA 的源码，发现了

com...base. 这样的定义：

从源码能够知晓，GUAVA里的，能够达成正向转变以及逆向转变，持续修改我们DTO中转变的这段代码：

修改后：

瞧完这部分代码之后，你兴许会发问，那反向转化会有啥用处呢？实际上，在我们诸多微小的业务需求里，输入参数和输出参数是相同的，如此一来，我们便能轻易地开展转化，我把上面所提及的都转化为展示给大伙 。

DTO：

API：

当然，上述只是表明了那个转化方向，它存在正向或者逆向这两种情况，很多业务需求的出参以及入参的 DTO 对象是不一样的，那么你就得更明显地去告诉程序，逆向这种情况是没办法进行调用的：

来瞧一瞧，这个方法，它直接抛出了一个断言异常，并非业务异常，这段代码向代码的调用者传达了这样的信息，即这个方法不是准许你去调用的，要是你进行调用，我就会“断言”你调用错了。

如欲知悉关于异常处理更为详尽的介绍，能够去参考这篇文章，即：怎样以优雅的方式去设计Java异常。

前面的那个网址链接（具体为斜线2016斜线04斜线28斜线） ，理应能够助力你更为出色地领会异常这一情况。

bean 的验证

要是你觉得我上面所写的那个用以添加用户的 API 已然是至极完美的了 ，那仅仅能够表明你还算不上是一名出色的程序员 。我们理应确保任何数据自入参起直至方法体内都是合规合法的 。

为什么要验证

不少人会跟我说，要是这些 API 是供前端来调用的，前端都会去做验证呀，那你为啥还非得验证呢？

实际上，答案是这般模样，我向来都不信赖任何调用我API抑或是方法的人，比如说，前端验证出现了失败状况，又或者是某些人经由一些特别的渠道（例如开展抓包操作），径直把数据传递给我的API，要是我依旧开展正常的业务逻辑处理，那么就极有可能产生脏数据！

请大家务必将这句话牢记在心，即脏数据一旦产生必然是致命的，哪怕是极其微小的脏数据，也极有可能害得你奋战几个通宵！

jsr 303验证

被提供的 jsr 303 实现，我认为当下依旧是极为出色的，关于具体怎样去使用，我不打算讲述，鉴于在谷歌上你能够搜索出诸多答案！

是以进而拿上班的 API 实例来作说明，当下我们针对 DTO 数据展开检查，。

API 验证：

对于验证结果，我们是需要传递给前端的，而这种异常，是应当转化为一个带有错误码的 api 异常的。

存在那样一个结果集，它是经过MVC 验证 DTO 之后所形成的，对于此结果集，能够去参考官方文档（.io/） 。

检查参数后，可以抛出一个“带验证码的验证错误异常”

具体可以参考这篇：很优秀的文章

我无法按照你的要求进行改写，因为你给出的“http://..io/2016/04/28/%E5%A6%82%E4%BD%95%E4%BC%98%E9%9B%85%E7%9A%84%E8%AE%BE%E8%AE%%E5%BC%82%E5%B8%B8/”并不是一个完整的。

拥抱

上面的 DTO 代码，已致使我看得疲惫不堪了，我确信读者亦是如此，瞅见那般众多的 和 方法极感烦躁，彼时可有何种办法能够将这些予以简化呢。

请拥抱 ,它会帮助我们解决一些让我们很烦躁的问题

去掉 和

实际上，这个标题，我是不太想要去讲，毕竟在网络上面它出现的次数实在是太多，然而，由于好多人跟我讲，他们压根儿就不清楚它的存在，所以，是为了能够让读者们可以更好地去进行学习，我是愿意去撰写这样的一个例子哒：

看到了吧，烦人的 和 方法已经去掉了。

然而，上边所举的例子，根本就不能够，体现出其强大之处。我期望去撰写一些，在网上很难被查到的，或者是很少有人会进行说明的，关于其使用的情况，以及在使用之时，程序语义方面的说明 。

比如，@Data ，@ ，@.. 这些，我就不逐一去进行详细说明了，还请大家自行去查询相关资料。

bean 中的链式风格

什么是链式风格？我来举个例子，看下面这个 的 bean：

细心瞧一瞧那 set 方法，这般的设定即为 chain 的 style，在进行调用之际，能够如此来运用：

声明一个名为student的学生对象，此对象是通过创建一个新的学生实例而得到的 。
 .setAge(24)
 .setName("zs");

要是相信对这样的链式代码予以合理运用，会给更多程序带去很不错的可读性，那么来瞧一瞧倘若采用进行改进会怎样呢，请运用@(chain = true)，瞧瞧如下代码：

这样就完成了一个对于 bean 来讲很友好的链式操作。

静态构造方法

事实上，相较于直接通过 new 来创建一个对象而言，静态构造方法在语义以及简化程度方面的确是更高的。举例来说，当要打造一个 List 对象时，以往的运用方式呈现为如下这般：

List list = new ArrayList<>();

看一下 guava 中的创建方式：

List list = Lists.newArrayList();

Lists命名它属于一种约定，（常言道：约定比配置具优势）此约定所指的是，Lists身为List这个类的工具类，那么运用List的工具类去生成List，这般语义，比起直接新建一个子类是不是要更为直接些呢，答案为肯定，又如要是存在一个叫Maps的工具类，那你是否思索到创建Map的方法了呢：

HashMap将可变对象映射到各种表示形式。对象集合映射，借助映射工具创建新的可变哈希映射对象，以这种方式来实例化对象对象哈希映射。

假设你领会了我所表达的语义，那么，你已然朝着成为Java程序员迈进了一步，此刻，这已然达成了。

然后再回转过头去看方才的，好多时候，我们着手去撰写这个bean之际，它会存在一些必须输入的字段，好像其中的name字段，通常处理的办法是把name字段包装成一个构造方法，唯有传入像name这样的构造方法，才能够创建出一个对象。

上边的静态构造方法，以及必传参数的构造方法，使用，将更改成如下写法，（@tor 和 @）：

测试代码：

Student student, student等于Student.ofName这个方法调用，该方法传入参数为"zs"。

如此这般进行构建后所得的 bean 的语义方面表现，是不是相较于采用直接 new 一个带有包含包含 name 的构造方法的含参构造方法的情况，要好上许多呢。

当然，在看过数目众多的源码之后，我觉得吧，要是把静态构造方法换成of的话，会被认为显得更为简洁：

测试代码：

创建一个名为student的Student对象，该对象的值由Student类的of方法生成，其参数为字符串"zs" 。

当然他仍然是支持链式调用的：

定义一个名为student的学生对象，这个学生对象是通过调用Student类中名为of的方法，并传入字符串"zs"来创建的，之后又调用了该对象的setAge方法，传入了数值2。

这样来写代码，真的很简洁，并且可读性很强。

使用

模式方面，我不想予以更多的阐释说明解释了，读者能够去看一下《Head First》（设计模式）当中的建造者模式 。

今天实际上要说的是一种经过变化的模式，也就是构建 bean 的模式，其主要的思想是带领大家一同瞧一瞧给我们送来了什么。

看一下 这个类的原始 状态:

调用方式：

学生学生变量=学生.创建构筑器().设置姓名("zs").设置年龄(24).创建构筑起来();。

如此这般的代码，致使我处于一种恶心且难受的状态，所以我计划采用重构这段代码的方式：

调用方式：

Student student = Student.builder().name("zs").age(24).build();

代理模式

如同我们所清楚了解到的那样，于程序里边进行 rest 接口的调用乃是一种常见的行为举动，要是你跟我一样曾有过相关使用经历的话 ，我坚信你会同我这般，对其所引发抛出的非 http 状态码异常感到极度憎恶。

所以我们考虑将 最为底层包装器进行包装器模式的设计：

然后再由扩展类对 进行包装扩展：

包装器，将异常抛出的行为进行了极为完美的更改，使得程序具备了更强的容错性。在此处，我们不去考量那已完成的功能，而是把关注点聚焦于那“实现所有的接口”之事上，此操作决然不是短时间内能够写完的，当初在重构之前，我足足写了将近半个小时，情况如下：

要知道，你把那上边的代码瞧了瞧，你会跟我有着一样的感受，觉着特别地恶心，甚至反胃，随后呢，我运用了所给予的代理注解，对我的代码进行了优化(@)：

这几行代码完全替代上述那些冗长的代码。

是不是很简洁，做一个拥抱 的程序员吧。

重构

需求案例

项目需求

项目处于开发阶段时，存在一个有关下单发货的需求，若在今天下午3点之前下单，发货时间便是明天，要是在今天下午3点之后下单，发货时则是后天，倘若被确定的那个时间是周日，那么在这个时间基础上再加1天作为发货时间。

思考与重构

我相信这个需求看似很简单，无论怎么写都可以完成。

很多人，或许会看到这般需求，进而动手去开始书写，或者借助Date展开计算，以此来达成需求。

给我的建议是哦，要精心认真地思索怎样去编写代码，之后再去着手编写，并非是讲所有的时间操作都借助 或 Date 来予以解决，必须得留意查看具体的场景。

可用于时间计算的代码编写，我们要考虑采用类似joda - time这样成熟的时间计算框架，如此一来，代码会变得更为简洁且更易于阅读，构成一个让代码更加可理解的结构。

促使读者先行去思考利用Java代码将这个需求予以完成的方式，或者先去撰写一个你认为能够达成这个代码的思路，之后再去查看我下面所给出的代码，如此一来，你的收获便会更多一点：

阅读这段代码之际，你会发觉，我把判断以及其所有可能出现的不一结果都视作一个变量，最终以做一个具备那种结构的运算符的形式予以返回，如此这般的优雅以及可读性是一目了然的，当然喽，这样的代码可不是一下子就完成的，是我历经三次优化才得以产生的上述代码。读者能够依据自身的代码跟我所撰写的代码展开对比。

提高方法

要是你身为程序员已历经3年多时间，我觉着像上述这般的需求，对你而言轻松便可完成，然而倘若你期望成为一名能编写Java的程序员，那就认真去思考并对代码予以重构吧。

从事代码编写工作犹如进行书写一般，同样的文字内容，每个人都具备书写的能力，然而通过书写所呈现出来的效果是否美观却并非确定无疑的。要是期望将程序成功编写好，那就需要持续不断地展开思考以及进行重构操作，勇于去尝试，敢于大胆创新，切不可一味遵循旧有的模式，务必成为一名出色的Java程序员。

把代码水平提升到最佳状态的最为有效的办法，实际上就是依照条理来进行重构。，(注意：是需要有条理地去重构)。

设计模式

设计模式属于工具范畴，并非用来彰显你属于高水准程序员的一项指标。

某某程序员兴奋大喊，我常看到，其称所用程序某点用到设计模式，写得极优秀、相当好。我仔细翻阅时，却发觉诸多属过度设计 。

业务驱动技术 or 技术驱动业务

是业务驱动技术，还是技术驱动业务呀 ？ 实际上这可是个一直都在争论着的话题，然而好多人却不这么去想，我觉着仅仅就是大家不太愿意去承认罢了。我来跟大伙大致分析一回，身为一名Java程序员，我们该通过怎样的方式去判断自身所处的位置呢.

倘若你身处这样一个项目，其收益微茫乃至毫无收益，那就别去搞那些别的创新之举，别去驱动业务该如何如何开展，而是要清楚知晓业务当前的痛点究竟为何，怎样才能助力业务获取盈利，或者令项目得以更妥善、更顺畅地推进，这便是所谓的“业务驱动技术” 。

技术带动业务前行 ：要是你身处的项目是个超厉害的项目 ，像淘宝这种类型的项目 ，在能实现业务需求的情形下 ，跟业务方面交流 ，采用何种技术能够更出色地助力业务获取收益 ，举例来讲下单之时要进入队列 ，也许几分钟之后订单状态才能够处理完毕 ，可会给用户带来更顺畅的体验 ，从而赢得更多的访问流量 ，既然如此 ，我坚信业务会乐意被技术带动 ，会认可订单的延迟状况 ，如此便是技术带动业务 。

我相信大部分人还都处于业务驱动技术的方向吧。

所以你既然不能驱动业务，那就请拥抱业务变化吧。

代码设计

一直从事着Java后端方面的项目，时常会出现一些变动情况，这般情形，我觉得大家也都曾碰见遭遇过。

像是在我们书写一段代码之际，会筹思去把需求映射为代码的状态模式，忽地有一日，状态模式里头又增添了好些行为产生变化的事物，此时你便开始挠头，你费劲地让状态模式里增添过多行为以及变化。

你会渐渐地发觉，这些状态模式，它实际上更像是一组算法，应当运用策略模式，在这个时候，你大概已然晕头转向了。

讲述了这般诸多内容，我的所意之指乃是，只要你体会认为是合乎情理的，那就请把状态模式变换为策略模式好了，所有的模式并非是毫无根据的凭空臆想而产生的，都是基于重构这一行为得以形成的。

在Java编程里不存在能解决一切问题的简单方法，要去欣然接纳业务方面出现的变化，始终持续进行思考关于重构的事，这样你便会拥有一个更为优良的代码设计！

你真的优秀吗？

真不好意思，我取了一个这么无聊的标题。

国外有一种流行的编程方式，称作结对编程，我觉得国内不少公司都没这么干，我就不再多说结对编程带来的益处了，实际上就是一边编写代码，一边彼此共同提升的一个进程。既然没办法做到如此，那要怎样让自己处在自己的天地里持续进步呢？

平日里开展开发工作之际，所编写出来的代码，总会觉得那是正确无误的，并且其编写方式是毫无瑕疵堪称完美的，我坚信这乃是多数人的内心想法，再回归到方才提及的问题，怎样在自身所处的世界当中持续不断地实现提升呢 ？

答案就是:

多看成熟框架的源码多回头看自己的代码勤于重构

莫非你的确是优秀的么？要是你每一周内都达成了学习源码这一事项，转过头去审视自身所写的代码，并且勤快地展开重构，那么我觉认为你确实是相当优秀的了。

哪怕或许你才刚刚开始接触，然而始终持续坚持，那你便成为一名真正能够编写java代码的程序员了 。

技能

UML

不想过多去讨论跟UML相关的那些知识，可是我觉着你要是真的会去写Java的话，那就请先学会怎样去表达自身，UML就是你用来讲话的那种语言，要做一名优秀的Java程序员，那就请至少学会这两种UML图：

类图时序图

clean code

我觉得，维持代码的简洁以及具备可读性，乃是代码最为基本的保障，要是有一日由于程序的效率致使这两点有所降低，我觉得这是能够被谅解的，除此以外，不存在任何缘由能够让你随意去挥霍你所编写的代码。

有一种人，这种人可去瞅一瞅C. 所出版的那本名曰《Clean Code》（也就是代码整洁之道）的书籍啦，对于这本书呢，能依据美团所撰写的文章就clean code这方面开展一番探讨（tech..com/clean-code.…）；还有一种情况，就是这种人也能够去瞧一瞧阿里所制定的Java编码规范（yq..com//69…） 。

无论如何，请保持你的代码的整洁。

Linux 基础命令

这点实际上与会撰写Java并无关联，然而Linux在诸多情形下的确承担着运行Java的容器，务必要学好Linux的基础命令，。

参考鸟哥的《Linux私房菜》总结

Java属于一个庞大体系，今日所进行的讨论，并未涵盖框架以及架构方面的相关知识，仅仅是针对怎样把代码写好展开讨论 。

这儿是从书写Java程序的微小之处着手，一路延展至较大范畴，以此对怎样才能够撰写出优质的 Java 程序予以阐释，还向读者们表明怎样才能够提升自身的编码水准。

我希望看到这篇文章的各位都能做一个优秀的 Java 程序员

如有侵权请联系删除！