継承のための設計はどのように余分なコストを引き起こすことができますか？[閉まっている]

だから私はsealed classインシャープから継承したいと思い、やけどを負った。ソースにアクセスできない限り、封印を解除する方法はありません。

それから、「なぜsealed存在するのか」と考えさせられました。4ヶ月前。次のような多くのことを読んだにもかかわらず、私はそれを理解できませんでした。

• Jon Skeetの願いは、「クラスは.NETでデフォルトで封印されました。」
• 継承よりも構成を優先しますか？
• 「すべてのクラスを封印するべきではありません（...）」
• Sealedクラスをどのようにモックしますか？

それ以来、すべてを消化しようとしましたが、それは私にとってはやりすぎです。最終的に、昨日私はそれをもう一度試しました。私はそれらすべてをもう一度スキャンし、さらにいくつかをスキャンしました：

• クラスが「抽象」または「最終/封印」以外のものでなければならないのはなぜですか？
• 15年以上のプログラミングで、すでにリンクされている質問からの答えのうち、最初にSOLIDを聞いたことがあり、明らかに4ヶ月前にそれをすべて読んでいませんでした

最後に、熟考した後、新しいタイトルに基づいて元の質問を大幅に編集することにしました。

古い質問が広すぎると主観的でした。それは基本的に尋ねていました：

1. 旧称：シールを使用する1つの正当な理由
2. 本文：シールクラスを適切に変更する方法 継承を忘れますか？コンポジションを使用しますか？

しかし、今、理解すること（私は昨日なかった）すべてのsealed継承を阻止されず、そして私たちは、実際に使用する必要がありますすることができます継承上の組成を、私は私がした必要なものを実現実用例。

私はここに私の質問は正確に何を（実際には常にされている）であると思いMr.Mindorはチャットで私の提案：どのように余分なコストの原因継承のために設計することができますか？

これを理解するのはそれほど難しくありません。sealed彼らの生活を楽にし、たくさんのお金を節約し、彼らの評判を助けるために、マイクロソフトのために特別に作成されました。これは言語機能であるため、他の誰もが使用できますが、シールを使用する必要はおそらくないでしょう。

ほとんどの人は、クラスを拡張できないことに不満を抱いており、そうすれば、正しく動作させるのは開発者の責任であることを誰もがよく知っていると言います。同じ人々がWindowsの歴史についての手がかりを持たず、問題の1つがsealed解決しようとしていることを除いて、それは正しいです。

開発者が.Netコアクラスを拡張し（sealedが存在しなかったため）、完全に動作するようになったとします。はい、開発者向け。開発者は製品を顧客に提供します。開発者のアプリは素晴らしい作品です。顧客は満足しています。人生は素晴らしい。

Microsoftは、この特定の.Netコアクラスのバグ修正を含む新しいオペレーティングシステムをリリースしました。顧客は時代に遅れずについていくことを望み、新しいオペレーティングシステムをインストールすることを選択します。.Netコアクラスで修正されたバグを考慮しなかったため、顧客が非常に気に入っているアプリケーションは突然動作しなくなりました。

誰が責任を負いますか？

Microsoftの歴史に詳しい人は、Microsoftの新しいOSがWindowsライブラリを悪用したアプリケーションソフトウェアではなく、責任を負うことを知っています。そのため、問題を作成したアプリケーション会社ではなく、Microsoftが問題を修正することが義務付けられています。これが、Windowsコードが肥大化した理由の1つです。私が読んだことから、Windowsオペレーティングシステムコードには特定のif-thenが散らばっていて、特定のアプリケーションとバージョンが実行されているかどうかをチェックし、実行されている場合はプログラムを機能させるための特別な処理を行います。それは、Microsoftが別の会社の無能さを修正するために費やした大金です。

使用sealedしても上記のシナリオが完全になくなるわけではありませんが、役立ちます。

sealedクラスの作成者が継承されるように設計していないことを示すために使用されます。 それ以下でも、それ以上でもありません。

多くのプログラマーにとって、インターフェースを適切に設計することはすでに困難です。潜在的に継承できるクラスを適切に設計すると、コードの難易度と行が追加されます。記述されたコード行が増えると、維持するコードが増えます。この困難さの増大を避けるためにsealed、クラスが継承されることを意図していないことを示すことができます。このコンテキストでは、クラスの封印は問題に対する完全に有効な解決策です。

クラスCustomBoeing787がから派生した場合を想像してくださいAirliner。これCustomBoeing787はAirliner、からの一部の保護されたメソッドをオーバーライドしますが、すべてではありません。開発者に十分な時間があり、それだけの価値がある場合、クラスを単体テストして、オーバーライドされていないメソッドが呼び出されるコンテキスト（たとえば、オブジェクトの状態を変更する保護されたセッター）でも、すべてが期待どおりに動作することを確認できます。同じ開発者が（1）時間がない場合、（2）上司/顧客にさらに数百または数千ドルを費やすことを望まない場合、または（3）追加のコードを記述したくない場合今すぐ必要（YAGNI）、それから彼は：

• 潜在的なバグを気にするためにこのプロジェクトを後で維持するプログラマの懸念であることを考慮して、コードをそのままリリースするか、

• またはsealed、このクラスが継承されることを意図していないことを明示的に将来のプログラマーに示すようにクラスをマークします。

可能な限り多くのクラスを封印するのは良い考えですか、それともできるだけ少なくするのですか？私の経験から、決定的な答えはありません。一部の開発者は、使いsealedすぎる傾向があります。他の人は、クラスがどのように継承されるか、およびクラスが引き起こす可能性のある問題を気にしません。そのような使用法を考えると、問題は、プログラマーがインデントに2つまたは4つのスペースを使用すべきかどうかを判断することにある問題に似ています。正しい答えはありません。

クラスがシールされると、そのタイプを使用するコードは、クラスが処理していることを正確に知ることができます。

C＃は今でstringありsealed、あなたはそれを継承することはできませんが、聞かせてのは、それはそうではなかったことを第二のために想定しています。もしそうなら、誰かがこのようなクラスを書くことができます：

public class EvilString// : String
{
    public override string ToString()
    {
        throw new Exception("I'm mean");
    }
    public override bool Equals(object obj)
    {
        return false;
    }
    public override int GetHashCode()
    {
        return 0;
    }
}

これは、デザイナーstringが真実であると知っていたあらゆる種類のプロパティに違反している文字列クラスになります。彼らはEqualsメソッドが推移的であることを知っていましたが、そうではありません。ちなみに、このequalsメソッドは対称ではありません。文字列はそれに等しいかもしれませんが、その文字列には等しくないでしょう。ToStringメソッドがstringnull以外の値に対して例外をスローしないという仮定のもとでコードを書いたプログラマーがいるはずです。これで、その仮定に違反することができます。

これを行うことができる他のクラスがいくつもあり、違反する可能性のある他のあらゆる種類の仮定があります。言語機能を削除した場合sealed次に、言語設計者は、すべてのライブラリコードでこのようなことの会計処理を開始する必要があります。使用したいタイプの拡張タイプが「適切に」書かれていることを確認するために、あらゆる種類のチェックを実行する必要があります。これは非常に費用のかかる作業です（開発時でも実行時でも）。クラスを封印できることにより、これは不可能であり、意図的に拡張するように設計されたタイプを除き、独自のタイプの実装の詳細についての主張に違反することはありません。拡張するように設計されたタイプの場合、言語コードはそれらをどのように扱うかについてはるかに防御的である必要があることがわかります。

シールを使用する正当な理由はありますか？

え？しばしばあるわけではない。私は、私は不変のタイプ（または他のいくつかの制限）がある場合にのみ密封され使用されます本当に 本当に不変のままにする必要がありますをし、私が信頼相続は、システムに微妙な、catastropicバグを導入することなく、その要件をfurfillすることはできません。

シールを使用する正当な理由があり、それをすべてのデフォルトとして使用する必要があると仮定します。継承で何をしますか？

デフォルトではないものには継承を使用します。たとえ合成が継承よりも好まれたとしても（そうであるとしても）、それは継承が破棄されることを意味するものではありません。継承には、設計とコードの保守性に導入されるいくつかの固有の問題があり、コンポジションは（一般的に）問題がほとんどなく同じことをほとんど行います。そして、それは、構成が好まれても、継承が問題の特定のサブセットに適していることを意味します。

意地悪すぎるつもりはありませんが、SOLIDと単体テストについて聞いたことがあれば、岩の下から抜け出して実際にコードを書いてください。物事は明確ではなく、「常にXを実行する」、「Yを使用しない」、「Zが最適」が正しい方法になることはめったにありません（質問の意見に基づいて引き寄せられるようです）。コードを書くsealedと、他のトレードオフと同様に、良い場合と悲しみを引き起こす場合があります。

まず、Microsoftがクラスを封印する理由に関するEric Lippertの投稿を読んでください。

http://blogs.msdn.com/b/ericlippert/archive/2004/01/22/61803.aspx

次に、sealedキーワードは、それが行うことを正確に行うために存在します-継承を防ぎます。継承を防ぎたい状況はたくさんあります。コレクションを持っているクラスを考えてください。コードが特定の方法で動作するそのクラスに依存している場合、誰かがそのクラスのメソッドまたはプロパティの1つをオーバーライドして、アプリケーションが失敗することは望ましくありません。

