本文曾经收录到 Github 仓库，该仓库蕴含 计算机根底、Java 外围知识点、多线程、JVM、常见框架、分布式、微服务、设计模式、架构 等外围知识点，欢送 star~
Github 地址：https://github.com/Tyson0314/…
Gitee 地址：https://gitee.com/tysondai/Ja…
软件工程师和码农最大的区别就是平时写代码时习惯问题，码农很喜爱写反复代码而软件工程师会利用各种技巧去干掉反复的冗余代码。
业务同学埋怨业务开发没有技术含量，用不到 设计模式、Java 高级个性、OOP，平时写代码都在堆 CRUD，个人成长无从谈起。
其实，我认为不是这样的。设计模式、OOP 是前辈们在大型项目中积攒下来的教训，通过这些方法论来改善大型项目的可维护性。反射、注解、泛型等高级个性在框架中大量应用的起因是，框架往往须要以同一套算法来应答不同的数据结构，而这些个性能够帮忙缩小反复代码，晋升我的项目可维护性。
在我看来，可维护性是大型项目成熟度的一个重要指标，而晋升可维护性十分重要的一个伎俩就是缩小代码反复。那为什么这样说呢？
- 如果多处反复代码实现完全相同的性能，很容易批改一处遗记批改另一处，造成 Bug
- 有一些代码并不是齐全反复，而是类似度很高，批改这些相似的代码容易改（复制粘贴）错，把本来有区别的中央改为了一样。
明天，我就从业务代码中最常见的三个需要开展，聊聊如何应用 Java 中的一些高级个性、设计模式，以及一些工具打消反复代码，能力既优雅又高端。通过明天的学习，也心愿扭转你对业务代码没有技术含量的认识。
1. 利用工厂模式 + 模板办法模式，打消 if…else 和反复代码
假如要开发一个购物车下单的性能，针对不同用户进行不同解决：
- 普通用户须要收取运费，运费是商品价格的 10%，无商品折扣；
- VIP 用户同样须要收取商品价格 10% 的快递费，但购买两件以上雷同商品时，第三件开始享受肯定折扣；
- 外部用户能够免运费，无商品折扣。
咱们的指标是实现三种类型的购物车业务逻辑，把入参 Map 对象（Key 是商品 ID，Value 是商品数量），转换为出参购物车类型 Cart。
先实现针对普通用户的购物车解决逻辑：
// 购物车
@Data
public class Cart {
// 商品清单
private List<Item> items = new ArrayList<>();
// 总优惠
private BigDecimal totalDiscount;
// 商品总价
private BigDecimal totalItemPrice;
// 总运费
private BigDecimal totalDeliveryPrice;
// 应酬总价
private BigDecimal payPrice;
}
// 购物车中的商品
@Data
public class Item {
// 商品 ID
private long id;
// 商品数量
private int quantity;
// 商品单价
private BigDecimal price;
// 商品优惠
private BigDecimal couponPrice;
// 商品运费
private BigDecimal deliveryPrice;
}
// 普通用户购物车解决
public class NormalUserCart {public Cart process(long userId, Map<Long, Integer> items) {Cart cart = new Cart();
// 把 Map 的购物车转换为 Item 列表
List<Item> itemList = new ArrayList<>();
items.entrySet().stream().forEach(entry -> {Item item = new Item();
item.setId(entry.getKey());
item.setPrice(Db.getItemPrice(entry.getKey()));
item.setQuantity(entry.getValue());
itemList.add(item);
});
cart.setItems(itemList);
// 解决运费和商品优惠
itemList.stream().forEach(item -> {
// 运费为商品总价的 10%
item.setDeliveryPrice(item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())).multiply(new BigDecimal("0.1")));
// 无优惠
item.setCouponPrice(BigDecimal.ZERO);
});
// 计算商品总价
cart.setTotalItemPrice(cart.getItems().stream().map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))).reduce(BigDecimal.ZERO, BigDecimal::add));
// 计算运费总价
cart.setTotalDeliveryPrice(cart.getItems().stream().map(Item::getDeliveryPrice).reduce(BigDecimal.ZERO, BigDecimal::add));
// 计算总优惠
cart.setTotalDiscount(cart.getItems().stream().map(Item::getCouponPrice).reduce(BigDecimal.ZERO, BigDecimal::add));
// 应酬总价 = 商品总价 + 运费总价 - 总优惠
cart.setPayPrice(cart.getTotalItemPrice().add(cart.getTotalDeliveryPrice()).subtract(cart.getTotalDiscount()));
return cart;
}
}而后实现针对 VIP 用户的购物车逻辑。与普通用户购物车逻辑的不同在于，VIP 用户能享受同类商品多买的折扣。所以，这部分代码只须要额定解决多买折扣局部：
public class VipUserCart {public Cart process(long userId, Map<Long, Integer> items) {
...
itemList.stream().forEach(item -> {
// 运费为商品总价的 10%
item.setDeliveryPrice(item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())).multiply(new BigDecimal("0.1")));
// 购买两件以上雷同商品，第三件开始享受肯定折扣
if (item.getQuantity() > 2) {item.setCouponPrice(item.getPrice()
.multiply(BigDecimal.valueOf(100 - Db.getUserCouponPercent(userId)).divide(new BigDecimal("100")))
.multiply(BigDecimal.valueOf(item.getQuantity() - 2)));
} else {item.setCouponPrice(BigDecimal.ZERO);
}
});
...
return cart;
}
}最初是免运费、无折扣的外部用户，同样只是解决商品折扣和运费时的逻辑差别：
public class InternalUserCart {public Cart process(long userId, Map<Long, Integer> items) {
...
itemList.stream().forEach(item -> {
// 免运费
item.setDeliveryPrice(BigDecimal.ZERO);
// 无优惠
item.setCouponPrice(BigDecimal.ZERO);
});
...
return cart;
}
}比照一下代码量能够发现，三种购物车 70% 的代码是反复的。起因很简略，尽管不同类型用户计算运费和优惠的形式不同，但整个购物车的初始化、统计总价、总运费、总优惠和领取价格的逻辑都是一样的。
正如咱们开始时提到的，代码反复自身不可怕，可怕的是漏改或改错。比方，写 VIP 用户购物车的同学发现商品总价计算有 Bug，不应该是把所有 Item 的 price 加在一起，而是应该把所有 Item 的 price*quantity 加在一起。
这时，他可能会只批改 VIP 用户购物车的代码，而疏忽了普通用户、外部用户的购物车中，反复的逻辑实现也有雷同的 Bug。
有了三个购物车后，咱们就须要依据不同的用户类型应用不同的购物车了。如下代码所示，应用三个 if 实现不同类型用户调用不同购物车的 process 办法：
@GetMapping("wrong")
public Cart wrong(@RequestParam("userId") int userId) {
// 依据用户 ID 取得用户类型
String userCategory = Db.getUserCategory(userId);
// 普通用户解决逻辑
if (userCategory.equals("Normal")) {NormalUserCart normalUserCart = new NormalUserCart();
return normalUserCart.process(userId, items);
}
//VIP 用户解决逻辑
if (userCategory.equals("Vip")) {VipUserCart vipUserCart = new VipUserCart();
return vipUserCart.process(userId, items);
}
// 外部用户解决逻辑
if (userCategory.equals("Internal")) {InternalUserCart internalUserCart = new InternalUserCart();
return internalUserCart.process(userId, items);
}
return null;
}电商的营销玩法是多样的，当前势必还会有更多用户类型，须要更多的购物车。咱们就只能一直减少更多的购物车类，一遍一遍地写反复的购物车逻辑、写更多的 if 逻辑吗？
当然不是，雷同的代码应该只在一处呈现！
如果咱们熟记抽象类和形象办法的定义的话，这时或者就会想到，是否能够把反复的逻辑定义在抽象类中，三个购物车只有别离实现不同的那份逻辑呢？
其实，这个模式就是 模板办法模式。咱们在父类中实现了购物车解决的流程模板，而后把须要非凡解决的中央留空白也就是留形象办法定义，让子类去实现其中的逻辑。因为父类的逻辑不残缺无奈独自工作，因而须要定义为抽象类。
如下代码所示，AbstractCart 抽象类实现了购物车通用的逻辑，额定定义了两个形象办法让子类去实现。其中，processCouponPrice 办法用于计算商品折扣，processDeliveryPrice 办法用于计算运费。
public abstract class AbstractCart {
// 解决购物车的大量反复逻辑在父类实现
public Cart process(long userId, Map<Long, Integer> items) {Cart cart = new Cart();
List<Item> itemList = new ArrayList<>();
items.entrySet().stream().forEach(entry -> {Item item = new Item();
item.setId(entry.getKey());
item.setPrice(Db.getItemPrice(entry.getKey()));
item.setQuantity(entry.getValue());
itemList.add(item);
});
cart.setItems(itemList);
// 让子类解决每一个商品的优惠
itemList.stream().forEach(item -> {processCouponPrice(userId, item);
processDeliveryPrice(userId, item);
});
// 计算商品总价
cart.setTotalItemPrice(cart.getItems().stream().map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))).reduce(BigDecimal.ZERO, BigDecimal::add));
// 计算总运费
cart.setTotalDeliveryPrice(cart.getItems().stream().map(Item::getDeliveryPrice).reduce(BigDecimal.ZERO, BigDecimal::add));
// 计算总折扣
cart.setTotalDiscount(cart.getItems().stream().map(Item::getCouponPrice).reduce(BigDecimal.ZERO, BigDecimal::add));
// 计算应酬价格
cart.setPayPrice(cart.getTotalItemPrice().add(cart.getTotalDeliveryPrice()).subtract(cart.getTotalDiscount()));
return cart;
}
// 解决商品优惠的逻辑留给子类实现
protected abstract void processCouponPrice(long userId, Item item);
// 解决配送费的逻辑留给子类实现
protected abstract void processDeliveryPrice(long userId, Item item);
}有了这个抽象类，三个子类的实现就非常简单了。普通用户的购物车 NormalUserCart，实现的是 0 优惠和 10% 运费的逻辑：
@Service(value = "NormalUserCart")
public class NormalUserCart extends AbstractCart {
@Override
protected void processCouponPrice(long userId, Item item) {item.setCouponPrice(BigDecimal.ZERO);
}
@Override
protected void processDeliveryPrice(long userId, Item item) {item.setDeliveryPrice(item.getPrice()
.multiply(BigDecimal.valueOf(item.getQuantity()))
.multiply(new BigDecimal("0.1")));
}
}VIP 用户的购物车 VipUserCart，间接继承了 NormalUserCart，只须要批改多买优惠策略：
@Service(value = "VipUserCart")
public class VipUserCart extends NormalUserCart {
@Override
protected void processCouponPrice(long userId, Item item) {if (item.getQuantity() > 2) {item.setCouponPrice(item.getPrice()
.multiply(BigDecimal.valueOf(100 - Db.getUserCouponPercent(userId)).divide(new BigDecimal("100")))
.multiply(BigDecimal.valueOf(item.getQuantity() - 2)));
} else {item.setCouponPrice(BigDecimal.ZERO);
}
}
}外部用户购物车 InternalUserCart 是最简略的，间接设置 0 运费和 0 折扣即可：
@Service(value = "InternalUserCart")
public class InternalUserCart extends AbstractCart {
@Override
protected void processCouponPrice(long userId, Item item) {item.setCouponPrice(BigDecimal.ZERO);
}
@Override
protected void processDeliveryPrice(long userId, Item item) {item.setDeliveryPrice(BigDecimal.ZERO);
}
}抽象类和三个子类的实现关系图，如下所示：
是不是比三个独立的购物车程序简略了很多呢？接下来，咱们再看看如何能防止三个 if 逻辑。
或者你曾经留神到了，定义三个购物车子类时，咱们在 @Service 注解中对 Bean 进行了命名。既然三个购物车都叫 XXXUserCart，那咱们就能够把用户类型字符串拼接 UserCart 形成购物车 Bean 的名称，而后利用 Spring 的 IoC 容器，通过 Bean 的名称间接获取到 AbstractCart，调用其 process 办法即可实现通用。
其实，这就是工厂模式，只不过是借助 Spring 容器实现罢了：
@GetMapping("right")
public Cart right(@RequestParam("userId") int userId) {String userCategory = Db.getUserCategory(userId);
AbstractCart cart = (AbstractCart) applicationContext.getBean(userCategory + "UserCart");
return cart.process(userId, items);
}试想，之后如果有了新的用户类型、新的用户逻辑，是不是齐全不必对代码做任何批改，只有新增一个 XXXUserCart 类继承 AbstractCart，实现非凡的优惠和运费解决逻辑就能够了？
这样一来，咱们就利用工厂模式 + 模板办法模式，不仅打消了反复代码，还防止了批改既有代码的危险 。这就是设计模式中的 开闭准则：对批改敞开，对扩大凋谢。
2. 利用注解 + 反射打消反复代码
是不是有点兴奋了，业务代码竟然也能 OOP 了。咱们再看一个三方接口的调用案例，同样也是一个一般的业务逻辑。
假如银行提供了一些 API 接口，对参数的序列化有点非凡，不应用 JSON，而是须要咱们把参数顺次拼在一起形成一个大字符串。
- 依照银行提供的 API 文档的程序，把所有参数形成定长的数据，而后拼接在一起作为整个字符串。
- 因为每一种参数都有固定长度，未达到长度时须要做填充解决：
-
- 字符串类型的参数不满长度局部须要以下划线右填充，也就是字符串内容靠左；
- 数字类型的参数不满长度局部以 0 左填充，也就是理论数字靠右；
- 货币类型的示意须要把金额向下舍入 2 位到分，以分为单位，作为数字类型同样进行左填充。
- 对所有参数做 MD5 操作作为签名（为了不便了解，Demo 中不波及加盐解决）。
比方，创立用户办法和领取办法的定义是这样的：
代码很容易实现，间接依据接口定义实现填充操作、加签名、申请调用操作即可：
public class BankService {
// 创立用户办法
public static String createUser(String name, String identity, String mobile, int age) throws IOException {StringBuilder stringBuilder = new StringBuilder();
// 字符串靠左，多余的中央填充_
stringBuilder.append(String.format("%-10s", name).replace('','_'));
// 字符串靠左，多余的中央填充_
stringBuilder.append(String.format("%-18s", identity).replace('','_'));
// 数字靠右，多余的中央用 0 填充
stringBuilder.append(String.format("%05d", age));
// 字符串靠左，多余的中央用_填充
stringBuilder.append(String.format("%-11s", mobile).replace('','_'));
// 最初加上 MD5 作为签名
stringBuilder.append(DigestUtils.md2Hex(stringBuilder.toString()));
return Request.Post("http://localhost:45678/reflection/bank/createUser")
.bodyString(stringBuilder.toString(), ContentType.APPLICATION_JSON)
.execute().returnContent().asString();}
// 领取办法
public static String pay(long userId, BigDecimal amount) throws IOException {StringBuilder stringBuilder = new StringBuilder();
// 数字靠右，多余的中央用 0 填充
stringBuilder.append(String.format("%020d", userId));
// 金额向下舍入 2 位到分，以分为单位，作为数字靠右，多余的中央用 0 填充
stringBuilder.append(String.format("%010d", amount.setScale(2, RoundingMode.DOWN).multiply(new BigDecimal("100")).longValue()));
// 最初加上 MD5 作为签名
stringBuilder.append(DigestUtils.md2Hex(stringBuilder.toString()));
return Request.Post("http://localhost:45678/reflection/bank/pay")
.bodyString(stringBuilder.toString(), ContentType.APPLICATION_JSON)
.execute().returnContent().asString();}
}能够看到，这段代码的反复粒度更细：
- 三种规范数据类型的解决逻辑有反复，稍有不慎就会呈现 Bug；
- 解决流程中字符串拼接、加签和发申请的逻辑，在所有办法反复；
- 理论办法的入参的参数类型和程序，不肯定和接口要求统一，容易出错；
- 代码层面针对每一个参数硬编码，无奈清晰地进行核查，如果参数达到几十个、上百个，出错的概率极大。
那应该如何革新这段代码呢？没错，就是要用注解和反射！
应用注解和反射这两个武器，就能够针对银行申请的所有逻辑均应用一套代码实现，不会呈现任何反复。
要实现接口逻辑和逻辑实现的剥离，首先须要以 POJO 类（只有属性没有任何业务逻辑的数据类）的形式定义所有的接口参数。比方，上面这个创立用户 API 的参数：
@Data
public class CreateUserAPI {
private String name;
private String identity;
private String mobile;
private int age;
}有了接口参数定义，咱们就能通过自定义注解为接口和所有参数减少一些元数据。如下所示，咱们定义一个接口 API 的注解 BankAPI，蕴含接口 URL 地址和接口阐明：
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Documented
@Inherited
public @interface BankAPI {String desc() default "";
String url() default "";}而后，咱们再定义一个自定义注解 @BankAPIField，用于形容接口的每一个字段标准，蕴含参数的秩序、类型和长度三个属性：
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
@Documented
@Inherited
public @interface BankAPIField {int order() default -1;
int length() default -1;
String type() default "";}接下来，注解就能够施展威力了。
如下所示，咱们定义了 CreateUserAPI 类形容创立用户接口的信息，通过为接口减少 @BankAPI 注解，来补充接口的 URL 和形容等元数据；通过为每一个字段减少 @BankAPIField 注解，来补充参数的程序、类型和长度等元数据：
@BankAPI(url = "/bank/createUser", desc = "创立用户接口")
@Data
public class CreateUserAPI extends AbstractAPI {@BankAPIField(order = 1, type = "S", length = 10)
private String name;
@BankAPIField(order = 2, type = "S", length = 18)
private String identity;
@BankAPIField(order = 4, type = "S", length = 11) // 留神这里的 order 须要依照 API 表格中的程序
private String mobile;
@BankAPIField(order = 3, type = "N", length = 5)
private int age;
}另一个 PayAPI 类也是相似的实现：
@BankAPI(url = "/bank/pay", desc = "领取接口")
@Data
public class PayAPI extends AbstractAPI {@BankAPIField(order = 1, type = "N", length = 20)
private long userId;
@BankAPIField(order = 2, type = "M", length = 10)
private BigDecimal amount;
}这 2 个类继承的 AbstractAPI 类是一个空实现，因为这个案例中的接口并没有公共数据能够形象放到基类。
通过这 2 个类，咱们能够在几秒钟内实现和 API 清单表格的核查。实践上，如果咱们的外围翻译过程（也就是把注解和接口 API 序列化为申请须要的字符串的过程）没问题，只有注解和表格统一，API 申请的翻译就不会有任何问题。
以上，咱们通过注解实现了对 API 参数的形容。接下来，咱们再看看反射如何配合注解实现动静的接口参数组装：
- 第 3 行代码中，咱们从类上取得了 BankAPI 注解，而后拿到其 URL 属性，后续进行近程调用。
- 第 6~9 行代码，应用 stream 疾速实现了获取类中所有带 BankAPIField 注解的字段，并把字段按 order 属性排序，而后设置公有字段反射可拜访。
- 第 12~38 行代码，实现了反射获取注解的值，而后依据 BankAPIField 拿到的参数类型，依照三种规范进行格式化，将所有参数的格式化逻辑集中在了这一处。
- 第 41~48 行代码，实现了参数加签和申请调用。
private static String remoteCall(AbstractAPI api) throws IOException {
// 从 BankAPI 注解获取申请地址
BankAPI bankAPI = api.getClass().getAnnotation(BankAPI.class);
bankAPI.url();
StringBuilder stringBuilder = new StringBuilder();
Arrays.stream(api.getClass().getDeclaredFields()) // 取得所有字段
.filter(field -> field.isAnnotationPresent(BankAPIField.class)) // 查找标记了注解的字段
.sorted(Comparator.comparingInt(a -> a.getAnnotation(BankAPIField.class).order())) // 依据注解中的 order 对字段排序
.peek(field -> field.setAccessible(true)) // 设置能够拜访公有字段
.forEach(field -> {
// 取得注解
BankAPIField bankAPIField = field.getAnnotation(BankAPIField.class);
Object value = "";
try {
// 反射获取字段值
value = field.get(api);
} catch (IllegalAccessException e) {e.printStackTrace();
}
// 依据字段类型以正确的填充形式格式化字符串
switch (bankAPIField.type()) {
case "S": {stringBuilder.append(String.format("%-" + bankAPIField.length() + "s", value.toString()).replace('','_'));
break;
}
case "N": {stringBuilder.append(String.format("%" + bankAPIField.length() + "s", value.toString()).replace('','0'));
break;
}
case "M": {if (!(value instanceof BigDecimal))
throw new RuntimeException(String.format("{} 的 {} 必须是 BigDecimal", api, field));
stringBuilder.append(String.format("%0" + bankAPIField.length() + "d", ((BigDecimal) value).setScale(2, RoundingMode.DOWN).multiply(new BigDecimal("100")).longValue()));
break;
}
default:
break;
}
});
// 签名逻辑
stringBuilder.append(DigestUtils.md2Hex(stringBuilder.toString()));
String param = stringBuilder.toString();
long begin = System.currentTimeMillis();
// 发申请
String result = Request.Post("http://localhost:45678/reflection" + bankAPI.url())
.bodyString(param, ContentType.APPLICATION_JSON)
.execute().returnContent().asString();
log.info("调用银行 API {} url:{} 参数:{} 耗时:{}ms", bankAPI.desc(), bankAPI.url(), param, System.currentTimeMillis() - begin);
return result;
}能够看到，所有解决参数排序、填充、加签、申请调用的外围逻辑，都汇聚在了 remoteCall 办法中。有了这个外围办法，BankService 中每一个接口的实现就非常简单了，只是参数的组装，而后调用 remoteCall 即可。
// 创立用户办法
public static String createUser(String name, String identity, String mobile, int age) throws IOException {CreateUserAPI createUserAPI = new CreateUserAPI();
createUserAPI.setName(name);
createUserAPI.setIdentity(identity);
createUserAPI.setAge(age);
createUserAPI.setMobile(mobile);
return remoteCall(createUserAPI);
}
// 领取办法
public static String pay(long userId, BigDecimal amount) throws IOException {PayAPI payAPI = new PayAPI();
payAPI.setUserId(userId);
payAPI.setAmount(amount);
return remoteCall(payAPI);
}其实，许多波及类结构性的通用解决，都能够依照这个模式来缩小反复代码。
反射给予了咱们在不通晓类构造的时候，依照固定的逻辑解决类的成员；而注解给了咱们为这些成员补充元数据的能力，使得咱们利用反射实现通用逻辑的时候，能够从内部取得更多咱们关怀的数据。
3. 利用属性拷贝工具打消反复代码
最初，咱们再来看一种业务代码中经常出现的代码逻辑，实体之间的转换复制。
对于三层架构的零碎，思考到层之间的解耦隔离以及每一层对数据的不同需要，通常每一层都会有本人的 POJO 作为数据实体。比方，数据拜访层的实体个别叫作 DataObject 或 DO，业务逻辑层的实体个别叫作 Domain，体现层的实体个别叫作 Data Transfer Object 或 DTO。
这里咱们须要留神的是，如果手动写这些实体之间的赋值代码，同样容易出错。
对于简单的业务零碎，实体有几十甚至几百个属性也很失常。就比方 ComplicatedOrderDTO 这个数据传输对象，形容的是一个订单中的几十个属性。如果咱们要把这个 DTO 转换为一个相似的 DO，复制其中大部分的字段，而后把数据入库，势必须要进行很多属性映射赋值操作。就像这样，稀稀拉拉的代码是不是曾经让你头晕了？
ComplicatedOrderDTO orderDTO = new ComplicatedOrderDTO();
ComplicatedOrderDO orderDO = new ComplicatedOrderDO();
orderDO.setAcceptDate(orderDTO.getAcceptDate());
orderDO.setAddress(orderDTO.getAddress());
orderDO.setAddressId(orderDTO.getAddressId());
orderDO.setCancelable(orderDTO.isCancelable());
orderDO.setCommentable(orderDTO.isComplainable()); // 属性谬误
orderDO.setComplainable(orderDTO.isCommentable()); // 属性谬误
orderDO.setCancelable(orderDTO.isCancelable());
orderDO.setCouponAmount(orderDTO.getCouponAmount());
orderDO.setCouponId(orderDTO.getCouponId());
orderDO.setCreateDate(orderDTO.getCreateDate());
orderDO.setDirectCancelable(orderDTO.isDirectCancelable());
orderDO.setDeliverDate(orderDTO.getDeliverDate());
orderDO.setDeliverGroup(orderDTO.getDeliverGroup());
orderDO.setDeliverGroupOrderStatus(orderDTO.getDeliverGroupOrderStatus());
orderDO.setDeliverMethod(orderDTO.getDeliverMethod());
orderDO.setDeliverPrice(orderDTO.getDeliverPrice());
orderDO.setDeliveryManId(orderDTO.getDeliveryManId());
orderDO.setDeliveryManMobile(orderDO.getDeliveryManMobile()); // 对象谬误如果不是代码中有正文，你能看出其中的诸多问题吗？
如果原始的 DTO 有 100 个字段，咱们须要复制 90 个字段到 DO 中，保留 10 个不赋值，最初应该如何校验正确性呢？数数吗？即便数出有 90 行代码，也不肯定正确，因为属性可能反复赋值。
有的时候字段命名相近，比方 complainable 和 commentable，容易搞反（第 7 和第 8 行），或者对两个指标字段反复赋值雷同的起源字段（比方第 28 行）
明明要把 DTO 的值赋值到 DO 中，却在 set 的时候从 DO 本人取值（比方第 20 行），导致赋值有效。
这段代码并不是我顺手写进去的，而是一个实在案例。有位同学就像代码中那样把经纬度赋值反了，因为落库的字段切实太多了。这个 Bug 很久都没发现，直到真正用到数据库中的经纬度做计算时，才发现始终以来都存错了。
批改办法很简略，能够应用相似 BeanUtils 这种 Mapping 工具来做 Bean 的转换，copyProperties 办法还容许咱们提供须要疏忽的属性：
ComplicatedOrderDTO orderDTO = new ComplicatedOrderDTO();
ComplicatedOrderDO orderDO = new ComplicatedOrderDO();
BeanUtils.copyProperties(orderDTO, orderDO, "id");
return orderDO;总结
第一种代码反复是，有多个并行的类实现类似的代码逻辑。咱们能够思考提取雷同逻辑在父类中实现，差别逻辑通过形象办法留给子类实现。应用相似的模板办法把雷同的流程和逻辑固定成模板，保留差别的同时尽可能防止代码反复。同时，能够应用 Spring 的 IoC 个性注入相应的子类，来防止实例化子类时的大量 if…else 代码。
第二种代码反复是，应用硬编码的形式反复实现雷同的数据处理算法。咱们能够思考把规定转换为自定义注解，作为元数据对类或对字段、办法进行形容，而后通过反射动静读取这些元数据、字段或调用办法，实现规定参数和规定定义的拆散。也就是说，把变动的局部也就是规定的参数放入注解，规定的定义对立解决。
第三种代码反复是，业务代码中常见的 DO、DTO、VO 转换时大量字段的手动赋值，遇到有上百个属性的简单类型，十分非常容易出错。我的倡议是，不要手动进行赋值，思考应用 Bean 映射工具进行。此外，还能够思考采纳单元测试对所有字段进行赋值正确性校验。