请教：关于接口的设计

老大实现类也得写吧，是实现类的方法可以不必真的实现！

JB X 也支持重构..

现在很多都支持重构的

=================

永远支持 test first -> refactoring, 不支持 design first

robbin谈到的是骨架类吧。
在efficitive java里面有详细的介绍。
对于接口没有默认实现的问题，而导致对接口的改动会出现大规模修复的情况。
其实这个问题完全可以通过重构工具来实现＋骨架类来实现。
我也倾向于让熟悉业务的人员针对业务接口编程，具体的实现交给系统编程熟悉的人去实现。
我下个项目中，对于dao就是采取接口的方法。

如果不知道为什么必须使用一个接口，那说明还没有理解要解决的问题，那么就不要使用接口。
如果给所有的类都定义一个接口。这样的接口跟不用接口没有什么区别。可以称之为垃圾接口。结果只是必须被迫使用某种框架。否则代码量会急剧膨胀。某些人心中的面向接口就是这样的。
如果为了实现拦截的功能，把类的方法定义为虚方法就可以了。
对于一些简单的存储数据的类也定义出接口，那就很可笑了。接口不是这么贱的。要不然大家看看jdk的源代码是怎么写的。

其实我对抛开具体的业务问题来谈这些设计并不是很感兴趣
-->
双手同意.
对于mis系统来说,一个业务只有一个业务逻辑,业务需求变化后,基本上业务逻辑的类也是需要变化的,也就是说原来的业务逻辑实现类就'过期'了.这种情况下抽取接口,实现了多个业务逻辑的做法其实是不必要的,反而增加了系统的复杂性.

显然不是这样，譬如说用户信息可能在数据库，也可能在LDAP，甚至可能两种方式并存。

gigix:
显然不是这样，譬如说用户信息可能在数据库，也可能在LDAP，甚至可能两种方式并存。

呵呵,这种情况我还没有碰到过,这种需求客户也从来没有要求过:)需要自己找自己麻烦吗?

感觉业务逻辑基本上没有'多态',实现就只有一个,这时候还需要抽取接口吗?我觉得是没有必要的.

只能说你运气好，我遇到的政府机关至少有一半用了LDAP。不知道别人是不是也有你这么好的运气。

是需求问题而不是运气问题.
一直坚持:
设计前的质量是需求!
做mis系统难点不在技术,在需求.
当然,我并不是要排斥好的设计,好的需求+好的设计才会有好的软件.