thông số chung loại tròn

Question

Tôi có 2 lớp chung, một Lớp BaseComponent và lớp BaseManager.

Cả hai đều trừu tượng và được dự định sẽ được làm cụ thể.

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

BaseManager có một danh sách các BaseComponents, đó là lý do tôi muốn làm cho nó chung chung, do đó, một PhysicsManager : BaseManager<PhysicsComponent> sẽ có một danh sách PhysicsComponents.

Tôi muốn (hoặc đúng hơn, nghĩ rằng tôi cần) BaseComponent là chung chung vì tôi chỉ muốn các lớp học bắt nguồn từ BaseComponent để được 'đính kèm' với người quản lý phù hợp của họ. Lý tưởng nhất là tôi không muốn phải viết một hàm tạo cho mỗi thành phần dẫn xuất chỉ vì vậy tôi có thể thêm nó vào một lớp quản lý cụ thể được truyền vào. Lý tưởng nhất là tôi muốn có một nhà xây dựng có lớp trừu tượng BaseManager.

Tôi làm cách nào để quản lý loại phụ thuộc vòng tròn này?

Answer 1

Có vẻ như bạn có thể muốn có hai tham số kiểu chung chung:

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> 

Vâng, nó có mùi - nhưng đó là loại điều tôi đã thực hiện trong Protocol Buffers.

Vì vậy, sau đó bạn sẽ phải:

public class PhysicsManager : BaseManager<PhysicsComponent, PhysicsManager> 

public class PhysicsComponent : BaseComponent<PhysicsComponent, PhysicsManager> 

Answer 2

Các khớp nối loosest sẽ là nếu thành phần không biết về các nhà quản lý của họ. Đây là một ví dụ về cách thức đó sẽ làm việc. Lưu ý rằng phương pháp này đòi hỏi một số loại cơ chế nhà máy nếu tất cả các thành phần phải được thêm vào một người quản lý. (Nat Pryce - "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); 
} 

Nếu thành phần không thể không phụ thuộc vào các nhà quản lý của họ, tôi nghĩ rằng nó sẽ tốt hơn mà chúng phụ thuộc vào một giao diện được định nghĩa bởi nhu cầu của các thành phần. Đây là 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(); 
    } 
} 

Nhược điểm là hệ thống kiểu không thi hành mà người quản lý chính xác vượt qua, và các diễn viên trong BaseManager sau đó sẽ thất bại. Tôi vẫn thích cách này và "giữ mùi trong cơ sở hạ tầng của tôi" thay vì có các mẫu tròn gây ô nhiễm tất cả các thành phần và quản lý cụ thể của tôi.