Unity游戏设计模式—单例模式（Singleton）
单例模式（Singleton）
⼀、单例模式定义
单例模式（Singleton）在GoF中的定义是：确认类只有⼀个对象，并且提供⼀个全局的⽅法来获取这个对象。
单例模式在实现时，需要程序设计语⾔的⽀持。只要具有静态类属性、静态类⽅法和重新定义类建造者存取层级。
⼆、单例模式说明
Singleton参与的在项⽬中参与⾓⾊说明如下：
能产⽣唯⼀对象类，并且提供“全局⽅法”让外界可以⽅便获取唯⼀的对象。
通常会把唯⼀的类对象设置为“静态类属性”。
习惯上会使⽤Instance作为全局静态⽅法的名称，通过这个静态函数可能获取“静态类属性”。
实现⽰例：
public class Singleton
{
private static Singleton _instance;
public static Singleton Instance
{
get{
if(_instance==null)
{
_instance=new Singleton();
}
return _instance;
}
}
private Singleton(){}
}
在类内定义⼀个Singleton类的“静态变量”_instance，并定义⼀个“静态属性”
。这⾥也应⽤了C#的getter存取运算符功能来实现Instance⽅法。
三、反对过多使⽤单例
单例好⽤的原因之⼀是：可以马上获取类对象，不必为了“安排对象传递”或“设置引⽤”⽽伤脑筋，想使⽤类对象时，调⽤类的Instance ⽅法就可以马上获取对象，⾮常⽅便，但如果⼀直⽤下去，容易得“单例癖(Singletonitis)”，即过于沉迷于使⽤单例模式。
如果不使⽤单例模式或全局变量，最简单的对象引⽤⽅式就是：将对象当成“⽅法参数”，⼀路传到最后
需要使⽤该对象的⽅法中，⾮常不⽅便且容易失控。
其实，产⽣这样⽭盾的原因是：开发时过度使⽤“全局变量”及不仔细思考对象的“适当可视性”所造成的产物，并且多数还是在设计上出现问题导致的，这些是是可以避免的。
如果更深⼊探讨，单例模式还违反了“开—闭原则（OCP）”。因为通过Instance⽅式获取对象是“实现类”⽽不是“接⼝类”，该⽅式返回的对象包含了实现细节的实体类。
因此，当设计变更或需求增加时，程序设计师⽆法将其替代为其他类，只能更改原有的实现类内的程序代码，⽆法满⾜“对修改关闭”的要求。
与其这样还不如花点时间修改原有的设计。
四、少⽤单例模式时如何⽅便地引⽤到单⼀对象
1、让类具有计数功能来限制对象数量
在数量限制的类中加上“计数器”（静态成员属性）。每当类的建造者被调⽤时，就让计数器增加1，然后判断有没有超过限制的数量，如果超过，标记为⽆法使⽤，后续的对象功能也不可以被执⾏。
public class ClassWithCounter
{
protected static int m_ObjCounter=0;
protected bool m_bEnable=false;
public ClassWithCounter(){
m_ObjCounter++;
m_bEnable=m_ObjCounter==1?true:false;
if(!m_bEnable){
//当前数量已超1个
}
}
public void Operator(){
if(!m_bEnable)
return;
}
}
2、设置成为类的引⽤，让对象可以被取⽤
某个类的功能被⼤量使⽤时，可以将这个类对象设置为其他类中的成员，⽅便直接引⽤这些类。
这种实现⽅法是“依赖性注⼊”的⽅式之⼀，可以让被引⽤的对象不必通过参数传递的⽅式，就能被类的其他⽅法引⽤。
按照设置⽅式⼜可分为：
分别设置：⽬标类设置为其他类中的对象引⽤；
指定静态类：⽬标类设置为其他类的静态引⽤成员
3、使⽤类的静态⽅法
单例模式的几种实现方式
类的每⼀个静态⽅法都负责返回⼀个“资源⽣成⼯⼚接⼝”。
四、总结
单例模式
优点：
可以限制对象的产⽣数量；
提供⽅便获取唯⼀对象的⽅法；
缺点：
容易造成设计思考不周和过度使⽤问题，但并不是要求设计者完全不使⽤这个模式，⽽是在仔细设计和特定的前提下，适当采⽤。适⽤场景
⽹络在线游戏客户端，通过单例模式限制连接数，预防过多连接；
⽇志⼯具，受项⽬影响⽐较⼩，可设计为跨项⽬共享使⽤。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。