详细设计到底应该怎样做

在软件开发中，很多时候都在讲规范，一般至少一个团队需要一致的规范。当然讲到规范很多人也可能想到驼峰规则、匈牙利命名法，今天我们不谈这些命名法则，遵守这些基本的法则，是做为一个程序员必备的素质。我们主要谈一些如何起名，参数列表一致性，善用注释、接口方法顺序等有趣的话题。详细设计规范了，接口实现者、接口调用者才能更好的理解接口。

起名难么？

如果你认真的为一个方法名或者一个类名思考过或者纠结过，说明我们都在为起一个好名字而努力。以下是个人就一些场景起名的一个看法。

1. 业务领域类，或者叫实体类，首先类名需要能够准确表达领域类的意图，比如我们一个领域类，School类，我们不可能拿它来表示班级。这是最简单的情况。
   • 具备共性的领域类，使用相同的结尾或者开头，比如Archive类，档案类，另外我们根据学生、班级、学校各有一个档案的领域类，这就是一个档案类的族，我们叫UserArchive、ClassArchive、SchoolArchive等。
   • 具有对应关系的领域类，使用相同的开头，比如Order类，订单类，通常订单类还需要一个订单详情类，我们叫OrderDetail类。
2. 业务接口名
   • 业务接口类，和详细设计者的抽象设计有关，不过一般业务接口类都有一个门面，门面类名字需要和具体的业务模块用例相关。比如阅卷门面接口类，我们就可以叫MarkingService。当然也有些不一定和业务用例有关，是设计者为实现某个用例，抽象出来的接口，比如以上的阅卷业务类，部分业务接口比较复杂，需要继续抽象。我们抽象出来一个阅卷任务类，我们就可以叫MarkingTask，当然MarkingTask不能被外部调用。需要通过门面接口类MarkingService对外提供服务。
   • 业务接口方法，业务接口方法和业务用例相关。比如我们有个业务用例是生成档案，我们就叫generateArchive，这个名字和业务相关。
3. 数据持久层接口名
   • 一般持久层接口设计比较轻，这个具体的接口设计原则，会在下次讲到。接口方法设计，一般几个固定开头就够用了，比如：insert,update,delete,find开头就够用。比如查询一条用户档案就叫findUserArchive。余下全文点我查看