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方面的经验，您应该确切地知道您想做什么以及将来可能的实现，然后找到一种实现方式，并且这不会限制您将来的实现。

在Unity中没有一种关联事物的方法，这是其易用性的一部分。每个人最终都会按照自己的方式做事。

尝试找到一种兼顾可读性和效率的解决方案，并坚持使用通常总体上更好的最新组件。

编辑：忘记说了，如果您是一名代码专家，请不要滥用脚本的功能，因为统一性是为避免代码而设计的。与编写代码相比，UI有很多选择，就像魔术一样。

Answer 2

Unity在架构方面提供了极大的自由度，当您能够以多种可以成功使用的方式成功完成工作时，Unity有时会不堪重负。关于您的问题-就将来的证明而言，我倾向于使用单独的组件（也称为单一职责），使用接口（例如IDestroy而不是具体类型）将它们松散地绑在一起，其想法是在可能的情况下避免组件的相互依赖性。 / p>

但是在很多情况下，带有覆盖的继承会很好，并且重构通常很容易（如果您走过一条巷子，有很多方法可以自动执行编辑器任务），所以我的建议是：不要使事情变得过于复杂，请尽可能简单，但不要简单

在Unity中建立组件之间关系的良好实践是什么？

2 个答案: