3

エンティティの組織階層構造をモデル化する必要があります。組織は、本社、地域ヘッド、サブ地域、エリア オフィスのいずれかです。組織が実行している一般的な機能はたくさんありますが、特定の機能がいくつかあります。たとえば、地域だけがタスク A を実行できます。地域に固有のプロパティ (データ) もあります。

継承を使用せずに構成を使用してモデル化しましたが、組織のタイプに応じて有効な参照を持つかnullになる可能性のある多くの参照を持つ、単一の組織クラスだけで終了しました。

オブジェクトの構成は苦痛でしたが、現在は工場で処理しています。しかし今、私の主な関心事は、開発者が組織の種類とは何か、およびプロパティがその組織にとって何らかの意味を持っているかどうかを覚えておく必要があるということです。

私が言いたいことを明確にするために。

    public class Organization : IKeyed<int> {
        public virtual int Id { get; protected set; }
        public virtual string Code { get; set; }
        public virtual OrganizationType orgType {get;set;}
        public virtual Organization Parent {get;set;}
        public virtual IList<Organization> Children {get;set;}

        public virtual typeA {get; set;} // only meaningful when organization type is 'Head office'

        public virtual typeB {get;set;}// only meaningful when 'Region'
        public virtual void AddChild(Organization org){...}
    ...

    }

ここで継承を使用する必要がありましたか? それとも、ここでいくつかのトリックが欠けていますか?

4

2 に答える 2

6

私の意見では、共通の動作とフィールドを保持する抽象基本クラスを作成することをお勧めします。次に、サブクラスを追加して、より具体的な動作やプロパティを拡張できます。

public abstract class Organization : IKeyed<int> { 
    public virtual int Id { get; protected set; } 
    public virtual string Code { get; set; }

    // remove this property
    // public virtual OrganizationType orgType {get;set;} 
    public virtual Organization Parent {get;set;} 
    public virtual IList<Organization> Children {get;set;} 

    // move this property to sub-class
    // public virtual typeA {get; set;} // only meaningful when organization type is 'Head office' 

    // move this property to sub-class
    // public virtual typeB {get;set;}// only meaningful when 'Region'

    public virtual void AddChild(Organization org){...} 
    ... 

}

public class HeadOffice : Organization
{
    public virtual typeA { get; set; }
}

public class Region : Organization
{
    public virtual typeB { get; set;}
}

public class OtherOrganizationType : Organization
{
    // 
}
于 2012-10-15T06:47:42.940 に答える
1

In regards to your specific question inheritance vs. composition: The maxim i've heard over and over again is "use inheritance when object A is a type of object B. Use composition when object A is made up of object B".

In this case, you can't say that a regional office is a type of head office. Nor can you say that a head office is made up of regional offices. This tells me that the objects should not be directly related. Instead, think about what it is about each that makes them eligable to perform common tasks. Maybe they can both HireWorker because they are both HiringOrganizations, maybe they can both ReportSales because they are both SalesEntities. In these cases, you should have a HiringOrginization or SalesEntity superclass, of which both HeadOffice and RegionalOffice are subclasses.

As far as org structure goes, it might be worth considering to maintain that structure in a separate OrgStructure object. Instead of having a Parent attribute and a Child attribute in each object, your OrgStructure object would maintain the relationships between all of the object instances. This provides a bit more flexibility, and removes the responsibility of maintaining relationships into a dedicated object.

于 2012-10-16T19:53:20.247 に答える