但是又有几个能讲清面向接口编程的好处和优点
大家来讨论下
237 个解决方案
#1
==
我先抢个沙发
我先抢个沙发
#2
面向接口的编程正是java的优点，首先 用起来方便，结构清晰
在j2ee中的接口也就是类，类与类之间的通信因为接口而变的简单易懂
在j2ee中的接口也就是类，类与类之间的通信因为接口而变的简单易懂
#3
=。=！
#4
那我弄个地板
#5
我觉得代码复用稍微差一点
#6
呵呵，像J2EE中的API规范基本上都是接口，由各应用服务器来实现，比如：WebSphere按照这个接口实现自己的，WebLogic也按照这个接口实现自己的，作为开发者来说我们根本就不用去管谁是怎样实现的，只要按照J2EE的API
来写就可以了，根本用不着导入它们的实现包，实际上具体的是由它们自身完成了。
接口说白了，也就是定死了一个框，具体的是糊红纸还是糊黑纸我们都用不着去管的，我们只要知道它是个框，提供
了哪些方法就够了。
举个简单的JDBC的例子吧，比如有个BaseDao接口，现在有MySQLDao实现了一个（我们可以把具体的实现类配在配置
文件中，再通过反射进行实例化），也就类似这样的：
BaseDao dao = (BaseDao)(Class.forName(Config.getDaoName()).newInstance());
其中Config.getDaoName()可以获得配置文件中的配置，比如是：com.bao.dao.impl.MySQLDao。
之后，那些人开始要烧钱了，要改用Oracle了，这样我们只要按BaseDao的定义，再实现一个OracleDao就可以了，
再将配置文件中的配置改为：com.bao.dao.impl.OralceDao就可以了，而在已经写好的代码中，我们可以一行不
改的进行了数据库移植，这个就是面向对象设计原则中的“开-闭原则”（对增加是开放的，对修改是封闭的）。但
这只是理论上的，现实中很难做到的。
来写就可以了，根本用不着导入它们的实现包，实际上具体的是由它们自身完成了。
接口说白了，也就是定死了一个框，具体的是糊红纸还是糊黑纸我们都用不着去管的，我们只要知道它是个框，提供
了哪些方法就够了。
举个简单的JDBC的例子吧，比如有个BaseDao接口，现在有MySQLDao实现了一个（我们可以把具体的实现类配在配置
文件中，再通过反射进行实例化），也就类似这样的：
BaseDao dao = (BaseDao)(Class.forName(Config.getDaoName()).newInstance());
其中Config.getDaoName()可以获得配置文件中的配置，比如是：com.bao.dao.impl.MySQLDao。
之后，那些人开始要烧钱了，要改用Oracle了，这样我们只要按BaseDao的定义，再实现一个OracleDao就可以了，
再将配置文件中的配置改为：com.bao.dao.impl.OralceDao就可以了，而在已经写好的代码中，我们可以一行不
改的进行了数据库移植，这个就是面向对象设计原则中的“开-闭原则”（对增加是开放的，对修改是封闭的）。但
这只是理论上的，现实中很难做到的。
#7
接口 = 电脑的USB插口!
因为接口订好了，所以那面到底插的是什么就不重要了！
我们用户只需要
1 插上去
2 停用移动设备
3 拔下来
这三个就好似USB的接口功能。他隐藏了实际功能，但提供给用户统一的操作界面和使用方式
因为接口订好了，所以那面到底插的是什么就不重要了！
我们用户只需要
1 插上去
2 停用移动设备
3 拔下来
这三个就好似USB的接口功能。他隐藏了实际功能，但提供给用户统一的操作界面和使用方式
#8
继续关注~
#9
写小的应用程序看不到接口的优势，写大点的程序马上就显示出接口的优势，越大越明显．所以还是从现在开始养成面向接口编程的习惯．写多了程序就会觉得优势显而易见．
#10
-_________-!链条组装起来了,然后向上面挂东西.....挂的东西可以随时拿下来,可以随时替换掉,可以随时安上去.......
#11
子类只能继承一个父类
却可以继承多个接口..功能区分清晰，改起来方便
够了吧
多给点
却可以继承多个接口..功能区分清晰，改起来方便
够了吧
多给点
#12
优点：
接口和实现分离了，适于团队的协作开发。
更具体的优点：可以参看IDP原则。
缺点：
设计难了，在你没有写实现的时候，就得想好接口，接口一变，全部乱套，这就是所谓的设计比实现难。
接口和实现分离了，适于团队的协作开发。
更具体的优点：可以参看IDP原则。
缺点：
设计难了，在你没有写实现的时候，就得想好接口，接口一变，全部乱套，这就是所谓的设计比实现难。
#13
主要为了实现松散耦合的系统，便于以后升级，扩展．你去研究一下spring吧，那东东会让你真正体会到interface的优点．
#14
接口，主要是为了 弥补 JAVA 丢失的 多继承性 的特点吧 。。。就象11楼说的那样！
#15
封装好，好使用
#16
恰恰不是11楼所说的。。。
#17
http://topic.csdn.net/u/20071229/20/50c600d9-8369-4c75-a53b-73249696082b.html
我都预备好了。。。
我都预备好了。。。
#18
易扩展
#19
下班了 明天继续讨论
#20
容易让人把编写程序和现实联系起来。呵呵
#21
接口在项目中用的比较多的原因是，当你调用别人的接口时可以不用部署，直接引用就行了。
#22
呵呵...
#23
mark下，慢慢体会大家说的。
#24
我记得我曾经在一篇帖子中提到过，一个接口可以从三方面去考察：
制定者（或者叫协调者）， 实现者（或者叫生产者）， 调用者（或者叫消费者）。
接口本质上就是 由制定者来协调实现者和调用者之间的关系。
所以通常说的“面向接口编程”可以理解为：
只有实现者和调用者都遵循“面向接口编程”这个准则，制定者的协调目的才能达到。
一个老生常谈的例子就是JDBC。
很多人费解：既然我每连接一种数据库（如mysql）都要事先部署驱动程序，那我直接访问驱动程序不就行了？还要JDBC干吗？
实际上，JDBC已经起了至关重要的作用了：正因为驱动程序是按照JDBC所规定的方法编写的，你才可以按照JDBC的方式去使用。
换句话说，如果驱动程序提供者不按照JDBC标准来编写，而是按它自己独创的方式编写，那么你在使用驱动程序的时候就要花时间查看驱动程序的文档以搞清楚用法。而当你日后决定使用另一种数据库的时候，这种数据库的驱动程序也不是按照JDBC编写的，你又得去搞清楚另一套完全不同的用法，而你的所有代码都必须做相应的更改。这种代价是不可想象的。
而现在的情况是，驱动程序提供者都按照JDBC规定的方式来编写，程序员都按照JDBC规定的方式来使用。程序员不用关心自己正在使用何种数据库，而驱动程序编写者也不用费尽心力去编写接口文档来向程序员解释驱动程序的用法，大家都向标准看齐就行了。
现在，你觉得面向接口编程的好处还不明显吗？
当你正在你的键盘上打字的时候，你是否想到，你在学校就学会了的打字方法至今还在用，因为所有计算机键盘的布局都是一样的。
这时，你会不会由衷地感激这个设计键盘布局的人呢？正是他让你只要学会一种打字方法就可以用在所有计算机的键盘上。
制定者（或者叫协调者）， 实现者（或者叫生产者）， 调用者（或者叫消费者）。
接口本质上就是 由制定者来协调实现者和调用者之间的关系。
所以通常说的“面向接口编程”可以理解为：
只有实现者和调用者都遵循“面向接口编程”这个准则，制定者的协调目的才能达到。
一个老生常谈的例子就是JDBC。
很多人费解：既然我每连接一种数据库（如mysql）都要事先部署驱动程序，那我直接访问驱动程序不就行了？还要JDBC干吗？
实际上，JDBC已经起了至关重要的作用了：正因为驱动程序是按照JDBC所规定的方法编写的，你才可以按照JDBC的方式去使用。
换句话说，如果驱动程序提供者不按照JDBC标准来编写，而是按它自己独创的方式编写，那么你在使用驱动程序的时候就要花时间查看驱动程序的文档以搞清楚用法。而当你日后决定使用另一种数据库的时候，这种数据库的驱动程序也不是按照JDBC编写的，你又得去搞清楚另一套完全不同的用法，而你的所有代码都必须做相应的更改。这种代价是不可想象的。
而现在的情况是，驱动程序提供者都按照JDBC规定的方式来编写，程序员都按照JDBC规定的方式来使用。程序员不用关心自己正在使用何种数据库，而驱动程序编写者也不用费尽心力去编写接口文档来向程序员解释驱动程序的用法，大家都向标准看齐就行了。
现在，你觉得面向接口编程的好处还不明显吗？
当你正在你的键盘上打字的时候，你是否想到，你在学校就学会了的打字方法至今还在用，因为所有计算机键盘的布局都是一样的。
这时，你会不会由衷地感激这个设计键盘布局的人呢？正是他让你只要学会一种打字方法就可以用在所有计算机的键盘上。
#25
便于
扩展和
协作
#26
up
#27
凡事上升到概念的程度就不是我们应该干的事情了~~~
说出个一二三四点也不代表就理解了。倒不如拿出一个场景出来，让大家讲讲如何合理的运用到面向接口
说出个一二三四点也不代表就理解了。倒不如拿出一个场景出来，让大家讲讲如何合理的运用到面向接口
#28
加班中，估计今天得把太阳等出来
#29
interface 定义规范
class 编码实现
优点：1。便于程序规范化设计
2。便与团队协同开发
3。便于转换为com组件、activex组件等
4。方便的代码复用，无需了解技术细节。
缺点：1。接口协同工作时，设计不良会出现难以发现的bug,因为你只遵循接口规范，不知道实现的技术细节。
class 编码实现
优点：1。便于程序规范化设计
2。便与团队协同开发
3。便于转换为com组件、activex组件等
4。方便的代码复用，无需了解技术细节。
缺点：1。接口协同工作时，设计不良会出现难以发现的bug,因为你只遵循接口规范，不知道实现的技术细节。
#30
接口就是规划标准，有了标准去遵守就好扩展。
#31
接口 抽象 很容易被松偶合这个词汇忽悠，实际上就是定制一套方法，所有实现由各自去完成。
好比定义一套产品数据管理（增、删、改、查）的抽象方法，或者接口声明这些方法，那么在Oracle或SQLServer的实现上只要遵循这个规划，那么上层只需要面向接口编程不用改动代码，而数据层可以轻松切换到Oracle或者是SQLServer。也就是所谓的开闭原则。
好比定义一套产品数据管理（增、删、改、查）的抽象方法，或者接口声明这些方法，那么在Oracle或SQLServer的实现上只要遵循这个规划，那么上层只需要面向接口编程不用改动代码，而数据层可以轻松切换到Oracle或者是SQLServer。也就是所谓的开闭原则。
#32
优点：对外只公开接口，层与层之间通过接口通信，怎么做到了设计模式和框架模式的原则
#33
比如说，你要注册一个用户，前面是业务逻辑，要调用数据访问层的save(user)方法。先写一个数据访问对象的接口
jdbc的实现是
你的业务层UserService只要这么写
public interface IDAO{
void save(User user) throws UserNameExistException;
}
jdbc的实现是
public class JDBCDAO implements IDAO{
public void save(User user) throws UserNameExistException{
.....
String sql = "insert into t_user values(?,?,?,?)";
....
PreparedStatement pstm = conn.prepareStatement(sql);
pstm.setString(1,user.getName());
....
pstm.executeUpdate();
......
}
}Hibernate的实现是
public class HibernateDAO implements IDAO{
public void save(User user) throws UserNameExistException{
......
session.save(user);
session.getTransaction().commit();
....
}
}
你的业务层UserService只要这么写
public class UserService{
public void register(String userName,String password,int age,....等等参数){
//假设现在用的是JDBC的实现
IDAO dao = new JDBCDAO();//当你需要替换实现的时候，只要把这个JDBCDAO换成HibernateDAO就可以了，其它代码不需要改。
User user = new User();
user.setName(userName);
......
dao.save(user);
}
}
#34
上面是在QQ里和一位朋友讲工厂模式之前对接口作用的解释，现在看了看，异常应该在Service里抛，不该写在DAO里。不过只是为了描述接口的作用的话，那样写也没什么关系吧。
#35
面向接口主要是传统行业学习，比如建筑业，建筑业最重要的是图纸，那就是接口。开发软件的图纸就是设计师设计的接口。over。
#36
“这个就是面向对象设计原则中的“开-闭原则”（对增加是开放的，对修改是封闭的）。但
这只是理论上的，现实中很难做到的”
这只是理论上的，现实中很难做到的”
#37
学习～
#38
可以使代码的重用化，可定制性，修改性，抽象性加强，
在整个软件的代码组织上有比较重要的作用
在整个软件的代码组织上有比较重要的作用
#39
我是楼主 谢谢大家对此贴的关注
能不能举些项目中具体的例子 不要举有关JDBC和DAO层设计的 现在这个的好处我已经明白了
能不能举些项目中具体的例子 不要举有关JDBC和DAO层设计的 现在这个的好处我已经明白了
#40
学到了好多，共勉~
#41
我现在用gwt开发ajax
用到很多接口， 异步asynchronous调用
用到很多接口， 异步asynchronous调用
#42
作gwt分客户端程序，服务器端程序，
#43
举一反三呗，接口不就是解耦用的嘛
#44
接口主要是弥补JAVA的不支持多继承性，如果让一个类去继承另一个类、并且实现一个接口的话，
这不就达到了多继承的效果吗？
这不就达到了多继承的效果吗？
#45
再说一句，六楼真的说得好，感谢！！！（虽然我不是楼主！）
#46
继续关注
#47
同意 30 楼
#48
真正用了就理解了
#49
应该是在DAO层里抛出异常吧,再由业务逻辑层进行处理.因为底层抛出的异常一般不好处理……
#50
该回复于2015-05-26 13:05:52被管理员删除
#1
==
我先抢个沙发
我先抢个沙发
#2
面向接口的编程正是java的优点，首先 用起来方便，结构清晰
在j2ee中的接口也就是类，类与类之间的通信因为接口而变的简单易懂
在j2ee中的接口也就是类，类与类之间的通信因为接口而变的简单易懂
#3
=。=！
#4
那我弄个地板
#5
我觉得代码复用稍微差一点
#6
呵呵，像J2EE中的API规范基本上都是接口，由各应用服务器来实现，比如：WebSphere按照这个接口实现自己的，WebLogic也按照这个接口实现自己的，作为开发者来说我们根本就不用去管谁是怎样实现的，只要按照J2EE的API
来写就可以了，根本用不着导入它们的实现包，实际上具体的是由它们自身完成了。
接口说白了，也就是定死了一个框，具体的是糊红纸还是糊黑纸我们都用不着去管的，我们只要知道它是个框，提供
了哪些方法就够了。
举个简单的JDBC的例子吧，比如有个BaseDao接口，现在有MySQLDao实现了一个（我们可以把具体的实现类配在配置
文件中，再通过反射进行实例化），也就类似这样的：
BaseDao dao = (BaseDao)(Class.forName(Config.getDaoName()).newInstance());
其中Config.getDaoName()可以获得配置文件中的配置，比如是：com.bao.dao.impl.MySQLDao。
之后，那些人开始要烧钱了，要改用Oracle了，这样我们只要按BaseDao的定义，再实现一个OracleDao就可以了，
再将配置文件中的配置改为：com.bao.dao.impl.OralceDao就可以了，而在已经写好的代码中，我们可以一行不
改的进行了数据库移植，这个就是面向对象设计原则中的“开-闭原则”（对增加是开放的，对修改是封闭的）。但
这只是理论上的，现实中很难做到的。
来写就可以了，根本用不着导入它们的实现包，实际上具体的是由它们自身完成了。
接口说白了，也就是定死了一个框，具体的是糊红纸还是糊黑纸我们都用不着去管的，我们只要知道它是个框，提供
了哪些方法就够了。
举个简单的JDBC的例子吧，比如有个BaseDao接口，现在有MySQLDao实现了一个（我们可以把具体的实现类配在配置
文件中，再通过反射进行实例化），也就类似这样的：
BaseDao dao = (BaseDao)(Class.forName(Config.getDaoName()).newInstance());
其中Config.getDaoName()可以获得配置文件中的配置，比如是：com.bao.dao.impl.MySQLDao。
之后，那些人开始要烧钱了，要改用Oracle了，这样我们只要按BaseDao的定义，再实现一个OracleDao就可以了，
再将配置文件中的配置改为：com.bao.dao.impl.OralceDao就可以了，而在已经写好的代码中，我们可以一行不
改的进行了数据库移植，这个就是面向对象设计原则中的“开-闭原则”（对增加是开放的，对修改是封闭的）。但
这只是理论上的，现实中很难做到的。
#7
接口 = 电脑的USB插口!
因为接口订好了，所以那面到底插的是什么就不重要了！
我们用户只需要
1 插上去
2 停用移动设备
3 拔下来
这三个就好似USB的接口功能。他隐藏了实际功能，但提供给用户统一的操作界面和使用方式
因为接口订好了，所以那面到底插的是什么就不重要了！
我们用户只需要
1 插上去
2 停用移动设备
3 拔下来
这三个就好似USB的接口功能。他隐藏了实际功能，但提供给用户统一的操作界面和使用方式
#8
继续关注~
#9
写小的应用程序看不到接口的优势，写大点的程序马上就显示出接口的优势，越大越明显．所以还是从现在开始养成面向接口编程的习惯．写多了程序就会觉得优势显而易见．
#10
-_________-!链条组装起来了,然后向上面挂东西.....挂的东西可以随时拿下来,可以随时替换掉,可以随时安上去.......
#11
子类只能继承一个父类
却可以继承多个接口..功能区分清晰，改起来方便
够了吧
多给点
却可以继承多个接口..功能区分清晰，改起来方便
够了吧
多给点
#12
优点：
接口和实现分离了，适于团队的协作开发。
更具体的优点：可以参看IDP原则。
缺点：
设计难了，在你没有写实现的时候，就得想好接口，接口一变，全部乱套，这就是所谓的设计比实现难。
接口和实现分离了，适于团队的协作开发。
更具体的优点：可以参看IDP原则。
缺点：
设计难了，在你没有写实现的时候，就得想好接口，接口一变，全部乱套，这就是所谓的设计比实现难。
#13
主要为了实现松散耦合的系统，便于以后升级，扩展．你去研究一下spring吧，那东东会让你真正体会到interface的优点．
#14
接口，主要是为了 弥补 JAVA 丢失的 多继承性 的特点吧 。。。就象11楼说的那样！
#15
封装好，好使用
#16
恰恰不是11楼所说的。。。
#17
http://topic.csdn.net/u/20071229/20/50c600d9-8369-4c75-a53b-73249696082b.html
我都预备好了。。。
我都预备好了。。。
#18
易扩展
#19
下班了 明天继续讨论
#20
容易让人把编写程序和现实联系起来。呵呵
#21
接口在项目中用的比较多的原因是，当你调用别人的接口时可以不用部署，直接引用就行了。
#22
呵呵...
#23
mark下，慢慢体会大家说的。
#24
我记得我曾经在一篇帖子中提到过，一个接口可以从三方面去考察：
制定者（或者叫协调者）， 实现者（或者叫生产者）， 调用者（或者叫消费者）。
接口本质上就是 由制定者来协调实现者和调用者之间的关系。
所以通常说的“面向接口编程”可以理解为：
只有实现者和调用者都遵循“面向接口编程”这个准则，制定者的协调目的才能达到。
一个老生常谈的例子就是JDBC。
很多人费解：既然我每连接一种数据库（如mysql）都要事先部署驱动程序，那我直接访问驱动程序不就行了？还要JDBC干吗？
实际上，JDBC已经起了至关重要的作用了：正因为驱动程序是按照JDBC所规定的方法编写的，你才可以按照JDBC的方式去使用。
换句话说，如果驱动程序提供者不按照JDBC标准来编写，而是按它自己独创的方式编写，那么你在使用驱动程序的时候就要花时间查看驱动程序的文档以搞清楚用法。而当你日后决定使用另一种数据库的时候，这种数据库的驱动程序也不是按照JDBC编写的，你又得去搞清楚另一套完全不同的用法，而你的所有代码都必须做相应的更改。这种代价是不可想象的。
而现在的情况是，驱动程序提供者都按照JDBC规定的方式来编写，程序员都按照JDBC规定的方式来使用。程序员不用关心自己正在使用何种数据库，而驱动程序编写者也不用费尽心力去编写接口文档来向程序员解释驱动程序的用法，大家都向标准看齐就行了。
现在，你觉得面向接口编程的好处还不明显吗？
当你正在你的键盘上打字的时候，你是否想到，你在学校就学会了的打字方法至今还在用，因为所有计算机键盘的布局都是一样的。
这时，你会不会由衷地感激这个设计键盘布局的人呢？正是他让你只要学会一种打字方法就可以用在所有计算机的键盘上。
制定者（或者叫协调者）， 实现者（或者叫生产者）， 调用者（或者叫消费者）。
接口本质上就是 由制定者来协调实现者和调用者之间的关系。
所以通常说的“面向接口编程”可以理解为：
只有实现者和调用者都遵循“面向接口编程”这个准则，制定者的协调目的才能达到。
一个老生常谈的例子就是JDBC。
很多人费解：既然我每连接一种数据库（如mysql）都要事先部署驱动程序，那我直接访问驱动程序不就行了？还要JDBC干吗？
实际上，JDBC已经起了至关重要的作用了：正因为驱动程序是按照JDBC所规定的方法编写的，你才可以按照JDBC的方式去使用。
换句话说，如果驱动程序提供者不按照JDBC标准来编写，而是按它自己独创的方式编写，那么你在使用驱动程序的时候就要花时间查看驱动程序的文档以搞清楚用法。而当你日后决定使用另一种数据库的时候，这种数据库的驱动程序也不是按照JDBC编写的，你又得去搞清楚另一套完全不同的用法，而你的所有代码都必须做相应的更改。这种代价是不可想象的。
而现在的情况是，驱动程序提供者都按照JDBC规定的方式来编写，程序员都按照JDBC规定的方式来使用。程序员不用关心自己正在使用何种数据库，而驱动程序编写者也不用费尽心力去编写接口文档来向程序员解释驱动程序的用法，大家都向标准看齐就行了。
现在，你觉得面向接口编程的好处还不明显吗？
当你正在你的键盘上打字的时候，你是否想到，你在学校就学会了的打字方法至今还在用，因为所有计算机键盘的布局都是一样的。
这时，你会不会由衷地感激这个设计键盘布局的人呢？正是他让你只要学会一种打字方法就可以用在所有计算机的键盘上。
#25
便于
扩展和
协作
#26
up
#27
凡事上升到概念的程度就不是我们应该干的事情了~~~
说出个一二三四点也不代表就理解了。倒不如拿出一个场景出来，让大家讲讲如何合理的运用到面向接口
说出个一二三四点也不代表就理解了。倒不如拿出一个场景出来，让大家讲讲如何合理的运用到面向接口
#28
加班中，估计今天得把太阳等出来
#29
interface 定义规范
class 编码实现
优点：1。便于程序规范化设计
2。便与团队协同开发
3。便于转换为com组件、activex组件等
4。方便的代码复用，无需了解技术细节。
缺点：1。接口协同工作时，设计不良会出现难以发现的bug,因为你只遵循接口规范，不知道实现的技术细节。
class 编码实现
优点：1。便于程序规范化设计
2。便与团队协同开发
3。便于转换为com组件、activex组件等
4。方便的代码复用，无需了解技术细节。
缺点：1。接口协同工作时，设计不良会出现难以发现的bug,因为你只遵循接口规范，不知道实现的技术细节。
#30
接口就是规划标准，有了标准去遵守就好扩展。
#31
接口 抽象 很容易被松偶合这个词汇忽悠，实际上就是定制一套方法，所有实现由各自去完成。
好比定义一套产品数据管理（增、删、改、查）的抽象方法，或者接口声明这些方法，那么在Oracle或SQLServer的实现上只要遵循这个规划，那么上层只需要面向接口编程不用改动代码，而数据层可以轻松切换到Oracle或者是SQLServer。也就是所谓的开闭原则。
好比定义一套产品数据管理（增、删、改、查）的抽象方法，或者接口声明这些方法，那么在Oracle或SQLServer的实现上只要遵循这个规划，那么上层只需要面向接口编程不用改动代码，而数据层可以轻松切换到Oracle或者是SQLServer。也就是所谓的开闭原则。
#32
优点：对外只公开接口，层与层之间通过接口通信，怎么做到了设计模式和框架模式的原则
#33
比如说，你要注册一个用户，前面是业务逻辑，要调用数据访问层的save(user)方法。先写一个数据访问对象的接口
jdbc的实现是
你的业务层UserService只要这么写
public interface IDAO{
void save(User user) throws UserNameExistException;
}
jdbc的实现是
public class JDBCDAO implements IDAO{
public void save(User user) throws UserNameExistException{
.....
String sql = "insert into t_user values(?,?,?,?)";
....
PreparedStatement pstm = conn.prepareStatement(sql);
pstm.setString(1,user.getName());
....
pstm.executeUpdate();
......
}
}Hibernate的实现是
public class HibernateDAO implements IDAO{
public void save(User user) throws UserNameExistException{
......
session.save(user);
session.getTransaction().commit();
....
}
}
你的业务层UserService只要这么写
public class UserService{
public void register(String userName,String password,int age,....等等参数){
//假设现在用的是JDBC的实现
IDAO dao = new JDBCDAO();//当你需要替换实现的时候，只要把这个JDBCDAO换成HibernateDAO就可以了，其它代码不需要改。
User user = new User();
user.setName(userName);
......
dao.save(user);
}
}
#34
上面是在QQ里和一位朋友讲工厂模式之前对接口作用的解释，现在看了看，异常应该在Service里抛，不该写在DAO里。不过只是为了描述接口的作用的话，那样写也没什么关系吧。
#35
面向接口主要是传统行业学习，比如建筑业，建筑业最重要的是图纸，那就是接口。开发软件的图纸就是设计师设计的接口。over。
#36
“这个就是面向对象设计原则中的“开-闭原则”（对增加是开放的，对修改是封闭的）。但
这只是理论上的，现实中很难做到的”
这只是理论上的，现实中很难做到的”
#37
学习～
#38
可以使代码的重用化，可定制性，修改性，抽象性加强，
在整个软件的代码组织上有比较重要的作用
在整个软件的代码组织上有比较重要的作用
#39
我是楼主 谢谢大家对此贴的关注
能不能举些项目中具体的例子 不要举有关JDBC和DAO层设计的 现在这个的好处我已经明白了
能不能举些项目中具体的例子 不要举有关JDBC和DAO层设计的 现在这个的好处我已经明白了
#40
学到了好多，共勉~
#41
我现在用gwt开发ajax
用到很多接口， 异步asynchronous调用
用到很多接口， 异步asynchronous调用
#42
作gwt分客户端程序，服务器端程序，
#43
举一反三呗，接口不就是解耦用的嘛
#44
接口主要是弥补JAVA的不支持多继承性，如果让一个类去继承另一个类、并且实现一个接口的话，
这不就达到了多继承的效果吗？
这不就达到了多继承的效果吗？
#45
再说一句，六楼真的说得好，感谢！！！（虽然我不是楼主！）
#46
继续关注
#47
同意 30 楼
#48
真正用了就理解了
#49
应该是在DAO层里抛出异常吧,再由业务逻辑层进行处理.因为底层抛出的异常一般不好处理……
#50
该回复于2015-05-26 13:05:52被管理员删除