これは、このケース - クラス対インターフェイスvs抽象にとって理にかなっていますか？

Question

データベースに「パッケージ」テーブルがあります。

Aパッケージは、3つのタイプとすることができる：パッケージA、パッケージB及びパッケージC.

すべての3つのパッケージが
1のようないくつかの一般的なフィールドを有する）名前
2）サイズ
3）重量

は今のユニークなフィールドに来る：

パッケージA & B含まれている必要があります -
a）のチャンネル

パッケージCが含まれている必要があります -
a）の完了

をだから、私は、データベース内の "パッケージ" と呼ばれるテーブルを作成します。 "パッケージ" の
列は次のようになります。

1）ID
2）タイプ（1 = PackageA、2 = PackageB、3 = PackageC）
3）名前
4）サイズ
5）重量
6）チャネル（パッケージCのために必要ではない）
6）完了（パッケージA & Bのために必要ではない）

だから、私は）プロパティのデータ型を無視する（以下のような抽象クラスを作成する：

public abstract class Package 
{ 
public id; 
public type; 
public name; 
public size;  
public weight; 
} 

public class PackageA : Package 
{ 
public channel; 
} 


public class PackageB : Package 
{ 
public channel; 
} 

public class PackageC : Package 
{ 
public completion; 
} 

このアプローチではどうしたらいいですか？ Packageクラスは抽象クラスか単純クラスか？
私は他の人が直接Packageクラスで作業するのではなく、代わりにパッケージA、B、Cを取ることを望みます。

EDIT：データベースの部分はどうですか？パッケージA & B（パッケージCでは不要）（パッケージA & Bには必要ありません）のようなフィールド/カラムを「null」を持つようにするのは一般的ですか？特定のパッケージタイプには必要ない/使用しないときは？

Answer 1

このアプローチで間違っているのは、PackageAとPackageBにまたがってchannelが複製されていることだけです。

public abstract class PackageWithChannel : Package { 
    public Channel Channel {get;set;} 
} 
public class PackageA : PackageWithChannel { 
    ... 
} 
public class PackageB : PackageWithChannel { 
    ... 
} 

これはChannelプロパティの重複を排除します。あなたはchannelを共有する2つのパッケージタイプのために別の基本クラスを追加することによって、それを修正することができます。

データベース部分については、属性値リストの単一のテーブルからタイプフィールドを持つ階層ごとのテーブルまで、クラス階層をRDBMSにマッピングする方法があります。あなたは階層ごとのテーブルを選択しましたが、これは完全に有効です。