2016-07-18 6 views
0

私は、親クラスまたはインターフェースと、親から継承するか、インターフェースを実装する2つの子クラスを持っていて、親に共通のプロパティーを持っていますが、各子ごとに異なるプロパティーがあります。親クラス/インターフェース内のすべてのプロパティを収集するか、それらを分離する必要がありますか?親クラスの順応

abstract class Customer 
{ 
    string name { get; set; } 
} 

class GoldCustomer : Customer 
{ 
    string Address { get; set;} 
} 

class SilverCustomer : Customer 
{ 
    string Telephone { get; set;} 
} 

私はその後、それらを分離し、子を指している親からの参照を作成した場合、私は、分離子プロパティ

Customer c = new GoldCustomer(); 
c.Address // error 
より正確なアーキテクチャである

なくどんなデザインに違反にアクセスすることはできませんパターン?代わりに、継承を使用しての

abstract class Customer 
{ 
    string name { get; set; } 
    string Address { get; set;} 
    string Telephone { get; set;} 
} 

class GoldCustomer : Customer 
{ 

} 

class SilverCustomer : Customer 
{ 

} 


Customer c = new GoldCustomer(); 
c.Address = ""; 
+0

正確な状況によって異なります。 Liskov Substitution Principle(https://en.wikipedia.org/wiki/Liskov_substitution_principle)に違反する必要がないような方法でクラスを設計することが難しい場合は、継承(https:// en .wikipedia.org/wiki/Composition_over_inheritance) – itsme86

+0

これはあまりにも幅広い質問であり、itsme86が述べたように、それは特定の状況に依存します。両方のaproachesは正しいかもしれません、それは本当にあなたがしたいことに依存しています。あなたが実際に必要とするものを前もって考えてみて、あなたが不必要な依存関係を作っていないようにしてください。 – CrudaLilium

答えて

0

、私はおそらく、顧客のタイプのために別の連絡先情報を含むクラスの別のセットを選ぶだろう:私は@ itsme86 Aからのアプローチを変更します

public class Customer 
{ 
    public string Name { get; } 
    public ContactInfo ContactInfo { get; } 
    // Other common properties 
} 

public abstract class ContactInfo 
{ 
    public virtual string Address => ""; 
    public virtual string Telephone => ""; 
} 

public class GoldContactInfo : ContactInfo 
{ 
    public override string Address { get; } 
} 

public class SilverContactInfo : ContactInfo 
{ 
    public override string Telephone { get; } 
} 
1

少し、私は持っているように、AddressまたはTelephoneだけContactInfo特定のものに:

public class Customer<T> where T : IContactInfo 
{ 
    public string Name { get; } 
    public T ContactInfo { get; } 
} 

public interface IContactInfo 
{ } 

public class GoldContactInfo : IContactInfo 
{ 
    public string Address { get; } 
} 

public class SilverContactInfo : IContactInfo 
{ 
    public string Telephone { get; } 
} 

public class GoldCustomer : Customer<GoldContactInfo> 
{ 
    // Here does the GoldCustomer have a GoldContactInfo 
} 

public class SilverCustomer : Customer<SilverContactInfo> 
{ 
    // Here does the SilverCustomer have a SilverContactInfo 
} 
+0

さて、発信者が顧客の住所をどのように要求するのですか?もしあなたが 'if(typeof(T)== typeof(GoldContactInfo)'のようなものに落ちてしまうのではないでしょうか?別のトリックがない限り、それはあまりにも縛られているようです。 '' ContactInfo'型について何か知っておくべきクラスです。それは合成の全体のポイントです。 – itsme86

+0

@ itsme86まず第一に、タイプ 'T'は必要ではないと言ったことはありません。第二に、コンポジションには「顧客クラスがContactInfoクラスについて何も知る必要がないようにする」よりもはるかに多くの利点があると思います。"この5つの理由を参照してください。たとえば、http://javarevisited.blogspot.co.at/2013/06/why-favor-composition-over-inheritance-java-oops-design.html –

0

考えアボ継承とプロパティの場合、最も簡単な方法は、「is-a」と「has-a」という言葉で考えることです。

CustomerにはAddressがありますか? Telephoneはどうですか? 実際オブジェクトAddressプロパティが無関係である持っていることを

Customer c = new GoldCustomer(); 
c.Address = ""; // Customer does not have an Address property 

事実:一般Customerアドレスを持っていない場合は、次のようには意味がありません。変数Customerと宣言しているので、コンパイラはそれをそのように扱います。

すべてお客様が住所と電話番号をお持ちの場合、SilverCustomerは「通常の」顧客とどのような性質や行動をしていますか?レベルを示すCustmoerという属性も同様に簡単ですが、実際の使用状況によって異なります。