問題タブ [sealed]

これはおそらくコードで説明するのが最も簡単です（これはもちろん実際のコードではありませんが、同じプロパティを持っています）：

私は次のようなインターフェースを持っています：

そして、これには次のような実装があります。

これらの呼び出しの1つで、GetFoo1が非常に重いため、古いバージョンのインスタンスを使用して呼び出しがキャッシュされる新しいバージョンのインターフェイスを提供したいとします。

私は今このようにやっています：

これには（少なくとも）2つの問題があります。

• 誰かがインターフェイスにメソッドを追加するたびに、この新しいメソッドをキャッシュしたくない場合でも、これを変更する必要があります
• 基礎となる実装を呼び出すだけの役に立たないコードのこの膨大なリストを取得します。

誰かがこれらの問題を抱えていないこれを行う方法を考えることができますか？

簡単な質問ですが、グーグルには答えがありません！SilverlightのPasswordBoxが封印され
ているため、今日は壁にぶつかっています。なぜ彼らがそうするのか私には分かりません。誰かがそれについて考えを持っていますか？

いくつかの場所で（たとえば、MSDNの「 JavaScript用のWindowsランタイムコンポーネントの作成、C＃およびVisual Basicで」）、JavaScriptから使用するクラスを.NETで作成する場合は、封印されたクラスにします。

これは恣意的な制限のようです。JavaScriptが封印されたクラスでのみ機能するのはなぜですか？

未知の 2 つの「キーワード」を使用する (おそらく) C++ コードを見たことがあります (キーワードを想定していますが、コンテキストがないため、それらは単純な#defineものである可能性があります)。

また、少なくとも私が持っているドラフトでは C++11 標準には表示されないようですが、それはかなり遅いドラフトであるため、土壇場で標準にドロップされるとは想像できません。refとですsealed。

私が見つけたコードは次のようなものでした：

これらのキーワードが何であるか、またそれらが何を達成することを意図しているか知っている人はいますか?

私は公共の建設業者がいるベースクラスを持っています。

基本クラスは封印されておらず、抽象的でもありません。

封印したいコンストラクターが1つあります。これは可能ですか？

私の現在の試みでは、コンストラクターを封印できないという構文エラーが発生します。

追加：

基本クラスを直接インスタンス化し、封印されたコンストラクターにアクセスできるようにしたいと思います。派生クラスは、派生コンストラクターを介してそのコンストラクターを使用できません。例えば

一般的な抽象ツリー型が必要で、それを特殊化して特定の型のツリーを作成したいとします。たとえば、私は持っているかもしれません:

ここで、各クラスに「タイプ」フィールドを追加する特定のバージョンが必要です。それでは特徴を紹介しましょうTyped。

この特性を持つ 3 つのクラス AST、BranchAST、および LeafAST の特殊なバージョンを定義するにはどうすればよいですか?

最初の試み。Scala の型メンバー機能を使用します。型メンバーは何かのメンバーでなければならないため、オブジェクト定義

これにより、「タイプ TypedAST を含む不正な循環参照」というエラーが発生します。

二度目の試み。今回は新しいファイルを起動して入れます

しかしもちろん、TypedAST は別のファイルで定義されているシール クラス AST を拡張するため、「シール クラス AST からの不正な継承」というエラーが発生します。とにかく AST から継承したいわけではありません。私がやりたいのは、AST を特殊化することです。継承はあくまでも手段です。(ちなみに、シールされたトレイトがここで必要なものかどうかはよくわかりません。クラスではなくトレイトにした理由は、TypedLeafAST が TypedAST と LeafAST の両方を拡張する必要があるためです。)

Scala 2.9.1 と 2.9.2 の両方を使用しています。

IntelliJアイデアを使用してjarファイルをどのように封印できますか？

jar cmfコマンドで作成されていると思いますが、IntelliJでどのように実現できますか？

シングルトン クラスを実装しましたが、作成中のメソッドが「seal クラスで宣言された新しい保護されたメンバー」であるという警告が表示され続けます。ビルドには影響しませんが、後で問題が発生した場合に備えて警告を無視したくありませんか? シールされたクラスは継承できないクラスであることを理解しています-そのため、メソッドをオーバーライドすることはできませんが、次のコードで警告が表示される理由はまだわかりません(シングルトン設計の使用によるものですか?):

編集: 警告は MethodName() メソッドに関するものです。編集: public void MethodName() を protected void MethodName() に変更します

「メンバーのチェック」では、おそらく基本クラスのC ++ 11バージョンで、C++でも機能する継承されたメンバー関数をチェックするためにSFINAEからC++11バージョンの従来のメンバーチェックタイプ特性を開発しました。 11finalクラスですが、C ++ 11機能（つまり、decltype）も使用します。

MSVCは、VS2005以降に名前がfinal付けられた非標準の拡張機能として使用されていますが、VS2010でのみ追加されています。そのため、VS2005と2008では、マークされたクラスが従来の型特性を破り、C++11バージョンを使用できなくなります。sealeddecltypesealed

それで、has_resize_methodVC2005 / 08sealedクラスでも機能するように定式化する方法はありますか？

明らかに、C++11のみの機能を使用してC++11のみの問題（）を回避するのと同じように、VSのみの拡張機能を使用してクラスfinalのVS2005/08のみの問題を回避しますがsealed3セットのコンパイラ{C++11、{VS2005、VS2008}、その他すべて}で機能するソリューションがあるとしたら、それはすばらしいことですが、多分多すぎて要求できません:)

「修正された 'sealed' はこのアイテムには無効です」

インターフェイスが継承可能でなければならないことは、いくつかの点で理解できます。そうでなければ、クラスはそれを実装できません。

しかし、インターフェイスにサブ インターフェイスを定義しないように指定できないのはなぜsealedですか。

編集

なぜこれが必要なのかを説明するために、いくらかの努力を払うべきでした。開発者が代わりに構成を使用する必要があるインターフェイス継承チェーンをよく見かけます。Sealed はクラスでこれに理想的であり、インターフェイスに同じことを強制する方法があるかどうか疑問に思いました。私の意見では、不必要な継承により、リファクタリングと保守が難しくなります。

編集 2

コメントや投稿を反映して、インターフェイスの継承ツリーは、オブジェクトの継承ツリーほど複雑ではありません。別のインターフェースから派生している場合と同様に、IX「実装する必要がある」と言っているだけですIX。そして、それを防止しても何のメリットもありません。