代码可读性/习惯性实践/设计模式？

Question

我一直在分析一些可以像这样概括的类：

public class RulerFather {
    private Girl girl;
    private Pet  pet;

    public  RulerFather()
    {
        girl = new Girl(this);
        pet  = new Pet(this);
    }

    /*
     *  allowed messages between Girl and Pet   
     */
    public feedPet()
    {
        pet.receiveFood();
    }

    public lickGirl()
    {
        girl.beLicked();
    }
}
public class Girl {
    Father father;
    public Girl(Father father)
    {
        this.father = father;
    }
...

父亲实例化了女孩和宠物，并定义了可以交换的允许消息。 例如。在Girl的代码中，她可以执行以下操作喂养宠物（向宠物发送消息）：

father.feedPet();

我的意思是，父亲创建的对象可以交换消息，但只能使用父亲提供的方法，因此父亲是一种“统治者”，它定义了允许哪些方法在它们之间进行交换（在该交互级别）。

我的问题是，在我分析的代码中，我看到上面提到的和另一种方式之间的混合，该方式只是使女孩和宠物的引用公开而不是私有（这导致自由和女孩可以称呼的某些混乱）任何一种宠物方法，在RulerFather创建的对象范围内，RulerFather都会定义一些女孩和宠物之间的有效互动。

这与任何推荐的编码实践有关吗？ （甚至是我不知道的设计模式？）

Answer 1

这是一种有趣的方法，尽管会导致一些问题：

• 循环依赖关系：父类知道两个子类，反之亦然。因此，这三个组成了一个非常奇怪的三角形
• 内隐耦合：女生班知道有一个父亲可能养宠物

但是，这是 reducing 接口的一种方法。有时，您最终得到的旧类无法更改，但是为新用法提供了太多的方法。然后，您需要一种合理的方法来提供具有减少的“范围”的视图。但是该方法通过某种方式复制代码而起作用：父类定义其完全自己的接口！

除此之外，我在这里看不到特定的模式。

为了减轻我提到的问题，您一定会考虑使用界面。因此，所有类都应实现自己的接口，并且没有实现类对其他实现类一无所知。也许唯一的例外是必须知道针对不同接口类型实例化哪些impl类的代码。