2016-07-01 13 views
2

私はasync/awaitを全く新しくしていて、2年前に書いた完全に同期したアプリケーションを「改良」してきました。私は私の解決策に不満を抱いている次のような状況があります。抽象クラスの子に対して静的コンストラクタを作成できますか?

XAMLは、以下の二つのクラスにバインドされています

XAML

private InsuranceEditor _primaryinsurance; 
public InsuranceEditor PrimaryInsurance 
{ 
     get { return _primaryinsurance; } 
     set { if (_primaryinsurance == value) return; _primaryinsurance = value; OnPropertyChanged("PrimaryInsurance"); } 
} 

private InsuranceEditor _secondaryinsurance; 
public InsuranceEditor SecondaryInsurance 
{ 
     get { return _secondaryinsurance; } 
     set { if (_secondaryinsurance == value) return; _secondaryinsurance = value; OnPropertyChanged("SecondaryInsurance"); } 
} 

クラス、PrimaryInsurance、およびSecondaryInsurance抽象クラスの保険継承:

abstract class InsuranceEditor : SimpleViewModelBase, ISave, IDataErrorInfo 
{ 
      ................. 
      // Constructor 
    public InsuranceEditor(PatientDemographicsEditor patient, Billing service) 
    { 
     ... 
    } 

Factoryパターンを使用しますプライマリインシュランスの非同期建設(Async OOP Constructor)

private async Task<PrimaryInsurance> InitializeAsync() 
{ 
    // asyncData = await GetDataAsync(); 
    return this; 
} 

public static Task<PrimaryInsurance> Create(PatientDemographicsEditor patient, Billing service) 
{ 
    var ret = new PrimaryInsurance(patient, service); 
    return ret.InitializeAsync(); 
} 

// Constructor 
private PrimaryInsurance(PatientDemographicsEditor patient, Billing service) 
    : base(patient, service) 
{ 
    Editor_Id = 1; 
    ........ 
} 

class SecondaryInsurance : InsuranceEditor 
{ 
    // Constructor 
    private SecondaryInsurance(PatientDemographicsEditor patient, Billing service) 
     : base(patient, service) 
    { 
     Editor_Id = 2; 
     ............................ 
    } 
} 

論理的には、プライマリとセカンダリの両方の保険は、Editor_Idでのみ異なるので、共通のInsuranceEditorを継承するのは当然のようです。この問題は現在、プライマリとセカンダリの保険にasync/awaitを「正しく」適用することによって得られます。私は、使用のようなものになりたい:(。必ずしも抽象クラスInsuranceEditorの静的メソッド)

Create(...)PrimaryInsuranceの静的メソッドとして認識されている

PrimaryInsurance = await PrimaryInsurance.Create(....)

をこれを行うことができますか?

編集#1。この質問を投稿した後、私はそれが既に質問されているかもしれないと思っている、What's the correct alternative to static method inheritance?と私はCで行うことができないことを#。これは正しいです?

編集#2:私はVSに持っています問題は、使用方法の説明文が付いています:

PrimaryInsurance =待つPrimaryInsurance.Create(患者、BILLING)。

VSは私にその指示:

メンバー 'InsuranceEditor.Create(PatientDemographicsEditor、課金)' インスタンス参照してアクセスすることができません。 PrimaryInsuranceではなく、代わりにタイプ 名前で

それを修飾し、私はVSが(エラーがないように)(...)を作成するために許可した場合、その後、それはabstact InsuranceEditorクラスでこれを作りますクラス。

internal Task<InsuranceEditor> Create(PatientDemographicsEditor patient, Billing bILLING) 
     { 
      throw new NotImplementedException(); 
     } 

私は間違っていますか?

+0

もしそれらがすべて異なるのであれば、なぜEditor_Idが1つのクラスを使用し、Editor_Idをプライベートコンストラクタのパラメータとして渡すのではないのですか?次に、あなたは 'InsuranceEditor.CreatePrimary(...)'または 'InsuranceEditor.CreateSecondary(...)'を待つだけです。 –

+0

@ScottChamberlainそれはまさに質問を書いた後に起こったことです。しかし、より難しい場合があるので、子クラスの静的なCreateを使用して継承をどのように使用できるかについてのアイデアを期待しています。 –

+2

私は本当にあなたの質問がこれであるか分かりません。あなたは "できますか"と尋ねますが、あなたの質問には実例があります。あなたの質問は何ですか? –

答えて

2

まだ問題を確実に再現する良いMinimal, Complete, and Verifiable code exampleを提供していません。しかし、プログラムの例文と引用したエラーメッセージに基づいて、識別子の名前があいまいなコンテキストでPrimaryInsuranceという識別子を使用しようとしているようです。

プロパティの名前を保持したい場合は、型名を使用したい場所であれば、完全に修飾する必要があります。たとえば、

PrimaryInsurance = await MyNamespace.PrimaryInsurance.Create(Patient, BILLING); 

ここで、MyNamespaceは実際の名前空間の種類と同じです。

名前空間が特に長い場合やその他の理由で毎回全体を入力する必要がない場合は、usingディレクティブを使用して型名の別名を付けることができます。たとえば:

using PrimaryInsuranceType = MyNamespace.PrimaryInsurance; 

は、その後、あなたのプログラム文は次のようになります。もちろん

PrimaryInsurance = await PrimaryInsuranceType.Create(Patient, BILLING); 

を、PrimaryInsuranceTypeは一例です。プロパティ名自体(またはクラス内の他のプロパティ名)と異なる限り、任意のエイリアス名を使用できます。

+0

それがそれでした。 –

+0

私は今、約100回、「最小、完全、そして....」と読みました。私は明らかにそれを得ていない(私はこの質問でそうしたと思った)。 「Minimal ....」の良い例が最も役立ちます。 –

+1

@Alan:[mcve]ページや[ask]ページよりも説明する方法がわかりません。私はあなたの質問がバーに会うのに失敗した方法を伝えることができます。投稿したコードを単にコピー/ペーストすることはできず、変更せずにコードをコンパイルして報告した問題を再現しようとします。 [ask]ページの最後にあるリンクの記事を必ず読んでください。http://sscce.org/を読むためのボーナスポイント(質問をするときに良いコード例を提供するための非常に重要な必要性を人々が理解できるようにするためのさらに別のリソース) –

関連する問題