为什么不将java.io.OutputStream建模为接口而是抽象类?
我想,接口可以证明对单元测试很有用。
发布于 2013-01-11 00:41:24
其中一些方法已经实现。对于Interfaces,这是不可能的。
close()
void flush()
void write(byte[] b)
void write(byte[] b, int off, int len) 已经用默认实现实现了。
发布于 2013-01-11 00:41:38
javadoc给出了一个提示:
需要定义OutputStream子类的
应用程序必须始终至少提供一个写入一个字节输出的方法。
(即void write(int b) throws IOException)
如果您查看它的实际代码,就会发现这个抽象基类的默认其他write()方法使用您需要实现的唯一方法。
此外,输出流可能不会链接到实际的资源(例如ByteArrayOutputStream):因此这个类也有.close()和.flush()的默认实现,它们什么也不做,并且只需要由背后有实际资源的流覆盖。
至于测试目的,单元测试的唯一区别实际上是您需要覆盖( extends )而不是覆盖( implements ),并且不要忘记覆盖所需的方法。或者使用mocking库(例如mockito、jmock或...)。
发布于 2013-01-11 19:51:33
实际上,java.io.OutputStream (和java.io.InputStream一样)使用Decorator pattern。与问题相关,以下是来自(Head First Design Patterns第93页)的答复:
重点是,,装饰器的类型要和他们要装饰的对象的类型相同,这一点很重要。,
,。因此,这里我们使用继承来实现类型匹配,但不使用继承来获取行为。
这就是为什么在这种情况下,我们更喜欢继承(AbstracClass)而不是接口(多态)。但请注意,在大多数其他情况下,原理是相反的:“相对于继承(抽象类),更喜欢组合(接口)”。

https://stackoverflow.com/questions/14262761
复制相似问题