这篇文章主要介绍一下各类代码的设计模式。在 GoF 的《设计模式:可复用面向对象软件的基础》一书中,作者介绍了一共 23 种设计模式。其中,在 Unity 中得到非常广泛和大量使用的模式在这篇笔记里主要写单例模式、观察者模式和工厂模式。
单例模式 Singleton Pattern
单例模式指的是当一个类在场景中只有一个实例时,我们可以给它提供一个全局访问点。常用的情况是各类 Manager。下面是一个 GameManager Singleton 的常规单例模式写法:
public class GameManager : MonoBehaviour
{
// private singleton
private static GameManager _instance;
// public singleton for others to get;
public static GameManager Instance
{
get
{
if (_instance == null)
{
_instance = FindObjectOfType<GameManager>();
if (_instance == null)
{
_instance = new GameObject("Spawned GameManager", typeof(GameManager)).GetComponent<GameManager>();
}
}
return _instance;
}
}
private void Awake()
{
// since we are using the Singleton pattern, we should always assume that we only have the current instance in this scene
if (_instance != null && _instance != this)
{
// if another instance is found, we destroy it;
Destroy(this.gameObject);
}
else
{
_instance = this;
DontDestroyOnLoad(this.gameObject);
}
}
public void SomeFunction() {
// ... some implementation ...
return;
}
}
此后,我们就可以在其它 C# 脚本中,以
GameManager.Instance.SomeFunction();
来调用 GameManager 中的 public 函数和变量了,而不再需要去单独地设置一个 SerializedField 或是查找当前场景的 GameManager instance。
单例模式的优势
控制实例数量:单例模式确保了一个类在应用程序的生命周期内只有一个实例。
全局访问点:单例实例可以全局访问,因此在应用程序任何地方都可以访问,不再需要重复创建对象或通过参数传递对象;
保存状态:单例可以在应用程序的生命周期保持状态。这对于存储跨多个系统或组件共享的数据非常有用,例如配置数据、缓存、日志记录等。
减少资源消耗:因为不再需要创建大量的对象(或销毁),所以可以减少 GC 的调用。
统一资源管理:当你有一个需要在多个地方使用的共享资源时(例如数据库连接或文件系统的访问),单例可以提供一个统一的点来管理这些资源,确保资源的使用是同步和一致的。
延迟初始化:单例可以实现延迟初始化(Lazy Initialization),即直到真正需要使用对象时才创建它。这有助于减少应用程序启动时间和资源消耗。
单例模式的问题
虽然单例模式有很多优点,但也需要注意其潜在的问题。例如,它可能引入全局状态的问题,这可能导致代码难以测试和维护。此外,如果不正确使用,单例可能导致资源同步问题,特别是在多线程环境中。
在使用单例模式时,需要权衡其带来的便利性和潜在的风险,并在适当的场景中谨慎使用。
观察者模式 Observer Pattern
观察者模式定义对象间的一种一对多的依赖关系,当一个对象/被观察者(Subject)的状态改变时,所有依赖于它的观察者(Observers)都得到通知并被自动更新。
当被观察者的改变会需要改变其它的对象,同时,被观察者并不知道有多少观察者正在观察自己时,我们就会使用观察者模式。
下面是观察者模式的常规写法。
// 观察者接口
public interface IObserver
{
void Update();
}
// 被观察者接口
public interface ISubject
{
// 注册新的 Observer
void RegisterObserver(IObserver observer);
// 移除已有的 Observer
void RemoveObserver(IObserver observer);
// 通知目前所有的 Observer
void NotifyObservers();
}
// 具体主体
public class ConcreteSubject : ISubject
{
private List<IObserver> observers = new List<IObserver>();
private float someState;
public void RegisterObserver(IObserver observer)
{
observers.Add(observer);
}
public void RemoveObserver(IObserver observer)
{
observers.Remove(observer);
}
public void NotifyObservers()
{
foreach (var observer in observers)
{
observer.Update();
}
}
public void ChangeState(float state)
{
someState = state;
NotifyObservers();
}
}
// 具体观察者
public class ConcreteObserver : IObserver
{
private ConcreteSubject subject;
private float observerState;
public ConcreteObserver(ConcreteSubject subject)
{
this.subject = subject;
this.subject.RegisterObserver(this);
}
// 更新操作
public void Update()
{
observerState = subject.SomeState;
}
}
在这里,我们正好对比一下 interface / struct / class 的区别。
Interface 接口
定义:接口是一种规范或合同,它定义了一组方法和属性,但不提供实现。接口只声明成员,不包含成员的实现。
用途:用于定义对象应具有的方法和属性,但不实现这些方法。它允许不相关的类实现相同的接口并被以同样的方式处理。
特性:
不能包含数据字段。
可以包含方法、属性、索引器、事件的声明。
接口成员默认是公开的(public)。
一个类可以实现多个接口。
接口支持多重继承。
Struct 结构体
定义:结构体是一种值类型,用于封装小的、轻量级的对象。
用途:适合用于表示数据结构,如坐标点(Point),颜色(Color)等。
特性:
是值类型,在栈上分配内存。
不支持继承,但可以实现接口。
结构体成员可以是数据、方法、事件等。
结构体可以有构造函数,但不能有默认的无参构造函数。
结构体比类更轻量,适用于小型对象。
复制结构体时,会创建其副本。
Class 类
定义:类是一种引用类型,用于创建对象的模板。
用途:用于封装数据和行为,是面向对象编程的基础。
特性:
是引用类型,在堆上分配内存。
支持继承,一个类只能继承自另一个类。
类成员可以是数据、方法、构造函数、事件等。
类可以有多个构造函数。
复制类对象时,只复制引用。
类可以被声明为 abstract(抽象类)或 sealed(密封类)。
抽象类 abstract class:
定义
抽象类是一种不能被实例化的类。它通常作为基类,定义和部分实现通用的功能,但也包含至少一个抽象方法。这些抽象方法必须在派生类中被实现。
特点
抽象类不能被直接实例化。
抽象类可以包含抽象方法和具体方法。
抽象方法是没有实现的方法,只有声明。
任何继承抽象类的子类必须实现其所有抽象方法,除非子类也是抽象的。
抽象类通常用于提供一个基本框架,以便由子类进行扩展和实现。
密封类 sealed class:
定义
密封类是一种不能被继承的类。换句话说,其他类不能派生自一个密封类。这通常用于安全性和性能优化。
特点
一旦类被声明为密封的,它不能被继承。
密封类可以实例化和使用,就像普通类一样。
密封类主要用于防止进一步的继承,特别是在设计框架或库时,以确保核心功能不被修改。
在某些情况下,密封类可以提高运行时的性能,因为它们使得某些类型的优化成为可能(比如 JIT 编译器优化)。
比较 Class 与 Struct
内存分配:Struct 是值类型,分配在栈上;Class 是引用类型,分配在堆上。
继承:Class 支持继承;Struct 不支持继承;Interface 用于实现多重继承。
默认构造函数:Class 可以有自定义的无参构造函数;Struct 总是有一个默认的无参构造函数。
实例化:Class 实例化时使用 new 关键字;Struct 可以不使用 new 关键字。
赋值行为:Struct 赋值时复制其值;Class 赋值时复制引用。
工厂模式
工厂模式是一种创建型设计模式,用于创建对象,而不将对象创建的逻辑暴露给客户端。它提供了一种封装机制,用于创建对象的实例,这样可以让系统更加模块化,增加代码的可维护性和灵活性。
当一个类不知道它所必须创建的对象的类的时候,或者当一个类希望由其子类来指定创建对象的类的时候,或者当类将创建对象的职责委托给多个帮助类中的某一个,局部地希望将哪一个委托者是谁作为信息隐藏的时候,我们就可以使用工厂模式。
类型
工厂模式有三种常见的分支类型。
简单工厂模式:不属于 GoF 的 23 种设计模式,它使用一个中心化的工厂类来创建所有的实例。
工厂方法模式:定义一个用于创建对象的接口,但让子类决定实例化哪个类。工厂方法使一个类的实例化延迟到其子类。
抽象工厂模式:提供一个接口用于创建相关或依赖对象的家族,而不需要明确指定具体类。
代码
以工厂方法模式为例,假设我们有一个用于创建不同类型日志记录器的工厂。
// 抽象产品
public interface ILogger
{
void Log(string message);
}
// 具体产品
public class FileLogger : ILogger
{
public void Log(string message)
{
// 写日志到文件
}
}
public class ConsoleLogger : ILogger
{
public void Log(string message)
{
// 输出日志到控制台
}
}
// 抽象工厂
public abstract class LoggerFactory
{
public abstract ILogger CreateLogger();
}
// 具体工厂
public class FileLoggerFactory : LoggerFactory
{
public override ILogger CreateLogger()
{
// 返回 FileLogger 实例
return new FileLogger();
}
}
public class ConsoleLoggerFactory : LoggerFactory
{
public override ILogger CreateLogger()
{
// 返回 ConsoleLogger 实例
return new ConsoleLogger();
}
}
// 客户端代码
class Client
{
static void Main(string[] args)
{
LoggerFactory factory = new FileLoggerFactory();
ILogger logger = factory.CreateLogger();
logger.Log("This is a log message.");
}
}
在这个案例中,LoggerFactory 是一个抽象工厂,定义了创建对象的方法。
具体的工厂类是这边的 FileLoggerFactory 和 ConsoleLoggerFactory,它们去实现了上面定义的方法,用来创建具体的产品(比如 FileLogger 和 ConsoleLogger)。客户端代码仅与抽象工厂和产品接口交互,使得添加新类型的日志记录器时不需要修改客户端代码。
Comentarios