c# - 在 Unity 中建立组件之间关系的最佳做法是什么？

Question

当我尝试考虑 Unity 中的游戏架构时，我面临以下问题:在组件之间建立关系有多种方法，我无法理解哪种方法是最佳的。

例如，我们有具有以下参数的 GameplayObject 组件

public class GameplayObject : MonoBehaviour
{
    // every gameplay object has chanse of appear on board
    [SerializeField, Min(0)] int m_ChanseOfAppear = 0;

    public int ChanseOfAppear => m_ChanseOfAppear;

    //every gameplay object may be destroyed
    public virtual void Destroy()
    {

    }
}

销毁方法可以在用户输入后执行(点击或拖动只是输入的几种类型)或者另一个游戏对象可以执行销毁方法。 例如，我们有以下 TapBehaviour 组件

public class CustomDestroyer: MonoBehaviour, IPointerClickHandler
{    
    public event System.Action OnTap = delegate { };

    IPointerClickHandler.OnPointerClick()
    {
         OnTap();
    }
}

我们有具体的 GameplayObject(例如 CustomDestroyer)，它应该以具体的方式销毁对象。现在它需要我们的输入组件的依赖

[RequireComponent(typeof(TapBehaviour), typeof(BoxColiider2D))]
public class CustomDestroyer: GameplayObject 
{
    TapBehaviour m_TapBehaviour;
    TapBehaviour TapBehaviour
    {
        get
        {
            if (m_TapBehaviour == null)
                m_TapBehaviour = GetComponent<TapBehaviour>();
            return m_TapBehaviour;
        }
    }


    public override void Destroy()
    {

    }
}

但我们可以用相反的方式来做:从 TapBehaviour 继承 CustomDestroyer 并像组件一样使用 GameplayObject。

所以主要问题是您如何构建项目的架构？什么时候使用组件的继承，什么时候只使用组件？可能是我失去了一些更可取的方式？

你给我解释的越多，我就越感激你!

对不起，英语不好，只是学习。

Answer 1

Unity 在架构方面提供了很大的自由度，当您可以通过多种不同的方式成功地完成工作时，有时会让人不知所措。关于你的问题——就 future 的验证而言，我倾向于使用单独的组件(也就是单一责任)，使用接口(interface)松散地捆绑在一起(比如 IDestroy 而不是具体类型)，这个想法是尽可能避免组件的相互依赖。

但在很多情况下，带覆盖的继承会很好，并且重构通常是无痛的(如果你走得太远，有很多方法可以自动执行编辑器任务)所以我的建议是:不要使事情过于复杂，尽可能简单，但不要简单