Unity【话大】设计模式之简单工厂
前言：笔者在最开始写程序的时候经常会遇到一种情况，例如更改一个字段、或者添加一种小功能，就要把原来写过的东西几乎废弃掉，或者更改大量以前写过的代码。又或者自己写的东西时间久了再去回顾，完全找不到到时为什么这么写的头绪，如果遇到了Bug更是无法快速定位在哪里小范围出现的问题。如果你也经常遇到这种问题，就说明你现阶段非常需要学习下设计模式了。
在网上经常说的设计模式有23种，也有一些更多的设计模式，无非也是从这些设计模式中变种而来。如果让笔者来形容什么是设计模式，我认为设计模式是：一种思想，一种模式，一种套路，一种解决问题的高效策略。
举个生活中的列子：你需要从家去公园，虽然都是从A点到B点，但目的是着急取东西，你会用代步工具快速到达，但如果仅仅是打发时间，完全可以散步去。用代步工具和散步本身没有绝对的对错，只是根据当时的需求采取的策略。设计模式这种思想，就是根据你当时的需求给你提供最高效的策略。
有说的不正确或者不准确的地方欢迎留言指正
有什么有趣的写作技巧或者想法欢迎大家给我留言，大家的帮助是我写下去最有效的动力
简单工厂
在开发中，同学们会遇到这种情况，在业务逻辑中会经常创建一些如下实例
public interface IProduct{}
public class Computer : IProduct{}
public class IPhone : IProduct{}
public class Mac : IProduct{}
public class IPad : IProduct{}
public void Example()
{
//DoSomeThing();
Computer computer = new Computer();
IPhone iPhone = new IPhone();
Mac mac = new Mac();
IPad iPad = new IPad();
//DoSomeThing();
}
如果这种情况比较多，那你就可以考虑下使用简单工厂模式了，让我们把上面的代码稍加改动一下
public enum ProductType
{
None,
Computer,
IPhone,
Mac,
IPad
}
public class SimpleFactory
{
public static IProduct CreatProduct(ProductType productType)
{
IProduct tempProduct = null;
switch (productType)
{
case ProductType.Computer:
{
tempProduct = new Computer();
}
break;
case ProductType.IPhone:
{
tempProduct = new IPhone();
}
break;
case ProductType.Mac:
{
tempProduct = new Mac();
}
break;
case ProductType.IPad:
{
tempProduct = new IPad();
}
break;
default:
{
Debug.LogWarning($"没有指定的产品{productType}");
}
break;
}
return tempProduct;
}
}
经过上面的改装我我们就可以这么写
public void ExampleSimpleFactory()
{
IProduct computer = SimpleFactory.CreatProduct(ProductType.Computer);
IProduct iPhone = SimpleFactory.CreatProduct(ProductType.IPhone);
IProduct mac = SimpleFactory.CreatProduct(ProductType.Mac);
IProduct iPad = SimpleFactory.CreatProduct(ProductType.IPad);
}
让我们对比一下原来和现在的写法
仅仅这么看貌似没有什么区别，而且代码量不减反增了，接下来笔者就要说说为什么要这么写了~~~
-
因为原始版的实例化都在对应的业务逻辑中，随着业务的不断增加，例如在实例化computer的时候需要进行参数传递的初始化，而且初始化的逻辑相对复杂，那么势必会大大增加原有类的代码量，这样原本只需要获取computer实例的一行代码可能会变成5-6行，如果这种情况很多的情况下，这一个类中增加的代码量可想而知，破坏了单一性原则。
-
如果在版本迭代的过程中，computer 初始化的相关逻辑需要更改，那么我们只需要去对应的简单工程实例部分进行修改，不必要修改原有的业务逻辑类，也大大降低了因为修改这一点点的业务逻辑造成原有类其他部分出现问题，这也是我们会后会说到的对扩展开放、对修改封闭。
-
还有一个原因就是这样功能的划分更方便问题的定位，一个类是业务逻辑，一个类是创建Product类，出现Bug也可以根据现象缩小问题范围，按照原来的写法他们都是在一个类里面的，后期代码量多的话这是个很头疼的问题~
如果项目的需求就是这4行实例Product能够满足后面的所有需求，那就按照最原始的写好了。
对于产品或者策划大佬说以后不会该需求的这种事,不管你们信不信，反正我是不信~~~
