我被告知“为数据库对象建模一个抽象容器,构造接受一个孩子的变种,然后暴露一些儿童检查功能而不重复代码”。
这暗示了“计算孩子数”,“按标识符查找”等等。
为简单起见,下面的代码只有一个来自基本抽象DatabaseObject类型(即名称)的字段,但实际代码中包含“identifier”和一些复杂的元数据查找噱头等内容。
这个想法肯定是有用的,但只是看看我开始编码的东西让我想要呕吐:如果我继续沿着这条路走下去,那将是一个陷入困境的弗兰肯斯坦。有什么方法可以把它变成像样的Java吗?有参考的设计模式吗? (想到综合......)
前提:要共享的实际功能非常有用,并且确实适用于任何可能的可嵌套类型(模式具有表,表具有列,CompositeIndex具有子索引等),尤其是标识符查找。 ..
......但“必须有更好的方法”。我觉得我内心的声音说“无论何时你写这样的代码,把自己打扮成脸”。
帮助:)
public abstract class DatabaseContainerObject<ChildType extends DatabaseObject>
extends DatabaseObject {
protected List<ChildType> children;
public DatabaseContainerObject(String name, ChildType... children) {
super(name);
this.children = new ArrayList<ChildType>(children.length);
this.children.addAll(Arrays.asList(children));
}
protected List<ChildType> getChildren() {
return Collections.unmodifiableList(children);
}
... count ...
... find ...
... sort ...
... remove ...
...
}
答案 0 :(得分:1)
考虑策略模式(http://en.wikipedia.org/wiki/Strategy_pattern)。原因:
我猜,它是这样的:
public abstract class DatabaseContainerObject<ChildType extends DatabaseObject>
extends DatabaseObject {
protected List<ChildType> children;
private DataOperator dataOperator;
public Object find(){
return dataOperator.find(children);
}
}
public interface DataOperator{
public <ChildType extends DatabaseObject> find(List<ChildType> childList);
}
public Class GeneralDataOperator extends DataOperator{
public <ChildType> find(List<ChildType> childList){
//implements find;
}
}
然后,您可以使用依赖注入。
答案 1 :(得分:0)
复合材料很快就浮出水面,但你也应该研究装饰模式。
查找显然是递归的,但计算例如在叶子对象上是非常有限的,并且在所有类型的节点上都是一样的。
答案 2 :(得分:0)
带有建议的复合模式(骨架实现)来自项目18:首选接口到抽象类来自 Effective Java 2nd Edition 。
优点是未来的类可以扩展 DatabaseContainerObject 或实现 EntityCollection