Question

我目前正在设计一种非常分层的API，因为大多数对象类型都是另一种类型的容器对象的父级。例如：

interface Parent {
    Set<Child> getChildren();

    Child createChild();
}

interface Child {
    Parent getParent();

    // other methods
}

但是，当removeChild添加Parent等方法时，此设计会出现问题。当被调用时，孩子与父母分离，有效地使其孤立并使其过时。

但是，使用API的程序可能会保留对Child的引用，因此为确保不会错误地调用任何方法，当前设计会发现Child定义的所有方法都会抛出{如果目标是孤立的，则{1}}（扩展OrphanedObjectException）。

我不相信这是最好的解决方案，所以我想知道这个问题是否有更好或更多的OO方法。

Answer 1

我不认为这是＆＃34;层次结构＆＃34;有效的清理。如果孩子从父母身上移除后应该不再存在，那么你需要确保它不再存在。删除API的其他部分所持有的每个引用。

你可以这样做的一种方法是制作类似ChildManager的类，类跟踪需要被要求丢弃对子进程的每个对象，以及ChildConsumer接口。由使用Child的每个类实现。类似的东西：

class ChildManager {
   private Child child = null;

   public void register(Child child);
   public void unregister(Child child);
   public Child consume(ChildConsumer consumer);
}

interface ChildConsumer { 
    public void releaseChild(Child child);
}

现在Parent拥有ChildManager。每当它获得一个孩子，它就会调用register。每次另一个对象需要访问其中一个子对象时，它会调用consume，并且必须实现releaseChild，以便在使用该对象后不再具有对该子对象的引用。现在Parent负责在unregister期间致电remove，并为每位消费者致电unregister来电releaseChild，确保完全删除Child。

在某种意义上，感觉就像您重新实施引用计数一样，但设计一个OrphanedObjectException不会隐藏在每个方法调用之下的系统会更好在我看来。

另一种解决方案可能是将WeakReference<Child>传递给包含可能孤立Child的每个对象，并在每次调用null时检查get。这样可以使您免于OrphanedObjectException。这似乎更自然，而且是Java-ish，但是为代码中散布的null创建了许多丑陋的检查。

逻辑上孤立对象的替代方案

1 个答案: