質問のタイトルはそれを要約していると思います。ABCがデータメンバーを持つことは良い設計であると考えられる時期はありますか？これで大丈夫な状況があるのではないかと思っていました。私が思いつくことができるのは静的なものだけであり、それでもそれは一種のストレッチです。

私はVB.NETクラス（私が書いていない）を見ています.3つのメソッドがあり、 MustInherit（ C＃では）abstractと定義されています。クラスにはプロパティやフィールドはなく、3 つのメソッドだけです。オブジェクト指向の観点から、これは意味がありますか?Sharedstatic

それを作ることによってMustInherit、あなたは本質的にこのクラスのインスタンスを作成できないと言っているからです - あなたはそれから継承し、派生クラスのインスタンスを作成しなければなりません。しかし、すべてのメソッドが共有されているため、親クラスのインスタンスを実際に作成することは決してないため、は役に立ちMustInheritません。マークを付けずに、必要なときにいつでも継承することもMustInheritできます。

この方法でクラスを作成することが理にかなっている状況はありますか?

どちらに進むか決めるのに苦労しています...
このアプリケーションは、1 つの基本プロジェクトとアプリケーション用の 1 つのプロジェクトで構成されています。アプリケーション プロジェクトには、特定のシステム、システム アプリケーションを対象とするコードが含まれています。

基本プロジェクトは、各システム固有のアプリケーション プロジェクトが実装する抽象メソッドを含む抽象クラスです。
問題は、システム アプリケーション プロジェクトには顧客固有の調整が含まれる可能性があることであり、このコードをシステム アプリケーション アセンブリに入れたくありません。

システム アプリケーション アセンブリを書き直さずに顧客固有のコードを追加できるかどうか、どこから始めればよいか、または将来のために安全で維持しやすい方法でこれを達成する方法がわかりません。

基本プロジェクト (dll) を 1 つ、システムごとに 1 つのシステム アプリケーション プロジェクト (dll) を用意し、顧客固有の調整を 1 つの顧客固有のプロジェクト (dll) に入れるという考え方です。
Rob.Core.dll
Rob.Application.BigSystem.dll
Rob.Application.BigSystem.Customer.BigCompany.dll

Rob.Core.dllは基本抽象プロジェクトです。
Rob.Application.BigSystem.dllは、システム固有のプロジェクト ( BigSystem ) であり、Rob.Core.dllから派生します。
Rob.Application.BigSystem.dllは、現在の顧客であるBigCompanyに独自の調整があるかどうかを確認し、そうである場合は、メソッドのオーバーライドまたはオブジェクトの拡張、追加のフィールドを含む可能性があるRob.Application.BigSystem.Customer.BigCompany.dllアセンブリをロードします。等

さて、要約する時間です...
ここでどちらに進むべきかわかりません。1つの基本プロジェクト(要約)を作成し、各システムから特定のプロジェクトを派生させることができます。これが開始方法のようです。
次に、独自の調整セットを持つ顧客ごとに新しいプロジェクトを作成し、システム固有のプロジェクトのすべてのメソッドをオーバーライドします。
問題は、実行時に実行されるプロジェクトはどれかということです。システム固有のプロジェクトですか、それともお客様固有のプロジェクトですか?
システム固有のプロジェクトが実行される場合、すべての顧客調整をどのようにロードする必要がありますか (存在する場合、すべての顧客が固有の調整を取得するわけではありません)。

これは非常に大きな質問ですが、アーキテクチャを書くのに役立つヒントを期待しています。

よろしく
ロバート

Webサービス呼び出しのパラメーターとして抽象クラスを使用しています。現在、次のように、派生クラスのXmlIncludeを基本クラスに含めています。

ただし、基本クラスにすべての派生型を含めたくはありません。

http://www.pluralsight.com/community/blogs/craig/archive/2004/07/08/1580.aspxで、作成者は別の方法について言及しています。代わりに、次のようにWebメソッドの上に属性を記述します。

ただし、派生型もWebサービスに入れたくありません。派生型で属性を保持する方法はありますか？