第三に、sealedを使用すると、継承よりも合成が促進されます。継承よりも合成を使用するということは、リスコフの置換原則を破ることができず、オープン/クローズの原則に従っていることを意味します。 sealedしたがって、ooプログラミングの5つの最も重要な原則のうちの2つに従うことを支援するキーワードです。私はそれが非常に貴重な機能になると思います。

この質問には客観的な答えはなく、すべてあなたの視点に依存していると思います。

一方では、一部の人々はすべてを「オープン」にしたいと考えており、すべてが正しく機能していることを確認する負担は、クラスを拡張する人にあります。これが、クラスがデフォルトで継承に対して開かれている理由です。そして、なぜJavaメソッドはデフォルトですべて仮想であるのか。

一方、デフォルトではすべてを閉じて、それを開くためのオプションを提供したい人もいます。この場合、基本クラスの作成者は、「オープン」にするすべてのものを、考えられるあらゆる方法で安全に使用する必要があります。これが、C＃でデフォルトですべてのメソッドが非仮想であり、オーバーライドされるように仮想と宣言する必要がある理由です。また、これらの人々のために、「オープン」デフォルトを回避する方法である必要があります。クラスをシール/ファイナルにするようなものです。クラスから派生した誰かが自分のクラスの設計に大きな問題を抱えているからです。

C＃で封印されている問題は、かなり最終的なことです。7年間のC＃商用開発で​​使用した唯一の場所は、Microsoft .NETクラスです。フレームワーククラスを拡張して調整された動作を実装する正当な理由があり、クラスが封印されていたため、 。

使用可能なすべての方法を考えてクラスを作成することは不可能であり、それらのいずれも正当なものではないと判断することはできません。同様に、フレームワークのセキュリティが継承されないクラスに依存している場合、セキュリティ設計の欠陥があります。

ですから、結論として、封印されたものは有用な目的には役立たないという見解をしっかりと持っています。

これまでのところ、封印された場所を正当化する3つの議論があったことがわかります。

1. 引数1は、人々がクラスを継承し、実際に内部を正しく理解せずにそのクラスの内部へのアクセスを増やしたときにバグの原因を排除することです。

2. 引数2は、Microsoftクラスを拡張し、Microsoftがそのクラスにバグ修正を実装したが、そのバグに依存しているエクステンションがコードが壊れている場合、Microsoftは非難を取得し、それを防ぐことができます

3. 引数3は、クラスの開発者として、クラスの設計の一環として、クラスを拡張できるようにするかどうかの選択です。

引数1は、エンドプログラマが私のコードの使用方法を知らないという引数のようです。そうかもしれませんが、オブジェクトインターフェイスへのアクセスを許可した場合でも、オブジェクトを使用し、使用方法を理解せずに呼び出しを行うことは事実です。 。これは、封印の必要性の弱い正当化です。

arg 2の事実ベースはどこから来たのか理解しています。特に、Microsoftがwin32 api呼び出しに追加のOSチェックを行って、不正な呼び出しを特定すると、Windows NTと比較してWindows XPの一般的な安定性が向上しますが、短期的にはWindows XPのリリース時に多くのアプリが破損しました。マイクロソフトは、これらのチェックに「ルール」を入れることでこれを解決しました。アプリXがこのルールに違反する場合は無視します。これは既知のバグです

引数2は貧弱な引数です。なぜなら、。壊れた動作に依存する回避策が壊れていることを意味します。継承を使用してこの問題を回避した場合でも、他の追加ラッパーコードを使用した場合でも、コードが修正されると、回避策は無効になります。

引数3は、自己を正当化する実質を持つ唯一の引数です。しかし、まだ弱いです。これは、コードの再利用に反するだけです。

sealed静的メソッドのみを含むクラスでのみキーワードを使用します。

私の質問から明らかなように、私はここの専門家ではありません。しかし、私は存在する理由sealedさえ見当たりません。

コードアーキテクトがインターフェイスを設計するのを支援するために作成されたようです。野生に出て、多くの人がそれを継承するクラスを書きたい場合、そのクラス内の何かを変更すると、あまりにも多くの人のためにそれを壊す可能性があります。だから私たちはそれを封印することができ、誰も継承することはできません。"問題が解決しました"。

まあ、「スポットをカバーし、別のものを発見する」ように見えます。そして、それは問題を解決することすらしていません-それはただツールを継承することです：継承です。他のツールと同様に、多くの使用法があり、不安定なクラスから継承することはリスクです。そのリスクを負った人は誰でもよく知っているはずです。

キーワードがあるかもしれないstableので、人々はそれを継承する方が安全だと知っているでしょう。