回头想想--关于接口的问题
2007-12-04 09:32
246 查看
当了个IT民工快两年了,大大小小的JAVA程序也写了许多,但都是写简单的纯体力活,也还在菜鸟堆里面混着呢。怎样才能有所提高,是一直困扰我的问题。我现在会的是什么?会使用java api,会web 设计,会调用第三方api,会使用IDE,会用各式各样的框架.......会了这些就是程序员了?就在昨天我明白了我缺失的是什么。为了写个通用类,翻查了一些资料,发现我一直以来都没能回答上一个简单的问题--接口有什么用?为什么要用接口?什么时候该使用接口?以前在大学里学到的时候,不以为然,以为学java就是学api,理论上那些晦涩难咽的东西都是鸡肋,可有可无。到现在我发现我错了,真错了,我连java都还没有入门呢!显而易见,因为我还不能回答上那几个问题。被学校的那些烂教材害惨了,完全被误导了,java真正的精髓,不,应该是面向对象编程的精髓应该是Oo设计模式,不是一个深奥的理论,是一个程序员的基本功,程序员的马步。
关于接口和继承这篇文章很有启发澄清Java
先要弄清楚什么时候接口,才能体会设计模式真正的意图所在。大多数人认为,接口的意义在于顶替多重继承。众所周知Java没有c++那样多重继承的机制,但是却能够实作多个接口。其实这样做是很牵强的,接口和继承
是完全不同的东西,接口没有能力代替多重继承,也没有这个义务。接口的作用,一言以蔽之,就是标志类的类别(type of
class)。把不同类型的类归于不同的接口,可以更好的管理他们。OO的精髓,我以为,是对对象的抽象,最能体现这一点的就是接口。为什么我们讨论设计
模式都只针对具备了抽象能力的语言(比如c++、java、c#等),就是因为设计模式所研究的,实际上就是如何合理的去抽象。(cowboy的名言是
“抽象就是抽去像的部分”,看似调侃,实乃至理)。
设计模式中最基础的是工厂模式(Factory),在我最近的一个很简单的应用中,我想尽量的让我的程序能够在多个数据库间移植,当然,这涉及很多问题,单是如何兼容不同DBMS的SQL就让人头痛。我们不妨先把问题简单化,只考虑如何连接不同的数据库。
假设我有很多个类,分别是Mysql.java、SQLServer.java、Oracle.java、DB2.java,他们分别连接不同的数
据库,统一返回一个Connection对象,并且都有一个close方法,用于关闭连接。只需要针对你的DBMS,选择不同的类,就可以用了,但是我的
用户他会使用什么数据库?我不知道,我希望的是尽量少的修改代码,就能满足他的需要。我可以抽象如下接口:
package org.bromon.test;
public interface DB
{
java.sql.Connection openDB(String url,String user,String password);
void close();
}
这个接口只定义两个方法,没有任何有实际意义的代码,具体的代码由实作这个接口的类来给出,比如Mysql.java:
Package org.bromon.test;
import java.sql.*;
public class Mysql implements DB
{
private String url=”jdbc:mysql:localhost:3306/test”;
private String user=”root”;
private String password=””;
private Connection conn;
public Connection openDB(url,user,password)
{
//连接数据库的代码
}
public void close()
{
//关闭数据库
}
}
类似的当然还有Oracle.java等等,接口DB给这些类归了个类,在应用程序中我们这样定义对象:
org.bromon.test.DB myDB;
使用myDB来操作数据库,就可以不用管实际上我所使用的是哪个类,这就是所谓的“开-闭”原则。但是问题在于接口是不能实例化的,myDB=new
DB(),这样的代码是绝对错误的,我们只能myDB=new Mysql()或者myDB=new
Oracle()。麻烦了,我还是需要指定具体实例化的是哪个类,用了接口跟没用一样。所以我们需要一个工厂:
package org.bromon.test;
public class DBFactory
{
public static DB getConn()
{
Return(new Mysql());
}
}
所以实例化的代码变成:myDB=DBFactory.getConn();
这就是23种模式中最基础的普通工厂(Factory),工厂类负责具体实例化哪个类,而其他的程序逻辑都是针对DB这个接口进行操作,这就是“针对接口
编程”。责任都被推卸给工厂类了,当然你也可以继续定义工厂接口,继续把责任上抛,这就演变成抽象工厂(Abstract Factory)。
到目前,还是要给不同的DB编写不同的DBFactory,因为new Mysql()被硬编码在里面了,如果我们打算把DB当成是操作了入口,还是没有达到我们的目的。
手工依赖注入:我们可以将所有依赖逻辑都移动到工厂类中。也就是说,我们还需要有一个工厂类来创建连接对象。
package org.bromon.test;
public class DBFactory
{
private final DB db;
public static DB getConn(){
return ConnFactory.getInstance();
}
}
public class ConnFactory{
private ConnFactory() {}
private static DB instance=new Mysql();
public static DB getInstance() {
return instance;
}
public static DB setInstance(DB db) {
instance=db;
}
}
这样做的好处就是,统一了获取连接的方式。方便进行注入(IOC如Spring和guice)
整个过程中接口不负责任何具体操作,其他的程序要连接数据库的话,只需要构造一个DB对象就OK,而不管工厂类如何变化。这就是接口的意义----抽象。
继承的概念不用多说,很好理解。为什么要继承呢?因为你想重用代码?这绝对不是理由,继承的意义也在于抽象,而不是代码重用。如果对象A有一个run()
方法,对象B也想有这个方法,所以有人就Class B extends
A。这是不经大脑的做法。如果在B中实例化一个A,调用A的Run()方法,是不是可以达到同样的目的?如下:
Class B
{
A a=new A();
a.run();
}
这就是利用类的聚合来重用代码,是委派模式的雏形,是GoF一贯倡导的做法。
Powered by ScribeFire.
关于接口和继承这篇文章很有启发澄清Java
先要弄清楚什么时候接口,才能体会设计模式真正的意图所在。大多数人认为,接口的意义在于顶替多重继承。众所周知Java没有c++那样多重继承的机制,但是却能够实作多个接口。其实这样做是很牵强的,接口和继承
是完全不同的东西,接口没有能力代替多重继承,也没有这个义务。接口的作用,一言以蔽之,就是标志类的类别(type of
class)。把不同类型的类归于不同的接口,可以更好的管理他们。OO的精髓,我以为,是对对象的抽象,最能体现这一点的就是接口。为什么我们讨论设计
模式都只针对具备了抽象能力的语言(比如c++、java、c#等),就是因为设计模式所研究的,实际上就是如何合理的去抽象。(cowboy的名言是
“抽象就是抽去像的部分”,看似调侃,实乃至理)。
设计模式中最基础的是工厂模式(Factory),在我最近的一个很简单的应用中,我想尽量的让我的程序能够在多个数据库间移植,当然,这涉及很多问题,单是如何兼容不同DBMS的SQL就让人头痛。我们不妨先把问题简单化,只考虑如何连接不同的数据库。
假设我有很多个类,分别是Mysql.java、SQLServer.java、Oracle.java、DB2.java,他们分别连接不同的数
据库,统一返回一个Connection对象,并且都有一个close方法,用于关闭连接。只需要针对你的DBMS,选择不同的类,就可以用了,但是我的
用户他会使用什么数据库?我不知道,我希望的是尽量少的修改代码,就能满足他的需要。我可以抽象如下接口:
package org.bromon.test;
public interface DB
{
java.sql.Connection openDB(String url,String user,String password);
void close();
}
这个接口只定义两个方法,没有任何有实际意义的代码,具体的代码由实作这个接口的类来给出,比如Mysql.java:
Package org.bromon.test;
import java.sql.*;
public class Mysql implements DB
{
private String url=”jdbc:mysql:localhost:3306/test”;
private String user=”root”;
private String password=””;
private Connection conn;
public Connection openDB(url,user,password)
{
//连接数据库的代码
}
public void close()
{
//关闭数据库
}
}
类似的当然还有Oracle.java等等,接口DB给这些类归了个类,在应用程序中我们这样定义对象:
org.bromon.test.DB myDB;
使用myDB来操作数据库,就可以不用管实际上我所使用的是哪个类,这就是所谓的“开-闭”原则。但是问题在于接口是不能实例化的,myDB=new
DB(),这样的代码是绝对错误的,我们只能myDB=new Mysql()或者myDB=new
Oracle()。麻烦了,我还是需要指定具体实例化的是哪个类,用了接口跟没用一样。所以我们需要一个工厂:
package org.bromon.test;
public class DBFactory
{
public static DB getConn()
{
Return(new Mysql());
}
}
所以实例化的代码变成:myDB=DBFactory.getConn();
这就是23种模式中最基础的普通工厂(Factory),工厂类负责具体实例化哪个类,而其他的程序逻辑都是针对DB这个接口进行操作,这就是“针对接口
编程”。责任都被推卸给工厂类了,当然你也可以继续定义工厂接口,继续把责任上抛,这就演变成抽象工厂(Abstract Factory)。
到目前,还是要给不同的DB编写不同的DBFactory,因为new Mysql()被硬编码在里面了,如果我们打算把DB当成是操作了入口,还是没有达到我们的目的。
手工依赖注入:我们可以将所有依赖逻辑都移动到工厂类中。也就是说,我们还需要有一个工厂类来创建连接对象。
package org.bromon.test;
public class DBFactory
{
private final DB db;
public static DB getConn(){
return ConnFactory.getInstance();
}
}
public class ConnFactory{
private ConnFactory() {}
private static DB instance=new Mysql();
public static DB getInstance() {
return instance;
}
public static DB setInstance(DB db) {
instance=db;
}
}
这样做的好处就是,统一了获取连接的方式。方便进行注入(IOC如Spring和guice)
整个过程中接口不负责任何具体操作,其他的程序要连接数据库的话,只需要构造一个DB对象就OK,而不管工厂类如何变化。这就是接口的意义----抽象。
继承的概念不用多说,很好理解。为什么要继承呢?因为你想重用代码?这绝对不是理由,继承的意义也在于抽象,而不是代码重用。如果对象A有一个run()
方法,对象B也想有这个方法,所以有人就Class B extends
A。这是不经大脑的做法。如果在B中实例化一个A,调用A的Run()方法,是不是可以达到同样的目的?如下:
Class B
{
A a=new A();
a.run();
}
这就是利用类的聚合来重用代码,是委派模式的雏形,是GoF一贯倡导的做法。
Powered by ScribeFire.
相关文章推荐
- Maven项目中,关于Spring Boot 整合MyBatis时,Service层无法找到mapper接口的问题解决
- 答网友强护灰飞烟灭关于接口的问题
- 关于OPC自动化接口编程(OPCDAAuto.dll)几点注意问题
- 关于接口的实现和继承的问题
- 关于php 接口问题(php接口主要也就是运用curl,curl函数)
- 关于http接口开发中json格式数据编码问题处理
- 关于php和C语言接口的结构传递问题,udp,tcp通信
- Remoting中,关于获取某接口派生的自定义属性(CustomAttribute)的问题
- c++关于接口机制和不完全类型的小问题
- 关于支付宝接口整合的几个问题
- EasyNVR RTSP转RTMP-HLS流媒体服务器前端构建之_关于接口调用常见的一些问题(401 Unauthorized)
- 关于接口的问题
- 接口和抽象类关于拥有private属性和方法的问题
- 关于SDK接口中的指针问题
- 关于php和C语言接口的结构传递问题,udp,tcp通信
- 关于APP接口防止抓包问题
- 关于微信 调用js-sdk接口报错的问题
- AE开发中关于 “无法嵌入互操作类型.........请改用适用的接口”问题的解决方法
- 关于接口的实现和继承的问题