我对接口编程相当新，并试图将其作为开发测试驱动的主要工具。
目前我们有很多Manager类都实现了CRUD接口。但是有些经理还没有做更新，有些不做删除，有些可能永远不会做。
未实施例外？
没关系，只是
throw new NotImplementedException()
直到该方法得到实施，或者甚至永远都没有？
（显然有一个源代码评论告诉程序员“不应该使用这种方法，例如像'男'女'那样的类型永远不会被删除）？
分割吗
或者我应该将我的CRUD界面拆分为可创建，可读（可搜索），可更新和可删除？这不会弄乱我的班级定义吗？
PersonManager implements Creatable<Person>, Updateable<Person>, Deletable<Person>, Searchable<Person>
拆分并合并？
或者我应该将像所有4这样的接口组合到CRUD中，还是将其他组合如Read + Update组合起来？
也许这也会创建一个接口加载，其中必须单击一个大的继承路径来找出哪个接口为当前情况实现所有所需的原子接口（我需要读取和创建，所以哪一个只是实现了两个？这可以快速复杂得多）
答案 0 :(得分：6)
IMO，对于中间阶段 - 可以使用NotImplementedException，直到你完成它。
然而，作为永久解决方案 - 我认为这是一种不好的做法 [在大多数情况下]。
相反，我创建了一个界面，其中包含所有实现类的通用行为，使用子接口将它们聚类以获得更具体的行为。
这个想法类似于java标准 SortedSet ，它扩展了 Set - 我们不想考虑{{1} } Set s并为此类型的变量提供值SortedSet，而我们使用子接口HashSet来实现此目的。
答案 1 :(得分：6)
通常你想抛出UnsupportedOperationException这是一个运行时异常，明确提到不支持所请求的操作。
拥有大量的接口会导致文件太多，如果有人试图查看它们，他们会感到困惑。在这种情况下，Java文档也没有多大帮助。
如果一个接口的操作太多，则拆分接口是有意义的，并且并非所有操作都在逻辑上绑定在一起。
对于数据库操作很少会出现这种情况，因为您将有一些基本操作，这对于大多数情况都是如此。
答案 2 :(得分：1)
NotImplementedException并不意味着该类不支持此操作。这意味着它没有实现，但它将来会存在。
从逻辑的角度来看，必须实现所有接口方法，并且必须正常工作。但如果你离开它，并为自己编写一个应用程序，那么你将记住这个限制。另一方面，我很生气，一些开发人员实现了接口并使其未实现。所以我认为你不能只为未来的开发留下接口方法。
我的建议是修改接口，然后在实现的方法中使用异常。
答案 3 :(得分：0)
在支持协方差和逆变的框架中，分割接口然后定义一些复合接口非常有用。对于那些不提供此类支持的框架（有时甚至是框架），有时候让接口包含单个实现可能支持或不支持的方法更有帮助（实现应该在尝试不支持的操作时抛出异常）;如果要做到这一点，应该包括方法或属性，通过这些方法或属性，外部代码可以询问支持哪些操作，而无需使用任何会引发异常的代码。
即使使用支持操作的接口是可选的，有时也可能有助于定义其他接口以保证某些操作可用。拥有继承其他接口而不添加新成员的接口可能是一种很好的方法。如果正确完成，代表实现所需的唯一额外工作是确保它们将自己声明为最适用的特定类型。客户端的情况稍微复杂一些：如果客户端的需求可以在类型系统中充分表达，客户端可以通过要求特定类型来避免运行时类型检查的需要。另一方面，在客户端之间传递实例的例程可能因某些客户端对更具体类型的需求而变得复杂，而不是实例传递代码本身所需要的。