Unity3d 在我自己的脚本和mono行为之间创建一个类是一个好的实践吗？

因此，我将

战斗控制器

绑定到一个名为“godObject”的对象。在

Start（）

方法中，我调用其他类上的

init（）

函数。我这样做是为了控制对象初始化的顺序，因为，例如，角色控制器依赖于正在初始化的网格控制器

快速示意图：

--------------------   calls 
| CombatController | ----------> CameraController.init(); 
--------------------      |
                          | ---> GridController.init();
                          |
                          | ---> CharacterController.init();

所以，现在我有一个小问题。我在每个控制器中都需要多个属性。目前，我已将一切绑定到战斗控制器本身。这意味着，在每个控制器中，我都必须通过

GameObject.Find（“godObject”）.GetComponent（）

获得CombatController的实例。老实说，我认为这不是一个好的设计

我现在的想法是创建一个扩展单行为的

BaseCombatController

，然后拥有所有其他类，如

GridController

，

CharacterController

等。扩展

BaseCombatController

。它可能如下所示：

public class BaseCombatController : MonoBehaviour
{
    public GameObject activePlayer;

    public void setActivePlayer(GameObject player) {
        this.activePlayer = player;
    }

    ... more stuff to come ...
}

这样，我就可以随时随地访问

activePlayer

，而无需创建

CombatController

的新实例。但是，我不确定这是否有可能的副作用

---

因此，一个简单的问题有很多文本，这样做安全吗？

据我所知，这应该是安全的。如果你查看Unity intern甚至Microsoft脚本，它们都会相互扩展/插入

---

你可以尝试的另一件事是使用接口，这里是Unity文档：如果你想查看它。

据我所知，这应该是安全的。如果你查看Unity intern甚至Microsoft脚本，它们都会相互扩展/插入

---

您可以尝试的另一件事是使用接口，下面是Unity文档：如果您想查看它。

我一直在Unity中使用继承。就像您在问题中遇到的一样，诀窍是允许基类从monobehavior继承。例如：

public class Base Item : Monobehavior 
{
   public string ItemName;
   public int Price;
   public virtual void PickUp(){//pickup logic}
   //Additional functions. Update etc. Make them virtual.
}

这个类设置一个项应该做什么。然后在一个派生类中你可以改变和扩展这个行为

public class Coin : BaseItem
{
    //properties set in the inspector
    public override void PickUp(){//override pickup logic}
}

在过去的一年里，我经常使用这种设计模式，目前正在零售产品中使用。我想说，去吧！Unity似乎更喜欢组件而不是继承，但您可以轻松地将它们结合使用

---

希望这会有所帮助！

我一直在Unity中使用继承。就像您在问题中遇到的一样，诀窍是允许基类从monobehavior继承。例如：

public class Base Item : Monobehavior 
{
   public string ItemName;
   public int Price;
   public virtual void PickUp(){//pickup logic}
   //Additional functions. Update etc. Make them virtual.
}

这个类设置一个项应该做什么。然后在一个派生类中你可以改变和扩展这个行为

public class Coin : BaseItem
{
    //properties set in the inspector
    public override void PickUp(){//override pickup logic}
}

在过去的一年里，我经常使用这种设计模式，目前正在零售产品中使用。我想说，去吧！Unity似乎更喜欢组件而不是继承，但您可以轻松地将它们结合使用

---

希望这有帮助！

你说得对，游戏对象。查找纯粹是代码气味

您可以通过继承树（如前面所讨论的）或者更好地通过接口（如Assasin Bot所提到的），或者（我很惊讶前面没有人提到）通过静态字段（也称为单例模式）来实现

从经验中可以补充一点——必须以特定的顺序调用Inits（），这对您的设计来说是一个黄旗——我自己也经历过，发现自己被init顺序管理淹没了

作为一般建议：Unity提供了两个有用的回调函数-Awake（）和Start（）。如果您发现自己需要Init（），则可能没有按照设计使用这两个函数

所有Awakes（）都保证（对于acvie对象）在first Start（）之前运行，因此在Awake（）中进行所有内部对象初始化，并在Start（）上绑定到外部对象。如果您发现自己需要更好的控制，您可能应该简化设计

---

作为经验法则：所有对象在Awake（）结束时都应该有其内部状态（getcomponents、list inits等），但它们不应该根据其他对象在开始（）之前准备好的情况进行任何调用。以这种方式拆分它通常会有很大帮助

你是对的游戏对象。查找纯粹是代码味道

您可以通过继承树（如前面所讨论的）或者更好地通过接口（如Assasin Bot所提到的），或者（我很惊讶前面没有人提到）通过静态字段（也称为单例模式）来实现

从经验中可以补充一点——必须以特定的顺序调用Inits（），这对您的设计来说是一个黄旗——我自己也经历过，发现自己被init顺序管理淹没了

作为一般建议：Unity提供了两个有用的回调函数-Awake（）和Start（）。如果您发现自己需要Init（），则可能没有按照设计使用这两个函数

所有Awakes（）都保证（对于acvie对象）在first Start（）之前运行，因此在Awake（）中进行所有内部对象初始化，并在Start（）上绑定到外部对象。如果您发现自己需要更好的控制，您可能应该简化设计

---

根据经验法则：所有对象在Awake（）结束时都应该有其内部状态（getcomponents、list inits等），但根据其他对象在Start（）之前准备就绪的情况，它们不应该进行任何调用.以这种方式拆分通常会有很大帮助

很好，很高兴知道。我不太确定这是否会导致问题。非常感谢！需要注意的是，不要将所有的单行为魔法函数都给父类，除非你绝对需要它们，因为调用这些方法的开销。拥有它们会更好e只有一个单一行为，但对某些人来说很难做出改变。同意。单一行为“神奇函数”调用引擎，它们有大量开销。理想情况下，你应该