业务接口方法有业务含义,根业务紧耦合,需求变化(不一定是真的变了,可能是理解的问题)业务接口该变就要变,没什么说的。还有,不要尝试定义通用性(可扩展)业务接口,得不偿失。
业务接口只描述业务功能,不描述业务流程。业务流程中业务用业务接口来描述。具体开发实现的时候是用class还是interface,不能一概而论了,但我倾向于在原型设计的时候定出interface和流程的实现,每一个interface有一个最简单的实现类,保证流程能够跑得通,再由开发人员具体业务实现就相对清楚的。在并行开发的时候其他人“不需要”关心业务具体实现,做到“某种程度”的透明,如果团队比较大,就很必要了。
说到变更情况
首先,重构基本不大可能修改业务接口,因为重构只是代码结构、层次的调整,不是功能调整,所以可以说重构是业务接口无关的。
说到需求变更会不会修改业务接口,这是有可能的。什么情况下会修改业务接口呢?
第一种情况:业务接口方法映射的业务功能含义发生改变(这里不涉及业务具体实现),业务接口局部方法作出调整;
第二种情况:业务流程发生变化,整个业务接口都有可能费掉。
看这两种情况,都需要花大量的时间去重新确认需求、业务流程、业务功能要求,至于采用修改接口、还是实现类这种问题的工作量跟这些事情的工作量比起来几乎可以忽略不计。
业务接口的意义是在业务流程中给出一个需要做什么的业务约定,而不是具体怎么做。
业务接口只描述业务功能,不描述业务流程。业务流程中业务用业务接口来描述。具体开发实现的时候是用class还是interface,不能一概而论了,但我倾向于在原型设计的时候定出interface和流程的实现,每一个interface有一个最简单的实现类,保证流程能够跑得通,再由开发人员具体业务实现就相对清楚的。在并行开发的时候其他人“不需要”关心业务具体实现,做到“某种程度”的透明,如果团队比较大,就很必要了。
说到变更情况
首先,重构基本不大可能修改业务接口,因为重构只是代码结构、层次的调整,不是功能调整,所以可以说重构是业务接口无关的。
说到需求变更会不会修改业务接口,这是有可能的。什么情况下会修改业务接口呢?
第一种情况:业务接口方法映射的业务功能含义发生改变(这里不涉及业务具体实现),业务接口局部方法作出调整;
第二种情况:业务流程发生变化,整个业务接口都有可能费掉。
看这两种情况,都需要花大量的时间去重新确认需求、业务流程、业务功能要求,至于采用修改接口、还是实现类这种问题的工作量跟这些事情的工作量比起来几乎可以忽略不计。
业务接口的意义是在业务流程中给出一个需要做什么的业务约定,而不是具体怎么做。