怎么样设计类或者接口，可以为以后可能有的的泛化留扩展空间？

[鸣鸣Amadues]

比如我设计个数据库接口，实现可能是MySQL，也可能是其他数据库。
但以后数据库可能更往上一层抽象成持久化层（除了数据库外，还可能有XML等各种文件的写入读取），如果考虑到这点，那应该怎么设计比较好？
由于业务经常发生变化的，你现在在做的整体可能以后被整合到另外一个更大的东西里成为一部分，谁有这方面的设计经验的？

[maradona1984]

话说mybatis/hibernate都支持你想的,mybatis是接口做代理,xml可以理解为配置,换数据库不需要改代码的,当然我干了这么多年,还没真见过换数据库的,要换也是整体重构,而不是迁移. 而且做设计不要考虑太远,及时重构才是正道,因为你无法预测未来的需求变化,只有实时重构,当然也会有人说没时间,没时间那更不需要考虑什么设计了.

[树成]

JDBC本来就是基于接口实现的，直接拿来参考就可以了...。 另外你深入学习hibernate可以建立对应的架构思想，统一的ORM接口以及数据库访问方式，然后使用方言来扩展数据库特殊行为。

[八爻老骥]

你要找出共同点，和差异点。共同点可以抽象出来作为接口，比如都连接数据库，都有CRUD操作，不同点在于每种数据库的查询语句会有不同，连接方式也有所不同。差差异化的东西让厂商去实现，共同的东西在程序中实现。对于程序员来讲，DataSource的操作是一样，只是连接字符串和客户端驱动不一样而已。其实接口除了抽象，有时就是制定标准，无论什么数据库系统，要想让Java支持你，你就得提供符合JDBC的驱动程序。