我有一个基础课，Base。它有两个子类，Sub1和Sub2。每个子类都有一些其他方法。例如，Sub1has Sandwich makeASandwich(Ingredients... ingredients)和Sub2has boolean contactAliens(Frequency onFrequency)。

由于这些方法采用不同的参数并且做的事情完全不同，因此它们是完全不兼容的，我不能仅使用多态来解决此问题。

Base提供了大多数功能，并且我有大量的Base对象集合。但是，所有Base对象都是a Sub1或a Sub2，有时我需要知道它们是什么。

执行以下操作似乎是个坏主意：

for (Base base : bases) {
    if (base instanceof Sub1) {
        ((Sub1) base).makeASandwich(getRandomIngredients());
        // ... etc.
    } else { // must be Sub2
        ((Sub2) base).contactAliens(getFrequency());
        // ... etc.
    }
}

因此，我想出了一个避免这种情况的策略。 Base现在有以下方法：

boolean isSub1();
Sub1 asSub1();
Sub2 asSub2();

当然，将Sub1这些方法实现为

boolean isSub1() { return true; }
Sub1 asSub1();   { return this; }
Sub2 asSub2();   { throw new IllegalStateException(); }

并Sub2以相反的方式实现它们。

不幸的是，现在Sub1，Sub2这些方法已在自己的API中使用。因此，我可以在上执行此操作Sub1。

/** no need to use this if object is known to be Sub1 */
@Deprecated
boolean isSub1() { return true; }

/** no need to use this if object is known to be Sub1 */
@Deprecated
Sub1 asSub1();   { return this; }

/** no need to use this if object is known to be Sub1 */
@Deprecated
Sub2 asSub2();   { throw new IllegalStateException(); }

这样，如果已知对象仅为a Base，则不建议使用这些方法，并且可以使用这些方法将自身“转换”为其他类型，以便可以在其上调用子类的方法。在某种程度上，这对我来说似乎很优雅，但是，另一方面，我有点在滥用“不推荐使用的注释”，以从类中“删除”方法。

由于Sub1实例实际上是一个 Base，因此使用继承而不是封装确实有意义。我做得好吗？有解决这个问题的更好方法吗？

正如其他一些答案所建议的那样，向基类添加函数并不总是很有意义。添加过多的特殊功能可能导致将不相关的组件绑定在一起。

例如，我可能有一个Animal带有Cat和Dog组件的类。如果我希望能够打印它们或在GUI中显示它们，那么对我来说，添加renderToGUI(...)和添加sendToPrinter(...)到基类可能就太过分了。

您使用的类型检查和类型转换方法很脆弱-但至少确实使关注点分离了。

但是，如果您发现自己经常进行这些类型的检查/广播，那么一种选择是为其实现访客/双重分发模式。看起来像这样：

public abstract class Base {
  ...
  abstract void visit( BaseVisitor visitor );
}

public class Sub1 extends Base {
  ...
  void visit(BaseVisitor visitor) { visitor.onSub1(this); }
}

public class Sub2 extends Base {
  ...
  void visit(BaseVisitor visitor) { visitor.onSub2(this); }
}

public interface BaseVisitor {
   void onSub1(Sub1 that);
   void onSub2(Sub2 that);
}

现在您的代码成为

public class ActOnBase implements BaseVisitor {
    void onSub1(Sub1 that) {
       that.makeASandwich(getRandomIngredients())
    }

    void onSub2(Sub2 that) {
       that.contactAliens(getFrequency());
    }
}

BaseVisitor visitor = new ActOnBase();
for (Base base : bases) {
    base.visit(visitor);
}

主要好处是，如果添加子类，则会得到编译错误，而不是无提示丢失情况。新的访问者类也成为将函数引入其中的一个不错的目标。例如，getRandomIngredients()进入可能有意义ActOnBase。

您还可以提取循环逻辑：例如，上面的片段可能会变成

BaseVisitor.applyToArray(bases, new ActOnBase() );

进一步按摩并使用Java 8的lambda和流技术，您将可以

bases.stream()
     .forEach( BaseVisitor.forEach(
       Sub1 that -> that.makeASandwich(getRandomIngredients()),
       Sub2 that -> that.contactAliens(getFrequency())
     ));

哪一种IMO看起来都看起来既简洁又简洁。

这是一个更完整的Java 8示例：

public static abstract class Base {
    abstract void visit( BaseVisitor visitor );
}

public static class Sub1 extends Base {
    void visit(BaseVisitor visitor) { visitor.onSub1(this); }

    void makeASandwich() {
        System.out.println("making a sandwich");
    }
}

