在布置类层次结构时,我经常发现自己对能够封装功能同时共享代码之间的差距感到沮丧。当然,部分问题是缺少多重继承,但接口有所帮助。在我看来,无法在接口上定义受保护的方法是一个更大的问题。
标准解决方案似乎是拥有一个由受保护的抽象基类实现的公共接口。问题在于我们有以下内容
public interface Foo {
public String getName();
}
abstract protected BaseFoo implements Foo {
abstract protected int getId();
private String name;
protected BaseFoo(String name) {
this.name = name;
}
@Override
public String getName() {
return this.name;
}
}
public class ConcreteFoo extends BaseFoo {
public ConcreteFoo (String name) {
super(name);
}
@Override
protected int getId() {
return 4; // chosen by fair dice roll.
// guaranteed to be random.
}
}
// in the foo package with the classes above
public class FooCollection {
private static Map<Integer, Foo> foos = new HashMap();
public static void add(Foo foo) {
synchronized(foos) {
foos.put(foo.getId(), foo); // can't call foo.getId()
}
}
}
// client code, not in the foo package
FooCollection.add(new ConcreteFoo("hello world"));
也就是说,我们将一个封装好的对象返回给调用者,但是任何获取该对象的方法都需要能够依赖于某些内部功能。内部功能不能成为接口的一部分(这将破坏封装),但要使它成为抽象基类的一部分,需要我们使用转换。
我们不能将Foo作为抽象类,因为其他接口需要扩展它以将可选的正交功能添加到比此处显示的更复杂的层次结构中。
此问题的标准方法是什么?您是否将getId添加到Foo界面,即使客户端不应该使用它?你是否在FooCollection.add中对BaseFoo执行了不安全的转换?如果你在投射之前检查,当你的类型不匹配时你会怎么做,即使它们总是应该用于所有意图和目的?
您在此类情况下获得的最佳实践信息将非常有用。
编辑:如果不清楚,此示例有意过度简化。关键点在于,有时您会返回对象的“界面视图”。当“接口视图”传递回特定于包的类时,传递给它的方法可能需要在其实现中使用内部功能。如何管理内部和公共功能之间的不匹配?
答案 0 :(得分:6)
好的,这里有几点:
与流行的观点相反,继承实际上不是关于共享代码。您在继承层次结构中创建的是一组共享一些常见抽象行为的事物;它有时会产生重复使用某些代码的效果。
在过去的几年中,时尚已经发生了很大变化,因此深层次和复杂的继承层次结构不再被认为是好的形式。一般用Java。你应该
如果您真的想要多重继承的效果,请为您的接口构建实现类,然后聚合它们。
特别是,通过使用接口和实现类定义类,可以使构建测试变得更加容易;如果您的界面是独立的,那么为该界面构建模拟几乎是微不足道的。
答案 1 :(得分:2)
我不知道“最佳”做法,但这里有几个想法。
接口应该将“做什么”和“要做什么”分开。我不认为getter和setter属于接口。我试着给他们更有意义的签名。
在你的情况下,我发现两个接口没有错:
public interface Nameable {
String getName();
}
public interface Identifiable {
int getId();
}
将两者分开;迫使客户只实施他们需要的。您决定使id
部分抽象类是任意的。将它分开并使其明确可能会有所帮助。
Casting失去了多态性的所有好处。我认为不应该轻易放弃它。如果必须将getId()
移动到界面,请执行此操作。如果您可以通过不同的选择来避免它,请执行此操作。
“最佳”取决于您的背景。在所有情况下,您的简单示例可能都不正确。