请教：关于接口的设计

我做的项目有小一半需要以某种方式和LDAP交互，你从来没遇到过，你说这是不是运气问题？
如果你知道有大概40%的可能性需要考虑LDAP，你的产品或者基础架构要不要考虑同时支持两种持久化机制？我觉得这是很显而易见的。

我所接触的几个行业在可见的未来基本上不会使用LDAP.
这个是运气吗?
这个跟运气是没什么关系的.

其实我们也没必要拘泥于运气不运气.
就算后端有不同的持久层,那只要在业务逻辑层和持久层之间加入额外的数据访问层即可,数据库操作均由数据访问层完成.
btw:用什么数据库其实跟业务逻辑的实现关系不大了.
我还是坚持,单一的业务逻辑是不需要设计接口的.

假如还没有发现接口带来的好处，那大可以只使用类。
接口和实现，这个虚与实的关系可是绝大多数设计模式的关键所在啊，呵呵。
不说这些虚的。
具体来说
接口可以屏蔽具体实现对调用方的影响。
我曾经涉及一个需要计算费用的系统，计算费用是作为一个接口设计的。
在不同的时期，客户会要求不同收费方案。然而业务流程是没有变化的。
最终都需要从客户账户中扣除这部分费用。修改收费方案同业务流程分别
放在不同的包中，这样当收费方案变动时，业务流程不需要任何变动。

另外，使用接口，有利于并行开发，测试起来也会方便些。
在上面的例子中一个人可以负责业务流程的编码，具体如何计算费用，
是另外一个人负责。通过该接口调用方不需要引用实现方的类，
这样他们就可以同时开发业务的不同方面。
如果调用方需要测试自己的程序，他就可以做一个实现该接口的简单测试类先用。

接口的这些分离效果，使程序能够更加灵活和清晰。

对于公有的业务逻辑,比如生成/删除/更新可以做成通用的接口然后由各个具体的业务逻辑类实现这些接口.但对于某个业务特殊的逻辑,做成接口似乎没有必要,直接由一个具体的逻辑实现类,因为业务逻辑变化的话必然会改变逻辑实现代码,但可以不变类方法的情况下更新业务逻辑,而不是重新生成新的实现类.

呵呵，我倒觉得这样的接口没有用。或者我没懂你的含义？



能否举个比较实际的例子？

呵呵，我倒觉得这样的接口没有用。或者我没懂你的含义？
-->
应该说是服务(Service)接口.
比如业务系统每个模块均有的提交/审核/审批等操作就可以做成接口,然后由每个模块的实际实现类实现接口.
能否举个比较实际的例子？
-->
比如审核的业务逻辑,假定以前的业务逻辑是修改表单的审核状态,同时更新A,B表的数据.现时只需要更新A表的数据.那么只需要直接在原方法上修改即可,而无需新增另外的逻辑实现类.

是啊，接口的一个重要的作用就是屏蔽实现的差异。在你说的情况下，我认为即使
没有多个模块需要的情况也需要做成接口。这样客户端就不需要依赖于具体的接口
实现了。


这是需求变更或实现变更的问题，不涉及是否需要接口的问题。

这是需求变更或实现变更的问题，不涉及是否需要接口的问题。
-->可以这么说,但每个子模块都增加接口只会增加复杂性和许多没用的接口存在.
如我先前所说,很多业务逻辑是不具备'多态'的.

能讲讲怎么理解好接口、抽象类、实体类、静态工具类的设计目的及作用吗？
很有兴趣。