我知道如何访问另一个脚本的变量，但我只能通过function calls 或delegates 访问。第一个很简单，但会使代码变得脆弱，因为一旦我编辑了原件，我必须再次编辑。
第二个更好，但由于我有很多函数，具有不同类型的返回值和参数，这会使事情复杂化很多。
假设我想在游戏开始时做一些事情。到目前为止，我在适当的脚本中创建了一个名为 OnGameStart() 的函数，并从那里调用了我需要的所有内容，并且将 OnGameStart() 设为 public 并从另一个脚本调用。
一开始我需要播放声音、检查保存数据、播放 UI 和其他动画等等，但我不想让我的代码成为灾难。 我在网上找了这个，但只找到了最简单的“如何在脚本之间通信”的东西，它与基本的函数调用，有时是事件一起使用。谁能指导我获取有关如何制作紧凑、隔离类以支持 Demeter's law 的资源？
【问题讨论】：
标签： c# design-patterns unity3d organization code-organization
解决此类问题肯定有很多可能性，例如，您可以从Hollywood principle 中获得一些灵感。
不要让您的Player 搜索某些东西，而是在初始化时将其提供给他。
这是一个非常简单的示例：
游戏管理器界面的定义：
using UnityEngine;
namespace Assets.Scripts
{
public interface IGameManager
{
void PlayAudioClip(AudioClip audioClip);
}
}
游戏管理员的定义：
using UnityEngine;
namespace Assets.Scripts
{
public class GameManager : MonoBehaviour, IGameManager
{
#region IGameManager Members
public void PlayAudioClip(AudioClip audioClip)
{
// TODO
}
#endregion
}
}
一个例子：
using System;
using UnityEngine;
namespace Assets.Scripts
{
public class Player : MonoBehaviour
{
public GameManager GameManager; // TODO assign this in Inspector
public void Start()
{
if (GameManager == null)
throw new InvalidOperationException("TODO");
}
public void Update()
{
// demo
var wounded = true;
var woundedAudioClip = new AudioClip();
if (wounded)
{
GameManager.PlayAudioClip(woundedAudioClip);
}
}
}
}
您也可以在 Unity 中使用 Singleton （或任何合适的）。
注意事项：
上面的例子实际上只是给你一个提示如何思考的例子，你还没有提供所有的细节，即使你提供了，我们也很难为你提供任何进一步的帮助（只有你会随着时间的推移找到真正适合你当前问题的东西）。
在您的游戏项目中推进时，您会发现没有要遵循的硬性规则，显然模式很重要，但您可能会发现自己以自己的方式结束（即多种模式的细粒度组合使用）。
结论是，发现/尝试模式，调整它们，随着时间的推移，您会发现最适合您的方法。
【讨论】：
static 的使用，继续阅读使用组合模式VS 使用static 的好处（如果两者之间可以进行任何比较的话）。在您的示例中，您输入了Player.Current，但如果您向后倾斜一点，您迟早会意识到这根本没有意义:)
GameObject.Find(...) 这样的行既慢又容易出错。要么存储对该游戏对象的静态引用，要么至少将其包装在某个静态属性中。
Singleton 作为MainGameManager 并处理来自那里的大部分呼叫。例如，对于非功能性逻辑，我有一个 UImanager，所以我有类似 2 个实际发生的脚本。我仔细阅读了答案和 cmets，肯定会有所收获。
GameManager 的类——这样的名字实际上注定要成为神类:) 即它需要什么来管理一些更恰当命名的类不能做的事情（例如处理播放背景音乐的BackgroundMusic 类，而不是出现在这个“管理器”类中的 PlayMusic 方法）。
当您需要广泛访问程序的某些子系统时，静态类非常有用，因此它们在游戏中被广泛使用。
/// <summary>Save/load is a good example because it
/// doesn't need any settings and it's
/// useful to call it from almost anywhere.</summary>
public static class GameSaver {
/// <summary>I save the game when I'm run.</summary>
public static void Save() {
// Save the game!
}
}
要使用静态类，您只需直接使用成员 - 例如GameSaver.Save(); 将在“任何地方”工作。属性、字段、事件等都可以设为静态，但请先查看以下注释。
这是避免某种"god class" 的最简单方法 - 这似乎是您所描述的（是的，它们通常是代码灾难！） - 这是一个类过于复杂，什么都做。将其分解为一系列小的、独立的模块。
为此使用单例。
特别是在游戏中，只有一次实例化的事物（例如播放器或音频系统）非常普遍，它们还需要易于重置或具有大量属性。
重要的是不要将它们全部作为静态字段 - 这将难以重置和调试。这就是您使用静态字段并实例化普通类的地方 - 这称为 singleton：
/// <summary>There's only ever one background music source!
/// It has instance properties though (i.e. an AudioSource)
/// so it works well as a singleton.</summary>
public class BackgroundMusic {
/// <summary>The static field - use the Play method from anywhere.</summary>
private static BackgroundMusic Current;
/// <summary>Plays the given clip.</summary>
public static void Play(AudioClip clip) {
if (Current == null) {
// It's not been setup yet - create it now:
Current = new BackgroundMusic();
}
// E.g. Current.Source.Play(clip);
}
public BackgroundMusic() {
// Instance a source now.
}
}
这只是意味着BackgroundMusic.Play(..); 可以在任何地方使用。这种方法意味着您无需在检查器中设置任何内容 - 只需调用该方法即可按需设置。
通常认为所有代码都必须是 MonoBehaviour 并且必须附加到游戏对象。这不是 Unity 的实际工作方式。当一切都是 MonoBehaviour 并且必须全部手动实例化和连接时，这只会为使用编辑器的人带来更多的工作。
要明确，我并不是说根本不要使用 MonoBehaviour。相反，您应该根据代码实际表示的内容来使用组件模型和静态的适当组合。
一般：
其中一个例子是玩家（在单人游戏中）具有一系列您希望更改的默认设置。您可以将播放器设置为预制件，并拥有某种引用当前实例的 PlayerSettings.Current 静态字段：
/// <summary>Add this to a player prefab.</summary>
public class PlayerSettings : MonoBehaviour{
/// <summary>Still following the singleton pattern.</summary>
public static PlayerSettings Current;
/// <summary>Player speed. This can be edited in the inspector.</summary>
public float Speed;
public void Awake() {
// Update the static field:
Current = this;
}
}
这种方法两全其美——您可以在任何地方使用PlayerSettings.Current（在播放器预制件被实例化之后），而不必放弃检查器。它也比GameObject.Find("Player/Body").GetComponent<PlayerSettings>(); 之类的东西更容易重构，使其更易于维护。
如果有多个实例的东西，比如 NPC，那么通常你总是会使用带有 MonoBehaviour 的预制件。但是，使用静态方法对以下情况非常有用：
public class NPC : MonoBehaviour{
/// <summary>Gets an NPC by their name.</summary>
public static NPC Locate(string name){
// E.g. get all GameObject instances with an NPC component.
// Return the first one which has a 'Name' value that matches.
}
/// <summary>The name of this NPC (editable in the inspector).
public string Name;
}
NPC.Locate("Dave"); 对于它的实际预期作用变得不言自明。
【讨论】：
static，它是邪恶的 :)