円ジェネリック型パラメータ

Question

私はBaseComponentクラスとBaseManagerクラスの2つのジェネリッククラスを持っています。

これらはいずれも抽象的なものであり、具体的に意図されています。

public abstract class BaseManager<T> where T : BaseComponent<?> 
public abstract class BaseComponent<T> where T : BaseManager<?> 

BaseManager私はそれが一般的なようにしたい理由である、BaseComponentsのリストを持っているので、PhysicsManager : BaseManager<PhysicsComponent>はPhysicsComponentsのリストを持っているでしょう。

私はBaseComponentから派生したクラスを適切なマネージャーに欲しいと思っているだけなので、BaseComponentが一般的であることを望みたいです。理想的には、派生コンポーネントごとにコンストラクタを書く必要がないので、渡された具象マネージャクラスにコンストラクタを追加することができます。理想的には、私は、抽象的なBaseManagerクラスを取るコンストラクタをしたいです。

どのようにこの種の循環依存性を管理できますか？

Answer 1

は、それはあなたが2つのジェネリック型パラメータを持っている場合がありますように聞こえる：

public abstract class BaseManager<TComponent, TManager> 
    where TComponent : BaseComponent<TComponent, TManager> 
    where TManager : BaseManager<TComponent, TManager> 
public abstract class BaseComponent<TComponent, TManager> 
    where TComponent : BaseComponent<TComponent, TManager> 
    where TManager : BaseManager<TComponent, TManager> 

はい、それは臭いだ - しかし、それは私がProtocol Buffersにやった事のようなものです。

だから、あなたが持っているだろう：コンポーネントは上司について知らなかった場合

public class PhysicsManager : BaseManager<PhysicsComponent, PhysicsManager> 

public class PhysicsComponent : BaseComponent<PhysicsComponent, PhysicsManager> 

Answer 2

最も緩いカップリングは次のようになります。これがどのように機能するかの例があります。この方法では、すべてのコンポーネントをマネージャに追加する必要がある場合は、何らかのファクトリメカニズムが必要であることに注意してください。 （ナット・プライス - "If a relationship exists between two objects, some other object should establish the relationship."）

abstract class BaseComponent 
{ 
    public event EventHandler SomethingHappened; 
} 

abstract class BaseManager<TComponent> where TComponent : BaseComponent 
{ 
    List<TComponent> components = new List<TComponent>(); 

    public virtual void AddComponent(TComponent component) 
    { 
     components.Add(component); 
     component.SomethingHappened += (s, e) => OnSomethingHappened(component); 
    } 

    public abstract void OnSomethingHappened(TComponent component); 
} 

コンポーネントがその経営者から独立していることができない場合、私は彼らがコンポーネントの必要性によって定義されたインタフェースに依存することは良いことだと思います。これは、欠点は、型システムが正しいマネージャが渡され、そしてBaseManagerでキャストがその後、失敗することを強制しないことですInterface Segregation Principle

interface IManager 
{ 
    void ManageMe(BaseComponent component); 
} 

abstract class BaseComponent 
{ 
    public BaseComponent(IManager manager) 
    { 
     manager.ManageMe(this); 
    } 
} 

abstract class BaseManager<TComponent> : IManager where TComponent : BaseComponent 
{ 
    void IManager.ManageMe(BaseComponent component) 
    { 
     ManageMe((TComponent)component); 
    } 

    protected abstract void ManageMe(TComponent component); 
} 

interface IPhysicsManager : IManager 
{ 
    void AnotherCallback(PhysicsComponent comp); 
} 

abstract class PhysicsComponent : BaseComponent 
{ 
    public PhysicsComponent(IPhysicsManager manager) 
     : base(manager) 
    { 
     manager.AnotherCallback(this); 
    } 
} 

abstract class PhysicsManager : BaseManager<PhysicsComponent>, IPhysicsManager 
{ 
    protected override void ManageMe(PhysicsComponent component) 
    { 
     throw new NotImplementedException(); 
    } 

    public void AnotherCallback(PhysicsComponent comp) 
    { 
     throw new NotImplementedException(); 
    } 
} 

です。私はまだこの方法を好み、私の具体的なコンポーネントとマネージャをすべて汚染する円形のテンプレートを用意するのではなく、 "インフラストラクチャに匂いを残す"