8

カテゴリ/ファイルツリー構造があります。カテゴリとファイルの両方に親を含めることができるため、Parentプロパティを持つ共通の基本クラスからそれらを派生させました。すべての親は明らかに常にカテゴリになるため（ファイルを親にすることはできません）、ノードのParentプロパティをCategoryNodeタイプにするのは理にかなっているようです。

基本クラスが派生クラスを参照するのは悪い形式ですか？もしそうなら、なぜですか？もしそうなら、これを構造化するためのより良い方法は何ですか？

class Node {
    public CategoryNode Parent {get; set;}
}

class File : Node {
    ...
}

class CategoryNode : Node {
    ...
}
4

4 に答える 4

7

あなたができる...

interface IParent {
    ...
}

class Node {
    public IParent Parent {get; set;}
}

class File : Node {
    ...
}

class CategoryNode : Node, IParent {
    ...
}

このように、基本クラスの派生オブジェクトを参照する必要はありません。さらに、後で追加のオブジェクトタイプを取得した場合に備えて、実際に親になることができるものをより柔軟に設定できます。また、親にのみ関連する機能は、そのインターフェイスで宣言できます。

于 2012-07-03T07:40:05.530 に答える
4

プロパティParentが実際にはすべての子孫に共通のプロパティであり、常に種類がCategoryNodeである場合、問題はありません。意味論的に言えば、それは正しく、技術的には、同じライブラリにとどまるとすぐに（循環参照を避けるために）正しくなると思います。

これは、次のようなコードを作成するときに問題になる可能性があります。

// BAD CODE
if(myProp is subclassA) 
{ ... 
} 
else if (myProp is syubclassB) 
{ ...
}

継承の利点が失われるため、このコードは不適切です。

.Net Frameworkにも、そのような構造があります。私の頭に浮かぶ最初の例は、XObject.Parentプロパティです。

XElementはXObjectを継承し、XObjectはタイプXElementのプロパティを公開します。スニペットと同じです。

于 2012-07-03T07:36:41.370 に答える
1

その他のオプションは、クラス階層を変更してCategoryNodeをルートクラスにするか（a）、プロパティタイプをノードに変更する（b）ことです。

これらの可能性はどちらも良くありません。（a）ファイルにはCategoryNodeが必要としないすべての機能があります。（b）オブジェクトタイプ（常にCategoryNode）を非表示にします。これは、コード内のどこかで無効なキャストエラーが発生する可能性があります。たとえば、CategoryNodeインスタンスが常に存在することを忘れた場合です。

これを考えると、現在のコードは問題ないと思います。

于 2012-07-03T07:38:32.587 に答える
1

基本クラスは、誰がそれから派生したかを知る必要はありません。

そのような場合は、おそらく継承を望まないでしょう。何らかの形のカップリングを使用する必要があります。

FileとCategoryNodeは、あなたの場合、Nodeメンバーを保持する必要があります。

于 2012-07-03T07:36:15.347 に答える