public static class Sub2 extends Base {
    void visit(BaseVisitor visitor) { visitor.onSub2(this); }

    void contactAliens() {
        System.out.println("contacting aliens");
    }
}

public interface BaseVisitor {
    void onSub1(Sub1 that);
    void onSub2(Sub2 that);

    static Consumer<Base> forEach(Consumer<Sub1> sub1, Consumer<Sub2> sub2) {

        return base -> {
            BaseVisitor baseVisitor = new BaseVisitor() {

                @Override
                public void onSub1(Sub1 that) {
                    sub1.accept(that);
                }

                @Override
                public void onSub2(Sub2 that) {
                    sub2.accept(that);
                }
            };
            base.visit(baseVisitor);
        };
    }
}

Collection<Base> bases = Arrays.asList(new Sub1(), new Sub2());

bases.stream()
     .forEach(BaseVisitor.forEach(
             Sub1::makeASandwich,
             Sub2::contactAliens));

在我看来：您的设计是错误的。

翻译成自然语言，您说的是以下内容：

有了我们animals，有cats和fish。 animals有特性，这是共同的cats和fish。但是，这还不够：有一些属性，分化cat的fish，因此，你需要的子类。

现在您有一个问题，您忘记为运动建模了。好的。这是相对容易的：

for(Animal a : animals){
   if (a instanceof Fish) swim();
   if (a instanceof Cat) walk();
}

但这是一个错误的设计。正确的方法是：

for(Animal a : animals){
    animal.move()
}

move每个动物在哪里都将实施不同的共享行为。

由于这些方法采用不同的参数并且做的事情完全不同，因此它们是完全不兼容的，我不能仅使用多态来解决此问题。

这意味着：您的设计已损坏。

我的建议：重构Base，Sub1和Sub2。

很难想象您遇到一堆东西并希望他们做一个三明治或与外星人联系的情况。在大多数情况下，您会发现这种类型的转换将使用一种类型的操作-例如，在clang中，您过滤了一组声明用于getAsFunction返回非null的声明的节点，而不是对列表中的每个节点执行不同的操作。

可能是您需要执行一系列操作，而执行该操作的对象之间实际上并不相关。

因此，而不是列表，而是Base在动作列表上工作

for (RandomAction action : actions)
   action.act(context);

哪里

interface RandomAction {
    void act(Context context);
} 

interface Context {
    Ingredients getRandomIngredients();
    double getFrequency();
}

您可以在适当的情况下让Base实现一种方法来返回操作，或者通过其他任何方式都需要从基本列表中的实例中选择操作（因为您说不能使用多态性，因此大概可以采取该操作）不是该类的函数，而是基类的其他一些属性；否则，您只需给Base提供act（Context）方法）

如果您的子类实现了一个或多个定义它们可以做什么的接口，该怎么办？像这样：

interface SandwichCook
{
    public void makeASandwich(String[] ingredients);
}

interface AlienRadioSignalAwarable
{
    public void contactAliens(int frequency);

}

然后您的课程将如下所示：

class Sub1 extends Base implements SandwichCook
{
    public void makeASandwich(String[] ingredients)
    {
        //some code here
    }
}

class Sub2 extends Base implements AlienRadioSignalAwarable
{
    public void contactAliens(int frequency)
    {
        //some code here
    }
}

您的for循环将变为：

for (Base base : bases) {
    if (base instanceof SandwichCook) {
        base.makeASandwich(getRandomIngredients());
    } else if (base instanceof AlienRadioSignalAwarable) {
        base.contactAliens(getFrequency());
    }
}

这种方法有两个主要优点：

• 不涉及演员
• 您可以让每个子类实现所需数量的接口，这确实为将来的更改提供了一定的灵活性。

PS：很抱歉，接口的名称，在那个特定时刻我想不出任何更酷的东西：D。

如果一个家庭中的几乎任何类型都可以直接用作满足某些标准的某个接口的实现，或者可以用于创建该接口的实现，则该方法可能是一个好方法。恕我直言，内置的收集类型会从这种模式中受益，但是由于它们并非出于示例目的，因此我将创建一个收集接口BunchOfThings<T>。

的某些实现BunchOfThings是可变的；有些不是。在许多情况下，Fred的对象可能想要保留它可以用作a的对象，BunchOfThings并且知道Fred不能修改它。可以通过两种方式满足此要求：

1. 弗雷德（Fred）知道，它仅包含对此的引用BunchOfThings，并且在BunchOfThings内部任何地方都没有对其内部的外部引用。如果没有其他人引用BunchOfThings或其内部，则没有其他人可以对其进行修改，因此约束将得到满足。

