在超类外观中隐藏非相互方法

Question

有没有办法可以隐藏不符合特定方法条件的类型的非互方法？

假设我们有一个抽象超类，其中包含我们不想公开给对象本身的方法。我们创建了一个外观，其中包含我们希望允许对象使用的方法。（我们不希望突然将猫的年龄设置为 32 岁。）

我最终遇到了这样一种情况：我公开了一个特定子类的方法，而这个子类实际上是为另一个子类设计的。（即使我们在方法中可以控制类型是否正确）

场景：

public abstract class Animal {

    //setters and code we want to protect
}

public class Cat extends Animal{

    private boolean giveBirth;

    public void giveBirth(){giveBirth = true;}

    //setters etc


}

public class Bird extends Animal{

    private boolean layEgg;

    public void layEgg(){layEgg = true;}

    //setters etc

}

public class FacadeAnimal {

    Animal animal;

    public FacadeAnimal(Animal a){
        animal = a;
    }

    public void layEgg(){
        if(animal instanceof Bird){
            ((Bird) animal).layEgg();
        }
    }

    public void giveBirth(){
        if(animal instanceof Cat){
            ((Cat) animal).giveBirth();
        }
    }

}

所以在这种情况下，我们可以在方法内部控制，如果我们要产卵，类型需要是Bird。但是让猫下蛋对我们来说也是可以的。虽然逻辑搞定了，但是给Cat下蛋的选项还是不太直观

我认为可以创建一个 "facade inheritance structure"，我们为每个子类也为该特定子类创建一个外观。但就可扩展性而言，这意味着我们将迫使未来的开发人员不仅要创建子类，还要创建其外观的实现。

这是要走的路还是我们可以改变我们环绕它的方式？

干杯！

编辑：也许动物场景不是很清楚。

它可能以相同的方式是两辆不同的汽车，其中一辆有涡轮增压而另一辆没有，如果 "activateTurbo" 方法存在于外观中，我将能够在汽车上调用 activateTurbo 方法实际上没有涡轮增压器。

Answer 1

我会在 Animal 中将 giveBirth() 和 layEgg() 统一为一个方法，subclass 自己决定要做什么。

您还可以将此行为封装到一个新的 class 中，例如 NextGenerationStrategy with subclasses LayEggStrategy 或 GiveBirthStrategy。动物（鸟或猫）的子class选择自己的策略。因此，当您使用 Animal 时，您不在乎它会下蛋还是会分娩。

Answer 2

giveBirth() 和 layEgg() 等方法名称过于具体 - 考虑一些更常见的名称，例如：

public abstract class Animal {
    public void reproduce();
}

然后各个子类可以根据需要实现。例如：

public class Cat extends Animal {
    public void reproduce() {
       liveBirth();
   }

   private void liveBirth() {
       // ...
   }
}

和

public class Bird extends Animal {
    public void reproduce() {
       layEgg();
   }

   private void layEgg() {
       // ...
   }
}

这种方法可能会导致私有方法中至少有一些重复代码。正如@Lini所说，结合策略模式。稍微重构一下，由继承变为组合

在超类外观中隐藏非相互方法

Hide non mutual methods in superclass facade

java

inheritance

design-patterns

extensibility