9

グランドマスターが光を当てることができることを願っています。非常に高い概要は、私はコーディングの初心者ではありませんが、それでもOOPの初心者であるということです。このメッセージクラスのセットは、私たちが作成している大規模なシミュレーションアプリケーションの中心であり、愚かなことはしたくありません。このインターフェイスは、アプリケーションをシーケンサーから実行者に、またはその逆に半分に削減します。

私の質問は、継承階層をこれほど深くするのは悪い考えかどうかです（イメージはまだ具体化されておらず、最終的には5または6深くなる可能性があります）。これは、一部の子クラスが、継承するのではなく、親クラスに直接関連付けられるのとは対照的です。

深い継承階層は良い考えではなく、子クラスが単に親のデータを持つために継承している場合は、単に親を子のデータとして含める必要があることを読みましたが、私は苦労していますなぜ私の頭を包む時間。継承階層を7深さなどにすることにした場合、どのような悪いことが起こりますか？明らかにパフォーマンスに小さな影響があり、階層の最上位で変更を行うと、アプリ全体に大きな波紋が生じますが、それ以外は問題はありません。余談ですが、パフォーマンスのわずかな違いについてはほとんど気にしません。

クラス階層

（ボーナス質問：この種のものを処理する既製のパッケージはありますか？私たちはほとんどの低レベルの物理シミュレーションを処理していますが、シーケンスプログラムを作成する必要があります。私はこの疑いを持っています私がレイアウトしたものは、私の前の約10,000人のシミュレーション開発者のものと非常に似ています。）

（ボーナス質問＃2：ロサンゼルスでの生活を嫌うことのないシミュレーションシステムとOOPプログラミングの両方のマスターはいますか？私たちは採用しています。）

4

3 に答える 3

11

子クラスが単に親のデータを持つために継承している場合

これは悪い考えです。基本クラスを、一連の (具体的な) クラスが尊重する最も一般的なコントラクトとして定義するという理解があります。これは通常、契約が実装ではなく動作に関するものであることを意味します。

継承階層を 7 層にするなどの決定を下した場合、どのような悪いことが起こるでしょうか?

ここでの主な問題はありふれたものです。

  • 壊れやすい基底クラス (基底への変更は、派生クラスにとって悪夢です)
  • 結合の増加 (基本クラスが多すぎると密結合になります)
  • カプセル化が弱まる
  • テストの問題 (リーフ レベルのオーバーライドされたメソッドは、エンド ユーザーの動作を常に正しく再現するためにテストすることはできません。これは、あちこちで複数のチェーン呼び出しが行われているためです)
  • メンテナンス（強い結合によるもの）

(多くの人が、 Ada が人気がない理由、特に項目 6、パラ 6に関するこの論文を熟読したいと考えています。)

この種のものを処理する既製のパッケージはありますか?

あなたが何を探しているのかわかりませんが、自動化された階層単純化機能を探しているなら、私には何もわかりません。また、そのようなパッケージが存在する場合、選択した言語に大きく依存し、言及していません。

ほとんどの場合、このような問題は、集約や特性、依存性注入などの代替手段を検討することで解決できることに注意してください。これらは設計時の問題であり、通常 (IMO) コンパイラや何百万もの LOC を使用するよりも、ホワイトボードで解決するのが最適です。

于 2012-06-15T19:37:15.607 に答える
5

この質問を見るのはかなり遅いですが、私はこれについて多くの考えを持っており、深い継承階層に悩まされてきました。それらが悪い理由の 1 つは、多くのサブクラスを特殊化すると、分類が必然的に間違ってしまうためです。ただし、いったんクラス構造を配置すると、変更するのが難しくなります。変更すると、クライアント コードが壊れてしまうからです。

私はこれについてここにブログを書きました。

于 2015-04-21T04:20:45.830 に答える