我同意,针对接口的编程是一种很好的做法.在大多数情况下,Java"接口"在这个意义上意味着语言构造接口,因此您可以编写接口和实现类,并且在大多数情况下使用接口而不是实现类.
我想知道这是否也是编写域模型的好习惯.因此,例如,如果您有一个域类Customer,并且每个客户可能都有一个Orders列表,您通常也会编写接口ICustomer和IOrder.客户也会有一份IOrders而不是Orders的列表吗?或者你会在域模型中使用接口,只有它真的是由域驱动的,例如你至少有两种不同类型的订单?换句话说,您是否会因为域模型中的技术需求而使用接口,或者仅在与实际域相关时才使用接口?
编写接口"只是因为"让我感到浪费时间和精力,更不用说违反了KISS原则.
当它们实际用于表示相关类的常见行为时,我会编写它们,而不仅仅是一个花哨的头文件.
不要过度设计你的系统.如果你发现你有几种类型的订单,并认为为Orders声明一个接口是合适的,而不是在需要时重构它.对于域模型,特定接口在开发生命周期中会发生很大变化的概率很高,因此很早就编写接口很有用.
接口是隔离组件的绝佳方式,用于单元测试和一般依赖关系管理.说,我经常更喜欢抽象类,所以至少有一些常见的行为被卸载,而不是强迫接口带来的一些重复.现代IDE可以快速轻松地生成界面,因此它们没有那么多工作:-)
不,我只使用域对象上的接口来保持松散耦合.对我来说,使用接口开发自己的代码的主要方面是我可以在进行单元测试时轻松创建模拟.我没有看到模仿域对象的重点,因为它们没有服务层或DAO层类所具有的相同依赖性.
这当然不意味着偏离在域对象中使用接口.适当时使用.例如,最近我一直在开发一个webapp,其中不同类型的域对象对应于用户可以留下评论的永久链接页面.因此,每个域对象现在都实现了"可注释"接口.然后将所有基于注释的代码编程到Commentable接口而不是Domain Objects.