android.support.v4.app.BaseFragmentActivityHoneycombは実際に抽象メソッドがないときに抽象宣言されたのはなぜですか？誰もがBaseFragmentActivityHoneycombをインスタンス化することを望んでいないと思っていますが、なぜonCreate()の内容をBaseFragmentActivityHoneycombに書き込むのですか？FragmentActivity？なぜBaseFragmentActivityHoneycombは抽象ですか？
これはちょうど歴史的か偶然であるのか、それとも良い設計意図を持っていますか？
なぜ、彼らはFragmentActivityの中にBaseFragmentActivityHoneycombのonCreateメソッドのコンテンツを書きませんか？
私は、彼らがSOLID programmingに単一責任の原則に従っしようとFragmentActivityの懸念の数を減らしていると推測することができます。
はのは、その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互換性に関連する特定の機能が独自の分離クラスにある場合、メンテナンスプログラマーが理解しやすくなります。
「なぜDeveloper XはDecision Yを作ったのですか？ onスタックオーバーフローはめったに役に立ちません。決定的に質問に答えることができる唯一のパーティーはDeveloper Xです。Developer Xがこの質問を見ることはまずありません。他の誰も推測しかできない。 「抽象メソッドがないときにクラスを抽象クラスとして宣言するのはなぜですか？この例を例として挙げることができます。 – CommonsWare
これは必ずしも真実ではありません。単に賢明な設計選択肢がいくつかあり、経験豊富な開発者がそれらを見て「よく分かります」と言うかもしれません。 （または、おそらく開発者**は、彼らの決定について**書いています。）これがこの特定の質問のケースでない場合は、理由を説明する必要があります。 – giusti