ioc是什么意思的缩写(错误的IOC和DI)

什么是IOC?

什么是DI?

IOC和DI有什么关系?

作为程序员,天天撸代码,怎么能不知道IOC和DI呢。很多面试官也喜欢问这两个概念,虽然概念很简单,但是可以从面试者的回答当中,大体的可以估算到面试者的功力,那IOC和DI到底是何方神圣呢?让我们来一步一步扒掉它的外衣!!

ioc是什么意思的缩写(错误的IOC和DI)

说到IOC和DI,必须要提一下软件设计的六大原则

单一职责原则

一个类应该只有一个发生变化的原因

开闭原则

软件实体应该是可扩展,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。

里氏替换原则

所有引用基类的地方必须能透明地使用其子类的对象,换句话说,子类在任何引用基类的地方都可以替换成子类。

依赖倒置原则

这个原则说的详细一点其实可以概括为两点:

  1. 高层模块不应该直接依赖于底层模块,应该依赖于抽象
  2. 抽象不应该依赖于具体实现,具体实现应该依赖于抽象

接口隔离原则

程序不依赖于不使用的接口,换句话说,一个程序只依赖于它需要的接口。

我在之前的很多文章中也多次提到,要想系统保持高扩展性,始终离不开对业务的深刻理解和抽象

论系统设计的高可扩展性

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呢?其实我不推荐

写在最后

关于上边的问题,欢迎来喷,毕竟知识需要讨论才能进步


华风扬是一家创业点子分享平台,在这里提供互联网创业项目,以及引流推广、网络营销、实操案例分享,需要网上创业点子那就上华风扬,找项目,学推广就来华风扬!

联系我们:微信公众号搜索“大婶说事”

版权声明:本站部分文章来源或改编自互联网及其他公众平台,主要目的在于分享信息,版权归原作者所有,内容仅供读者参考,如有侵权请联系我们,如若转载,请注明出处:http://www.uxxsn.com/89834.html

发表评论

您的电子邮箱地址不会被公开。