【开源中国 APP 全新上线】“动弹” 回归、集成大模型对话、畅读技术报告”
有必要每个service都继承一个接口么
业务开发没有必要,平台的话最好用接口。
看需求,若是service都需要实现某个功能,需要继承,若需要约束这个service只有是某个接口的实现时才调用,也需要继承
接口的优点非常多, 但一接口对一类感觉确实有点多此一举, 不过细想之下也是有它的用途的. 现在aop运用极多, 而aop的底层实现有两种:
所以, 选择使用aop就一定程度上会选择接口. 而且, 在接口下, 你按接口调用就行, 接口不变调用就不受影响; 若没接口, 直接依赖怎么办? 还有, 以后的维护, 升级, 扩展和重写呢?
目前只是因为你的业务简单,所以不实现也可以……如果业务复杂的,一个接口有多个实现的,使用接口还是很方便的
主要是为了aop才使用接口的
个人的看法:
如果只是项目本身内部调用的,没有必要接口,因为除了显得啰嗦外,还有一点,现在一个项目功能都是单一的(微服务),所以都是一个人负责一个,自己写自己的东西,接口意思不大
但是如果是有DUBBO性质的接口,那就需要用接口了。
当然,接口在实际上还是很有用的,一般公司工具架构包提供给各个开发,一般都会用到接口
业务开发没有必要,平台的话最好用接口。
看需求,若是service都需要实现某个功能,需要继承,若需要约束这个service只有是某个接口的实现时才调用,也需要继承
接口的优点非常多, 但一接口对一类感觉确实有点多此一举, 不过细想之下也是有它的用途的.
现在aop运用极多, 而aop的底层实现有两种:
所以, 选择使用aop就一定程度上会选择接口.
而且, 在接口下, 你按接口调用就行, 接口不变调用就不受影响; 若没接口, 直接依赖怎么办?
还有, 以后的维护, 升级, 扩展和重写呢?
目前只是因为你的业务简单,所以不实现也可以……如果业务复杂的,一个接口有多个实现的,使用接口还是很方便的
主要是为了aop才使用接口的
个人的看法:
如果只是项目本身内部调用的,没有必要接口,因为除了显得啰嗦外,还有一点,现在一个项目功能都是单一的(微服务),所以都是一个人负责一个,自己写自己的东西,接口意思不大
但是如果是有DUBBO性质的接口,那就需要用接口了。
当然,接口在实际上还是很有用的,一般公司工具架构包提供给各个开发,一般都会用到接口