5

有効な Java (Joshua Bloch) Item 17 は次のように述べています。

「デザインとドキュメントまたは継承またはそれ以外の禁止」

ただし、Android API をざっと見てみると、ほとんどの API クラスが非最終的なものであることがわかります。継承についても文書化されていれば問題ありません (たとえば、Viewof )。Activityただし、いくつかの非最終クラスもありますが、ドキュメントではこれらのクラスの継承については言及されていません。私の要点を説明するためのいくつかの任意の例：

  • システム サービスを表すクラス ( WifiManager、NotificationManager...)
  • のようなユーティリティ クラスUriMatcher。
  • のようないくつかのハードウェア固有のクラスCamera。

オープン性と拡張性は Android の哲学ですが、ここでは慣例が逆転していますか? つまり、すべての Android API クラスが (明示的に文書化されているかどうかにかかわらず) 継承されるように設計されていると想定できます。最終宣言されない限り？

4

2 に答える 2

4

多くの場合推奨されていませんが、Android 開発者は拡張性を実現するために多大な努力を払いました。この背後にある動機は、テスト環境に関連しているようです。

たとえば、WifiManager完成した場合、単体テストを作成する目的で偽物を作成することははるかに困難になります。ファイナライズを行わない場合、 をサブクラス化しWifiManager(たとえば、操作中に「予期しない」wifi 切断を模倣する)、カスタマイズされた testing からこのサブクラスのインスタンスを返すのは簡単Contextです。

したがって、エンド ユーザーに出荷するアプリケーションにこれらのクラスのサブクラスを実装する理由をおそらく見つけることはできませんが、何らかの理由で必要な場合は、それらを拡張できる柔軟性があります。

ユーティリティ クラスの場合、その答えは単純です。開発者がサブクラス化できるようにしても、クラスのユーティリティが低下するわけではありません。多くの場合、開発者は、集約や委譲よりも継承によって、より理解しやすいコードの再利用を実現できます。

于 2011-11-11T09:30:58.303 に答える
4

ちょうど私の €0,02: 本によるクリーンな OO 設計は 1 つのことですが、実際に考えられるすべてのユースケースで物事を機能させることは別のことです。クリーンな OO 設計の原則は、学術的な性質のものである場合があります。- そして多分少し白黒です。

たとえば、Google が提供する Android APIを使用しているのは、アプリ開発者だけでなく、一般的な API をデバイス向けに特化する必要があるデバイス メーカーです。

ですから、私にとって、SW のデザインはほとんどの場合、黒でも白でもありません。グレーの色合いが重要です。

そして最後に：実際には、（クラスで） 「不注意に」省略されたキーワードによって引き起こされる問題はめったに見られませんでしたが、（多くの場合、「私のコードはすっごく[素晴らしい|醜い]、誰もいない」などの考えによって引き起こされます実際には継承によって変更したいと思うでしょう」) は、かなりの苦痛になる可能性があります。finalfinal

「私は何も知らないことを知っている」がここに当てはまるようです:自分のコードが将来どのように使用される可能性があるかについて、他の人のクレイジーで、独創的で、創造的で、賢い... アイデアをすべて知っていると主張するのはおこがましいです。

于 2011-11-11T09:32:10.947 に答える