设计模式简要介绍

设计模式有很多，较为重要的如下

静态和单例模式

单例模式的本质就是类成员中有一个对象实例

public class Animal{
  public static string Title = "Animal" // 类成员
  public string Name; // 对象成员
  public const float Pi = 3.14f; // 类成员
  public readonly float Pi2 = 3.14f // 对象成员
  public static readonly Animal animal; //类成员
  private static Animal Instance;  //实例
  public static Animal Instance{
    get{
      if(instance == null){
        instance = new Animal();
      }
      return instance;
    }
  }

  // 类构造函数
  static Animal(){
      animal = new Animal();
  }
  // 对象构造函数
  public Animal(){

  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

注意：

1. 我们也可以把整个类static来当做单例
2. 使用单例时，我们把构造函数私有可以防止被人new，在类前加上seal防止被继承，在构造函数前加上static也可以

观察者模式

多人开发的时候，每个人开发不同的功能，每个人代码风格不一样，但是要用到别人提供的功能，别人还没有写对应的功能，这时候我们要用到事件，关心的人订阅这个事件即可，完全不用关心其他人的代码。我们可以用到C#里面的Action函数。
这样的订阅功能我们可以用一个EventManager来管理，包含至少以下方法：订阅事件，取消订阅事件，触发事件， 移除事件，我们可以通过一个字典来进行管理，键是对应的命名（可以用枚举），值就是对应的Action(可以封装一下)。

外观模式

把一个功能的细节全部封装起来，只对外暴露使用者关心的部分。例如一场战斗开始之前我们需要初始化各个系统，有网络系统，团队系统，背包系统，AI系统等等，但是我们都把它封装到一个函数当中调用即可，对外只暴露一个初始化战斗的函数，战斗时候的更新同理，我们也可以把各个系统的更新集成到一起。
定义：为子系统定义一组统一的接口，这个高级接口让子系统更容易被使用。

状态模式

枚举是关键。怪物的状态机是一个例子。不同的状态有不同的初始化动作，不同的更新动作，更新的时候有状态转移条件。

工厂模式

概念：工厂模式（Factory Pattern）是一种创建型设计模式，它提供了一种将对象的创建和使用分离的方式。工厂模式通过定义一个创建对象的接口，但将具体的对象创建过程延迟到子类来完成。这样，客户端代码就不需要知道具体的对象创建细节，只需要通过工厂方法获取所需的对象。工厂模式的主要目的是封装对象的创建过程，使客户端与具体的对象类解耦，从而提供更大的灵活性和可维护性。
例子：MMORPG中输入网络端的信息即可调用对应的接口创建对应的角色。
工厂模式通常涉及以下角色：

抽象工厂（Abstract Factory）：定义了创建对象的接口，它是工厂方法模式的核心，具体工厂类实现了这个接口。

具体工厂（Concrete Factory）：实现抽象工厂接口，负责创建具体的产品对象。

抽象产品（Abstract Product）：定义了产品的接口，描述了产品的特性和功能。

具体产品（Concrete Product）：实现抽象产品接口，是被创建的对象。

工厂模式的工作流程如下：

客户端通过调用抽象工厂的方法创建产品对象，而不直接实例化具体产品类。

抽象工厂根据客户端的请求，选择合适的具体工厂来创建产品对象。

具体工厂根据客户端的请求，创建具体的产品对象，并将其返回给客户端。

工厂模式的好处在于当新增一个类的时候我们不会对原来的代码进行修改，只新增类本身及其工厂。

策略模式

根据不同的条件需求，构建不同的实例，并且在策略模式内 封装具体的自定义行为接口
应用场景
例如: 游戏设置界面，根据GPU品质，批量设置群组显示效果

命令模式

命令是对命令的封装，每一个命令都是一个操作，请求方发出请求，接收方接收请求，并执行操作。命令模式解耦了请求方和接收方，命令模式属于行为型模式
有执行队列的需求，且支持撤销需求
应用场景
例如: 比如FPS 输入模块，需要存储某些输入指令时
优点：
通过引入命令的抽象接口，实现了命令请求与实现的解耦
扩展性良好，可以很容易的增加新命令

面向对象的设计原则

1. 单一职责原则：一个类只做一件事情
2. 开放-封闭原则：对于扩展是开放的，对于更改是封闭的
3. Liskov替换原则：子类必须能替换基类
4. 依赖倒置原则：依赖于抽象，在依赖之间定义一个抽象的接口使得高层模块调用接口，而底层模块实现接口的定义，以此来有效控制耦合关系，达到依赖于抽象的设计目标。
5. 接口隔离原则：使用小的专门接口，不要使用大的总接口