2. 无论是BunchOfThings，也没有任何它的内部到外部引用存在的，可通过任何手段进行修改。如果绝对没有人可以修改BunchOfThings，则约束将得到满足。

满足约束的一种方法是无条件复制任何接收到的对象（递归处理任何嵌套组件）。另一个方法是测试接收到的对象是否保证不变性，如果不是，则对其进行复制，并同样处理任何嵌套组件。另一种方法可能比第二种方法更干净，而第一种AsImmutable方法则更快，它提供了一种方法，该方法要求对象制作自己的不可变副本（AsImmutable在支持它的任何嵌套组件上使用）。

也可以提供相关方法asDetached（供代码接收对象并且不知道是否要对其进行突变时使用，在这种情况下，应将可变对象替换为新的可变对象，但可以保留不可变对象按原样），asMutable（如果对象知道它将保存一个较早返回的对象asDetached，即对可变对象的非共享引用或对可变对象的可共享引用），以及asNewMutable（如果代码接收到外部参考并且知道它将要在其中更改数据的副本-如果传入数据是可变的，则没有理由从制作不可变的副本开始，该副本将立即用于创建可变的副本然后丢弃）。

请注意，尽管这些asXX方法可能返回略有不同的类型，但是它们的真正作用是确保返回的对象将满足程序需求。

忽略是否​​有一个好的设计，并假设它是好的还是至少可以接受的问题，我想考虑子类的功能，而不是类型。

因此，要么：

将有关三明治和外星人存在的一些知识移到基类中，即使您知道基类的某些实例也不能做到这一点。在基类中实现它以引发异常，并将代码更改为：

if (base.canMakeASandwich()) {
    base.makeASandwich(getRandomIngredients());
    // ... etc.
} else { // can't make sandwiches, must be able to contact aliens
    base.contactAliens(getFrequency());
    // ... etc.
}

然后，将覆盖一个或两个子类canMakeASandwich()，并且只有一个实现makeASandwich()和contactAliens()。

使用接口而不是具体的子类来检测类型具有的功能。不用理会基类，然后将代码更改为：

if (base instanceof SandwichMaker) {
    ((SandwichMaker)base).makeASandwich(getRandomIngredients());
    // ... etc.
} else { // can't make sandwiches, must be able to contact aliens
    ((AlienContacter)base).contactAliens(getFrequency());
    // ... etc.
}

或可能的话（如果此选项不适合您的样式，或者对于您认为明智的任何Java样式，请随时忽略此选项）：

try {
    ((SandwichMaker)base).makeASandwich(getRandomIngredients());
} catch (ClassCastException e) {
    ((AlienContacter)base).contactAliens(getFrequency());
}

就我个人而言，我通常不喜欢后一种捕获一半期望的异常的样式，因为存在不适当地捕获ClassCastException来自getRandomIngredients或makeASandwich，但YMMV 的风险。

在这里，我们有一个有趣的案例，该案例将基类转换为自己的派生类。我们完全知道这通常是不好的，但是如果我们想说我们找到了一个很好的理由，那么让我们看一下这可能是什么约束：

1. 我们可以涵盖基类中的所有情况。
2. 永远不会有任何外国派生类添加新的案例。
3. 我们可以接受在基类的控制下对其进行调用的策略。
4. 但是从我们的科学中我们知道，对于不在基类中的方法，在派生类中做什么的策略是派生类而不是基类的策略。

如果为4，则我们有：5.派生类的策略始终与基类的策略处于相同的政治控制之下。

2和5都直接暗示我们可以枚举所有派生类，这意味着不应有任何外部派生类。

但是，这就是事情。如果它们全部属于您，则可以将if替换为一个虚拟方法调用的抽象（即使这是一个废话），并摆脱if和self-cast。因此，请不要这样做。可以使用更好的设计。

将一个抽象方法放在基类中，该基类在Sub1中做一件事，在Sub2中做另一件事，然后在您的混合循环中调用该抽象方法。

class Sub1 : Base {
    @Override void doAThing() {
        this.makeASandwich(getRandomIngredients());
    }
}

class Sub2 : Base {
    @Override void doAThing() {
        this.contactAliens(getFrequency());
    }
}

for (Base base : bases) {
    base.doAThing();
}

请注意，这可能需要其他更改，具体取决于如何定义getRandomIngredients和getFrequency。但是，老实说，无论如何，在与外星人联系的类中，定义getFrequency可能是一个更好的地方。

顺便说一句，您的asSub1和asSub2方法绝对是不正确的做法。如果要执行此操作，请通过投射进行。这些方法没有给您铸造所没有的。

你可以推都makeASandwich和contactAliens成的基类，然后用虚拟实现方式实现它们。由于返回类型/参数无法解析为通用基类。

class Sub1 extends Base{
    Sandwich makeASandwich(Ingredients i){
        //Normal implementation
    }
    boolean contactAliens(Frequency onFrequency){
        return false;
    }
 }
class Sub2 extends Base{
    Sandwich makeASandwich(Ingredients i){
        return null;
    }
    boolean contactAliens(Frequency onFrequency){
       // normal implementation
    }
 }

这种事情有明显的弊端，例如这对方法的约定意味着什么，以及您可以和不能推断结果的上下文。您无法想像，因为我没有做一个三明治，所以尝试中用尽的食材等

您所做的完全合法。不要因为那些在某些书中读到过教条而反对只是重复教条的反对者。教条在工程学中没有地位。

我已经使用过相同的机制几次，并且可以自信地说，Java运行时也可以在我可以想到的至少一个地方完成相同的操作，从而提高了代码的性能，可用性和可读性。使用它。

举个例子java.lang.reflect.Member，它是基体java.lang.reflect.Field和java.lang.reflect.Method。（实际的层次结构要复杂得多，但这无关紧要。）字段和方法是千差万别的动物：一个具有您可以获取或设置的值，而另一个则没有这样的东西，但是可以使用大量参数，并且可能返回值。因此，字段和方法都是成员，但是您可以使用它们做的事情与做三明治和联系外星人一样彼此不同。

现在，在编写使用反射的代码时，我们经常会Member手握一个a ，并且我们知道它要么是Methoda Field，要么是a （或者很少是其他东西），但是我们必须做所有繁琐的工作instanceof才能精确地找出它是什么，然后我们必须对其进行强制转换以获得正确的参考。（这不仅繁琐，而且效果也不佳。）Method该类可以非常轻松地实现您所描述的模式，从而使成千上万的程序员的生活变得更轻松。

当然，此技术仅在您拥有（并将始终拥有）源级控制的紧密耦合的类的小型，定义良好的层次结构中才可行：如果您的类层次结构是可能会被不自由重构基础阶级的人所扩大。

这是我所做的与您所做的不同的地方：

• 基类为整个asDerivedClass()方法系列提供默认实现，使每个方法都返回null。

• 每个派生类仅覆盖asDerivedClass()方法之一，this而不是返回null。它不会覆盖其余的任何内容，也不希望了解有关它们的任何信息。因此，不会IllegalStateException抛出。

• 基类还提供final了整个isDerivedClass()方法家族的实现，其编码如下：return asDerivedClass() != null; 这样，派生类需要重写的方法的数量将最小化。

• 我没有@Deprecated在这种机制中使用过，因为我没有想到它。既然您给了我这个主意，我将使用它，谢谢！

C＃具有通过使用as关键字内置的相关机制。在C＃中，您可以说，DerivedClass derivedInstance = baseInstance as DerivedClass并且您将获得对a的引用（DerivedClass如果您baseInstance属于该类，或者null不是）。从理论上讲，此方法的性能要优于is强制转换（（is是公认的更好的C＃关键字instanceof，），），但我们手工制作的自定义机制的性能甚至更好：instanceofJava 的一对铸造操作因为asC＃的运算符的执行速度不如我们的自定义方法的单个虚拟方法调用快。

我在此提出一个命题，即应将此技术声明为一种模式，并为其找到一个好的名称。

哎呀，谢谢你的投票！

争议摘要，可帮助您免去阅读评论的麻烦：

人们的反对意见似乎是，原始设计是错误的，这意味着您永远都不应拥有从一个通用基类派生的截然不同的类，或者即使您这样做，使用这种层次结构的代码也永远不应处于基本参考，需要弄清楚派生的类。因此，他们说，这个问题和我的回答所提出的自我投射机制可以改善原始设计的使用，一开始就没有必要。（他们并没有真正谈论自广播机制本身，他们只是抱怨该机制打算应用于的设计的性质。）

然而，在上面我的例子都已经表明，Java运行时的创造者的确在选择的正是这样的设计java.lang.reflect.Member，Field，Method层次结构，并在评论下面我还表明，C＃运行时的创作者在独立抵达相当于设计为System.Reflection.MemberInfo，FieldInfo，MethodInfo层次结构。因此，这是两种不同的现实世界场景，它们正好坐在每个人的鼻子下面，并且使用精确的此类设计具有可证明可行的解决方案。

这就是以下所有评论的内容。几乎没有提到自铸造机制。