1 前言
在实际的学习和工作(我没工作过)中,总是避免不了把自己的代码给别人阅读以及回顾自己以前的代码,或者是对现有项目进行升级。这时候就需要有一个良好的规范来约束自己的代码,以得到更好的可维护性。
本文内容学习自:《Building Maintainable Software, Java Edition》详情见末尾参考文献
2 保持代码单元的接口简单
代码单元在第一篇中已经介绍过了,这里不再赘述,想了解的请看博主之前的文章。
接口简单是什么意思呢?代码单元的接口其实朴素地讲就是某些函数或方法的参数列表的复杂性,更直观的说,就是参数列表的长度。
想像一下:
- 当你要调用你之前写的函数的时候,突然发现…WHAT!!这些参数都是啥(尤其是当你的文档不完善,参数命名随意的时候)。
- 接口复杂有时候还代表着你的代码单元内容的复杂,会导致其他的问题。
- …很多种情况
所以你应该简化你代码单元的接口
请注意,过长的接口不是实质的问题,问题的本质在于过长的参数反映了代码内部存在的不合理设计以及改动
2.1 原则
如果要保持接口单元简单,参考文献中推荐:每个代码单元的参数要少于四个、少于四个、少于四个
2.2 将多个参数提取成对象
1 简单情况:参数之间联系紧密,容易提取
比如我们这里有一个关于电子邮件的方法:
public void buildAndSendMail(MailMan m, String firstName, \
String lastName, String division, String subject, \
MailFont font, String message1, String message2, \
String message3){
String mId = firstName.charAt(0) + "." \
+ lastName.substring(0, 7) + "@" \
+ division.substring(0, 5) + ".compa.ny";
MailMessage mMessage = formatMessage(font, message1, message2, message3);
m.send(mId, subject mMessage);
}
这个方法一共有9个参数,他负责了太多的东西,而其中几个参数组合起来正好是一个邮件的内容,那么我们就可以简单的提取出几个邮件类:
public void buildAndSendMail(MailMan m, MailAddress mAddress, MailBody mBody){
Mail mail = new Mail(mAddress, mBody);
m.sendMain(mail)
}
private class Mail{
private MailAddress address;
private MailBody body;
private Mail(MailAddress mAddress, MailBody mBody){
this.address = mAddress;
this.body = mBody;
}
}
private class MailBody{
String subject;
MailMessage message;
public MailBody(String subject, MailMessage message){
this.subject = subject;
this.message = message;
}
}
private class MailAddress{
private String mId;
private MailAddress(String firstName, String lastName, String division){
this.mId = firstName.charAt(0) + "." \
+ lastName.substring(0, 7) + "@" \
+ division.substring(0, 5) + ".compa.ny";
}
}
这里封装的用来传参的对象,称为数据传输对象(DTO)
2 复杂情况,参数之间关系不大
当各个参数之间关系不大,如果只是简单地将其抽象成一个对象,那么这个类可能就很不常用,只有这个方法会用到。这是不太好地,所以这里说另一种方法。
这个方法之前的文章也说过了,就是使用方法对象替换方法。这里就不再使用代码描述了。其具体方法就是,将过长的参数作为新类的成员属性,然后就可以通过设置默认值或者特定的方法设定其具体值来代替函数调用的传参。
最终,较少的参数可以让代码单元更容易理解和重用。
参考文献
[1] Visser J, Rigal S, Eck P V, et al. Building Maintainable Software, Java Edition: Ten Guidelines for Future-Proof Code[M]. O’Reilly Media, Inc. 2016.