接口，抽象类的使用

思想有时不太好表达。有的时候就是那种“只可以意会，不可言传”的感觉。还是就lz的代码谈, 如果我没有理解错的话，楼主的那个接口真是有点多余。其实只要一个抽象类里面再定义一个抽象方法就行了。不能为了接口而接口。代码如下:

public abstract class AbstractFileDataParser 
{  
    private FileInputStream fileInputStream = null;  
  
    public AbstractFileDataParser(FileInputStream fileInputStream)  
    {  
        if (fileInputStream == null)  
        {  
            throw new NullPointerException("file input stream is null!");  
        }  
        this.fileInputStream = fileInputStream;  
    }  
  
    protected FileInputStream getFileInputStream()  
    {  
        return this.fileInputStream;  
    }  
  
    public void release()  
    {  
        CloseUtil.close(fileInputStream);  
    }  
    
    abstract Object[] readData();  
}

然后在子类里就可以实现这个readData()方法。

如果一个类已经继承别的类！它还能继承抽象类么？这时只能使用接口，其实接口就是一个特殊的抽象类。我觉得在实际开发中，尽量少使用抽象类。不知道我说的对不对，如果不对请大家给点建议。

看了楼主的帖子，突然感觉大脑好~~~~清醒。

我感觉抽象类就是一类具有共性的对象的抽象表现，抽象类的方法表现了共同的动作与行为，而接口所描述的动作或行为，只是用了一个形象的描述名称，其具体内容要视实现它的类来决定

public class Cellphone extends Phone implements Bluetooth{  
}

这个比喻比较牛逼

看了楼上的帖子真的想说大家都是地道的程序员。

可是接口的引用并不源于编程，而是现实生活中的设计。针对编码中的接口和抽象类谁好谁坏进行争论是毫无意义的。同理也包括针对接口的使用是否有必要这样的争论。

之前楼上有人说“接口是针对外部使用者，而抽象类是针对内部”这样的观点就很精辟了。想想看为什么你家插座上的插孔都是二头三头，而内部线路的排放却千差万别就知道了。因为插座是提供给外部使用的。

面向接口的编程确实听起来很时髦，但是先想想有没有必要，是不是一定要用接口。一些规模小的公司的程序员会说，完全没必要，我们不用接口做出来的项目一样过硬，一些大公司的程序员会说，接口是必须的。

这是为什么？不是他们的项目差别有多大，而且就算不用接口也不会影响运行效率。而是因为，大公司里人员比较多，在多人共同开发一个项目的时候，他们需要设计一个或者若干个接口来作为一个标准，才不至于使项目的开发显得混乱。

也就是说接口的使用与否在代码层面完全无关紧要。

虽然这样说有人会觉得我藐视接口的作用，呵呵，经历过就会知道了。

接口一般对的事外面扩展和快速引用。关心的是事情本身的实现方法或者一个路径而已。
抽象类一般可以做两件事情，内部的松耦合；逻辑实现。关心的是具体的实现。

晕...

接口实现的是一种契约的关系,而抽象类实现的才是继承的关系.

接口对外，抽象类对内。
接口是战略层面的，抽象类是战术层面的。
抽象类的出现，只是为了省几行代码，没有它也是无所谓的。
抽象类，一般只有少数几个类使用它。而且，有可能存在几个不同的抽象类。
抽象类不能当作接口使用。
之所以会在这个问题上有疑惑，说明对创建型模式理解不正确。
仔细想想如何创建这个抽象类，想想如何屏蔽抽象类的实现细节，然后在想想出现几个抽象类的情况，想明白了就不会暴露抽象类了。
抽象类的正确用法，就是在包内部使用。应该是default访问修饰符。或者是更小的protected,不应该是public。