程序员过关斩将--错误的IOC和DI
什么是IOC？
什么是DI？
IOC和DI有什么关系？
作为程序员，天天撸代码，怎么能不知道IOC和DI呢。很多面试官也喜欢问这两个概念，虽然概念很简单，但是可以从面试者的回答当中，大体的可以估算到面试者的功力，那IOC和DI到底是何方神圣呢？让我们来一步一步扒掉它的外衣！！
说到IOC和DI，必须要提一下软件设计的六大原则
单一职责原则
一个类应该只有一个发生变化的原因
开闭原则
软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。
里氏替换原则
所有引用基类的地方必须能透明地使用其子类的对象,换句话说，子类在任何引用基类的地方都可以替换成子类。
依赖倒置原则
这个原则说的详细一点其实可以概括为两点：
- 高层模块不应该直接依赖于底层模块，应该依赖于抽象
- 抽象不应该依赖于具体实现，具体实现应该依赖于抽象
接口隔离原则
程序不依赖于不使用的接口，换句话说，一个程序只依赖于它需要的接口。
我在之前的很多文章中也多次提到，要想系统保持高扩展性，始终离不开对业务的深刻理解和抽象
IOC
控制反转（Inversion of Control，缩写为IoC），是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度
以上是IOC最典型的概念定义，其中“控制”这个词具有很泛的概念，比如：控制对象的初始化，控制程序的流程，控制资源的生命周期...等等，反转就和表面意思一样比较好理解，就是反过来。控制和反转综合起来呢，可以概括为：
对于程序的行为，把控制权交给其他人
确实不好理解，因为上面这句话是我自己总结的，说实话，我自己咋一听到都理解不了。还是举个栗子吧：
最常见并且最常用的莫过于类的使用，如下代码：
class A
{
public void XXOO(){
}
}
class Main
{
A a=new A();
a.XXOO();
}
上面的代码我想在我们平时的coding过程中非常多，那有什么问题吗？还是那句话，从功能性的角度来说，只存在正确和错误的观点，但是从非功能性的角度来说，每个人有每个人的见解。有的人不喜欢代码中中到处充斥着New的味道，有的人却喜欢掌控自己的代码（因为自己写的New，自己最清楚）。
至于软件编写的对与错，并没有一个明确的规范去说明，但是软件从小到大，从简单需求到越来越多的需求，把软件开发过程中一些不爽的诟病提取出来并解决，就是软件质量提升的一个度量角度。
言归正传，上面的代码以多数程序员的角度来说，不喜欢到处有New这个关键字，就好像New多了会出Bug一样！！为什么好多架构师不推荐到处有New的味道？我认为并不是代码美不美观，能不能装X的问题，是因为软件架构层次中强依赖的关系。
那怎么破除强依赖呢？
DI(依赖注入)
与IOC不同，DI是一种具体的编码技巧。但是，它并非为了解决New的问题而生，而是为了解决软件架构层面的问题而生，其实，从大多数使用场景来说，DI确实可以看做是实现IOC的一种解决方案。
有的架构师说，依赖注入就是把类放到容器当中，然后解析这些类的实例。我不否认原理上确实是容器来负责管理有依赖关系的模块或者类（接口），但是依赖注入在依赖关系上其实在为了解耦和多态。
说到这里，突然想起一件小事，作为高大上工作的开发者，都已经跨入21世界20多个年头了，还在围绕着数据库进行coding，在没有表的情况下居然没办法开展工作？我并不排斥围绕数据库进行设计编码，因为很多统计类的需求确实需要这样，但是大多数业务不应该是围绕业务来开展编码吗？没有数据库就不能进行coding是不是该改一改了？
依赖注入会在架构的扩展点出现，一个好的软件架构，永远会在需要扩展的地方提供自定义入口，说直白一点，任何一个系统都应该在会变化的地方进行抽象。举一个简单例子：一个支付系统会存在多种支付方式：微信、支付宝、银联等等。这些不同的支付方式其实就可以看做是系统的变化点，应该把这个地方进行抽象，并花大量精力去好好设计。
重点问题
那么问题来了：如果我没有使用面向接口（interface）进行开发，代码的分层一律都是以类（Class）来组织的，类似于以下代码：
var ret = await UserService.SetDefaultUserPlan(para.UserId, para.UserPlanId);
那我的类UserService是否也应该进行依赖注入呢？类似于以下代码(DI框架可能不一样，但是原理都是相同的)
services.AddSingleton<UserService, UserService>();
我想这个问题，每个人也都有自己的见解。有很多人认为，DI解决的是到处充斥着New味道的问题，每个类都应该进行DI操作，这样的代码才够“简洁，漂亮”。
是吗？
针对于以上观点，我其实有话要说。还是本质问题的讨论，DI到底要解决软件开发中的什么问题呢？是New的问题吗？不，是解耦、扩展、依赖的问题。
说道这三个非功能性的指标，其实和上边讲的几大软件设计规则息息相关，无论是什么样的软件系统都摆脱不了业务变化的命运。有的程序员最害怕这种变化，因为一旦发生业务变化，他就要改动大量的代码，接连会产生大量的Bug，进而会加大量的班。
其实，面对变化的时候，如果发生以上情况，我们应该反思自己是不是没有把业务的变化点分析清楚。还是拿支付业务为例，假如系统开始只有微信支付，可能你的代码很像以下这种
public void Pay(int amount)
{
//微信支付
WXPay.Pay(amount);
}
随着时间推移，公司业务发展壮大，产品上要支持支付宝支付，你的代码很大概率会变成这样
public void Pay(int payMode, int amount)
{
if (payMode == "微信支付")
{
//微信支付
WXPay.Pay(amount);
}
else if (payMode == "支付宝支付")
{
//支付宝支付
AliPay.Pay(amout);
}
}
如果随着业务继续发展，产品上又陆续加入了很多支付方式，你的代码就会变成以下这种方式
public void Pay(int payMode, int amount)
{
if (payMode == "微信支付")
{
//微信支付
WXPay.Pay(amount);
}
else if (payMode == "支付宝支付")
{
//支付宝支付
AliPay.Pay(amout);
}
else if (payMode == "XX支付")
{
//支付宝支付
XXXPay.Pay(amout);
}
else if (payMode == "YY支付")
{
//支付宝支付
YYPay.Pay(amout);
}
.
.
.
}
大量的if-else，很多人称之为“坏代码”味道（其实这样的代码每个公司都有）。通过这个例子其实大家已经看出来了，支付方式这是一个业务的变化点，应该在这个业务点上做抽象了。这个时候所谓的面向接口编程正是解决之道,其实也可以理解为程序的多态性：
interface IPay
{
void Pay(int amount);
}
然后每次新加一种支付方式，去实现这个接口，然后利用DI操作一下。在业务发生变化的过程中，根据某种策略来实现对应的支付方式即可。
在这个例子中，利用DI技术不仅解决了依赖倒置原则，更解决了系统扩展性的问题。回到开头的问题，为了解决New的美观问题，到底应不应该使用DI呢？其实我不推荐
写在最后
关于上边的问题，欢迎来喷，毕竟知识需要讨论才能进步