Java 代码可读性/习惯做法/设计模式？

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

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;
    }
...

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

father.feedPet();

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

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

---

这是否与任何推荐的编码实践有关？或者甚至是一种我不知道的设计模式？

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

循环依赖：父类知道这两个子类，反之亦然。这三个人组成了一个非常奇怪的三角形 隐性耦合：女生们知道有一位父亲可能有一只宠物 然而，这是减少接口的一种方法。有时，您最终会得到无法更改的遗留类，但这些类为新用法提供了太多的方法。然后，您需要一种合理的方式来提供具有缩小范围的视图。但是这种方法是通过复制代码来工作的：父类定义了它自己的接口

除此之外，我不知道这里有什么特别的模式

---

为了缓解我提到的问题，您肯定会考虑使用接口。所以所有类都应该实现它们自己的接口，并且没有一个实现类知道任何关于其他实现类的信息。可能只有代码例外，它必须知道要为不同的接口类型实例化哪些impl类

我将按照您的建议检查接口。在这种情况下，有趣的是，女孩通过执行father.feedPet来喂养宠物，然后转到pet.receiveFood，在某种程度上似乎更具可读性，因为在一种情况下表示女孩的行为，而在另一种情况下表示宠物的行为。在我最初的案例中，女孩宠物和父亲类的名字都像管理者或控制者，阅读后，角色有点混淆。