PHPからC＃に移行しています。

PHPでは、抽象クラスを使用して「カスケードオーバーライド」パターンを作成するのは簡単で簡単でした。基本的に、「継承クラスに同じシグネチャを持つメソッドがない限り、基本クラスのメソッドがそれを処理します」。

ただし、C＃では、基本クラスと継承クラスでキーワードnew、virtual、abstract、overrideのさまざまな組み合わせを試して、この単純なカスケードオーバーライドパターンを実行する正しい組み合わせが最終的に得られるまで、約20分を費やしました。

したがって、以下のコードが私が望むように機能する場合でも、これらの追加されたキーワードは、C＃が抽象クラスではるかに多くのことを実行できることを示唆しています。これらのキーワードの例を調べて、基本的にそれらが何をするかを理解しましたが、この単純な「カスケードオーバーライド」パターン以外にそれらを使用する実際のシナリオを想像することはできません。日常のプログラミングでこれらのキーワードを実装する実際の方法は何ですか？

動作するコード：

問題: 複数のアセンブリ間でコードを共有したいと考えています。この共有コードは、LINQ to SQL マップ クラスで動作する必要があります。

ここで見つかったのと同じ問題に遭遇しましたが、厄介な回避策も見つけました (「バグ」とは言いません)。

以下のコードはすべて、このソリューションでダウンロードできます。

このテーブルを考えると：

およびこの DBML マッピング:

1 つのアセンブリ「共有」に次の基本クラスを作成しました。

これらのクラスは、次のように別のアセンブリ "Main" で参照されます。

DBML ファイルも「メイン」アセンブリにあります。

を呼び出すUser.FindByName_Broken(db, "test")と、例外がスローされます。

System.InvalidOperationException: クラス メンバー UserBase.Name がマップされていません。

ただし、他の 2 つの基本的な静的メソッドは機能します。

さらに、呼び出しによって生成される SQLUser.FindByName_Works(db, "test")は、壊れた呼び出しで期待していたものです。

単一の述語クエリにこの1 == 1「ハック」を使用しても構わないと思っていますが、ベース/共有/コア アセンブリで LINQ to SQL 対応コードを共有するより良い方法はありますか?

コンパイルしている抽象クラスが仮想デストラクタを必要としないことを gcc に伝える方法はありますか (COM オブジェクトには決してありません)。たとえば、nsISupports は常に仮想デストラクタの欠落について文句を言います。この警告が必要な場合、COM に似ていないクラスがある可能性があるため、警告をオフにしても役に立ちません。

そのため __attribute__((com_interface)) は廃止され、vtable レイアウトのみが変更されました。このクラスに欠落しているデストラクタについて警告されたくないことをコンパイラに伝えることができる別の __attribute__ はありますか?

PageItemsがモデル オブジェクトである WPF アプリケーションがあります。

私のメイン ViewModel にはPageItemViewModelsの ObservableCollection があり、それぞれが一致する PageItem モデル オブジェクトから構築されます。

各PageItemViewModelは、抽象クラスBaseViewModelから継承して、INotifyPropertyChanged 機能を取得します。

各PageItemViewModelは、必要なプロパティがあることを確認するためにIPageItemViewModelも実装します。

最終的には約 50 ページになるので、不要なコードを削除したいと思います。

• 解決済み(以下を参照) : PageItemViewModel クラスにIdCode と Title を継承させて、各クラスに実装する必要がないようにする方法はありますか? これらのプロパティを必要としない他のViewModelがそれを継承するため、BaseViewModelに配置することはできません。また、IPageItemViewModelに配置することはできません。これは単なるインターフェイスであるためです。これには C# がサポートしていない複数の継承が必要であることを理解しています
• 解決済み (以下を参照) : switchステートメントを取り除く方法はありますか。たとえば、代わりにリフレクションを使用するなどです。

以下は、 WPFアプリケーションにあるコードを示すスタンドアロンのコンソール アプリケーションです。

リファクタリング: インターフェイスを抽象クラスに変更

Switch ステートメントを削除するための回答:

ありがとうジャブ: