为什么 Base FragmentActivity Honeycomb 是抽象的？答案

【问题标题】：Why is BaseFragmentActivityHoneycomb abstract?为什么 Base FragmentActivity Honeycomb 是抽象的？
【发布时间】：2017-01-05 19:34:11
【问题描述】：

为什么android.support.v4.app.BaseFragmentActivityHoneycomb 没有任何抽象方法却被声明为抽象？我知道他们不希望任何人实例化BaseFragmentActivityHoneycomb，但他们为什么不直接将BaseFragmentActivityHoneycomb 的方法onCreate() 的内容写在FragmentActivity 中？

这只是历史性的还是偶然的，还是有良好的设计意图？

【问题讨论】：

问“为什么开发人员 X 做出了 Y 决策？”在 Stack Overflow 上很少有用。唯一能明确回答问题的一方是开发者 X，开发者 X 不太可能看到这个问题。其他人只能提供猜测。问“当一个类没有abstract 方法时，为什么要将它声明为abstract？”是有效的，你可以举这个例子。
这不一定是真的。有几种设计选择是非常明智的，更有经验的开发人员可能会看着它们并说“嗯，这很明显”。（或者开发人员已经写过他们的决定。）如果这个特定问题不是这种情况，您应该解释原因。

标签： java android oop design-patterns

【解决方案1】：

为什么不把BaseFragmentActivityHoneycomb的onCreate方法的内容写在FragmentActivity里面？

我只能推测他们正在减少FragmentActivity 的关注数量，试图遵循SOLID programming 中的单一责任原则。

让我们看看BaseFragmentActivityHoneycomb的代码：

@Override
public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
    final View v = dispatchFragmentsOnCreateView(parent, name, context, attrs);
    if (v == null && Build.VERSION.SDK_INT >= 11) {
        // If we're running on HC or above, let the super have a go
        return super.onCreateView(parent, name, context, attrs);
    }
    return v;
}

虽然将它作为一个块包含在子类的 onCreate 中似乎微不足道，但 FragmentActivity 的 onCreate() 方法已经有 37 行长。如果与 Honeycomb 兼容性相关的特定功能在其自己的隔离类中，则维护程序员更容易理解。

【讨论】：