System.Stringが封印されている理由に興味がありますか？
私はそれを継承しないために必要なことは何でもできますが、それでも-なぜですか？
本質的に、特定のメソッドとプロパティを持つ文字列であるクラスはたくさんあります。それらは識別子、電子メール、名前などです。
オブジェクト指向設計は、特定のクラスに機能をカプセル化することを提案しています。そしてここでは、最も人気のあるオブジェクトフレームワークで最も使用可能な基本型が拡張できないという奇妙な状況があります。
ありがとうございました。
編集済み。
不変性に関するコメント。プライベートメソッドで状態に関連するすべてのものを非表示にし、子クラスがクラスのデータに読み取り専用でアクセスできるようにするのは簡単です。
// Safe inheritable immutable string (pseudocode).
class String
{
// Private state
private byte[] state;
private void EditState(byte[]) {}
// Protected read-only access to state
protected byte getReadOnlyData() {}
// Available to child classes overridable methods.
protected virtual getHashCode() {}
protected virtual xxx() {}
}
実際、実際のアプリケーションのオブジェクトのほとんどは文字列です。これらすべての連載、ASIN、IMEIなど、および名前、コメントは、その性質上文字列です。データベースから文字列として取得するか、Webページのテキストボックスのどこかに文字列として入力するか、バーコードスキャナーなどで缶詰にします。
そして、多かれ少なかれ同じことをする複数のクラスを発明する代わりに、特定の機能を備えた文字列を持つことは本当に素晴らしく、より安全で、はるかにエレガントでしょう。
本質的に、特定のメソッドとプロパティを持つ文字列であるクラスはたくさんあります。それらは識別子、電子メール、名前などです。
この特定のユースケースは、継承ではなく構成によってより適切に処理されます。つまり、「電子メールアドレスは文字列です」ではなく「電子メールアドレスには文字列表現があります」（電子メールアドレスは実際には複数の複合体であるため） SMTPを使用しているときに、たまたま簡潔な文字列表現を持つサブフィールド）。
もう1つのポイントは、文字列は基本的な型であることが意図されているということintです-から派生することは意味がありません-なぜ文字列なのですか？の実装Stringを拡張する場合（System.Stringたとえば、GetHashcode実装をオーバーライドする場合）にのみ派生する必要がありますが、オーバーライドする可能性のある操作の数は非常に限られているため、フレームワークのメンテナがサポートに煩わされる必要があるのはなぜですかそのシナリオ？
@Steveがコメントでリンクしているように、Eric Lippertによるこのブログ投稿ではsealed、特にメンテナンスPoVからの多くのクラスがなぜあるのかについても説明しています：https：//blogs.msdn.microsoft.com/ericlippert/2004/01/22/why-are -非常に多くのフレームワーククラス-封印された/
最後に、本当に独自の文字列動作が必要な場合（これは非常に可能です：長さ接頭辞付きの文字列、nullで終了する文字列、より大きな文字列バッファに定義された範囲として存在する文字列、リンクリストベースの文字列、Trie that複数の文字列をメモリ効率の高い方法で保持し、複数のアプローチのハイブリッドなど）独自の実装を最初から構築できますSystem.String。これらは、存在するために派生する必要はありません。確かに、文字列値を期待するクラスにそれを渡すことはできませんが、おそらくそれらのコンシューマーはの特定の実装動作System.String（ランタイムパフォーマンス、不変性など）に依存しているため、これは公正です。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加