网站开发部职责,wordpress网址缩短,泰安做网站网络公司,免费观看短视频的app软件有哪些之前看过前辈Artech关于控制反转的一篇文章#xff0c;文章通俗易懂且言语精炼#xff0c;写技术文章既是积累也是分享#xff0c;既然是分享那么必须让读者能够明白到底讲解的什么#xff0c;所以在这里我也挑战下自己#xff0c;看看能不能将概念通过简洁代码和语言的形… 之前看过前辈Artech关于控制反转的一篇文章文章通俗易懂且言语精炼写技术文章既是积累也是分享既然是分享那么必须让读者能够明白到底讲解的什么所以在这里我也挑战下自己看看能不能将概念通过简洁代码和语言的形式充分阐述清楚若有错误之处还望指正。什么是控制反转控制反转的英文名为Inversion Of Control我们简称为IOC控制反转是一个原则而不是一个设计模式它是反转程序的控制流这个术语在Steapano Mazzocchi的Apache软件基金会项目Avalon中被推广然后在2004年由Robert C. Martin和Martin Fowler进一步推广。正如Martin Fowler所说控制反转是框架的共同特征因此说这些轻量级容器之所以特别是因为它们使用控制反转就好像在说我的车很特别因为它带有轮子一样。它基本上是框架的定义特征控制反转用于增加程序的模块化并使其可扩展。那么问题来了真正反转体现在哪里呢在早期计算机软件命令行用于通用程序因此用户界面由应用程序本身控制在程序中我们可以通过将响应输入命令行来直接控制程序的流程但是在GUI程序中我们基本上是将控件移交给了窗口系统UI框架然后由窗口系统决定下一步要做什么此时程序的主控件从我们移到了UI框架。控制反转是库和框架之间的区别使用库时库本质上是调用特定的函数和方法来执行计算和操作每个调用都会完成一些工作并将控制权返回到客户端而框架会为我们完成一些工作我们只需要向框架不同位置注册我们所编写的代码然后框架将在需要时调用我们编写的代码。用更加通俗易懂的话理解则是不要叫我我会叫你或者不要给我们打电话我们会通知你好莱坞法则。有了对概念的初步理解接下来我们通过代码的形式来加深对概念的理解。我们反观上述代码因为汽车的组成离不开引擎构造当我们调用汽车对象实例时将主动去构造引擎对象实例表述上没有任何问题但是我们意识到引擎和汽车紧密结合在了一起如果构造引擎对象一旦发生变化毫无疑问我们需要修改汽车对象也就是说汽车对象强依赖引擎对象现在我们将代码进行如下修改在此种情况下汽车对象并不知道如何构造引擎对象当调用汽车时汽车的调用者有责任和义务将引擎对象实例传递给汽车此时流程控制被反转这种反转类似于基于事件的处理机制。也就是说流程管理从应用程序转移到了框架经过如此修改后引擎上升到了框架如黑匣子一般因为我们并不关心引擎具体如何构造。同时我们也可看出通过控制反转使程序更加灵活和松散耦合。讲完了控制反转的概念和例子我们似乎还有一个未进行讲解好像我们听到更多的是依赖注入那么依赖注入和控制反转有着怎样的联系呢依赖注入和控制反转两个相关但概念截然不同依赖注入的思想就是一个单独对象说白了就是编写类的方式使得可以在构造时将类或函数的特定实例传递给它们依赖注入其实就意味着控制反转因为当我们在对象上调用方法时它们不再定位它们所需的其他对象。取而代之的是它们在构造时就已被赋予了依赖关系但我们仍然必须管理构造通过使用控件容器的反转我们可以使依赖注入更进一步通过反转控制容器我们只需预先注册所有可用的类。当容器需要构造一个类的实例时它可以检查该类的构造函数需要哪些对象然后可以从向其注册的类中构造适当的实例总的来说依赖注入只是实现控制反转的一种方式而已。我们抛开依赖注入实现了控制反转仅仅只讨论依赖注入带来了哪些好处。既然是面向对象的语言那么我们是编写基于面向对象的代码那么对象自然而然就有其生命周期有的对象可能我们只需要一个实例有的对象可能在程序运行整个过程中一直存在也就是全局实例而且有的对象里面存在着对其他对象的引用如此一来会造成什么问题呢导致代码难以理解而且难以更改尤其是对于全局实例而言全局实例离散性行为太强分散在整个项目中的各个角落最主要的是我们所编写的代码细节中也隐藏了对象之间的交互有些实例就包含了对其他实例的引用一旦出现问题我们唯有通读每一行代码。我们通过引入依赖注入代替全局实例方式通过依赖注入常用方式即构造函数注入注入依赖项参数此举将提高代码的可读性我们只需快速浏览构造函数即可查看对应依赖关系。通过引入依赖注入我们需要注意的是对对应类进行合理划分因为每次引入新的依赖项时可能还是存在类与类之间的依赖将不同行为划分到不同组如此才能减少类与类之间的耦合使得我们的设计更具凝聚力。通过引入依赖注入也使得我们在进行单元测试时更加方便因为我们可通过隔离类来直接测试类实例。控制反转代码说明接下来我们讨论下如何利用程序实现控制反转实现控制反转最常见的两种方式则是服务定位器模式SL和依赖注入模式DI。接下来我们通过例子利用依赖注入和服务定位器模式实现控制反转。我们通过控制台实现获取图书馆库图书列表查询我们想要的图书如下我们定义图书类然后接下来我们将控制台程序名称修改为图书馆库然后根据我们输入的图书来查询图书并打印伪代码如下如上我们通过bookFinder获取图书馆图书列表然后查询我们输入的图书名称并打印我们一眼就能看出这个bookFinder从哪里来呢我们可能查找深圳图书馆或者国家图书馆或者网上远程爬取呢所以接下来我们需要创建bookFinder的接口实现如下经过上述改造后我们提供了IBookFinder接口以及其实现但是现在我们正在将其作为一个框架需要被其他人可扩展和使用若此时需要提供给国家图书馆使用呢我们可以看到此时图书库即Library同时依赖IBookFinder和及其实现当我们作为可扩展框架时最佳效果则是依赖接口而不是依赖具体实现细节那么此时该实例我们到底该如何使用呢答案则是控制反转我们通过依赖注入实现控制反转。接下来我们将上述图书馆库Library修改为通过构造函数注入IBookFinder接口此时库将仅仅只依赖于IBookFinder接口IBookFinder内部具体实现Library并不关心然后在控制台进行如下调用上述我们通过依赖注入使得我们可以进行可扩展根据不同图书馆需要只需提供IBookFinder具体实现即可依赖注入并不是实现控制反转唯一的方式我们还可以通过服务定位器来实现服务定位器的背后是一个对象该对象知道如何获取应用程序可能需要的所有服务也就是说服务定位器提供我们返回IBookFinder接口的实现如下通过依赖注入和服务定位器实现控制反转都分离了相互依赖只不过依赖注入让我们通过构造函数一目了然就可查看依赖关系而服务定位器需要显式请求依赖关系本质上没有任何区别至于如何使用主要取决于我们对二者的熟悉程度。正如Martin Fowler所说使用服务定位器时每个服务都依赖于服务定位器它可以隐藏对其他实现的依赖关系但是我们确实需要查看服务定位器因此是否采用定位器还是注入器主要决定于该依赖关系是否成问题。讲到这里我们借助于IServiceProvider接口实现.NET Core中的服务定位器。如下除了以上写法外我们还可以通过实例化ServiceLocator的方式来获取服务如下接下来我们写一个简单的接口来验证是否正确不知道上述两种写法是否存在有什么不妥的地方有的时候通过服务定位器的方式也非常清爽因为当我们实例化最终具体实现时通过构造注入依赖项时本没有什么但是若后期一旦需要增加或减少依赖项时我们同样需要修改最终具体实现像这种情况是否可以考虑用服务定位器模式直接通过服务定位器去获取指定服务当在具体方法里时我们每次都得去获取服务反而不如在构造器中一劳永逸注入。所以选择注入器和定位器根据个人而选择或者根据具体功能实现而定才是最佳。 控制反转举栗说明上述我们通过代码的形式来进一步阐述了控制反转在代码的世界里我们运用控制反转游刃有余在现实生活里我们运用控制反转也是得心应手。年末将至全家欢聚一堂这应该是一年中最热闹的一次家庭聚会了吧为了准备年饭具体要提供哪些食材和食物作为家庭的一份子都得有基本了解所以我们必须提前准备好这些这就像我们编写一个没有依赖注入的基本程序一样这是在自家做的情况自家做饭吃完后又不能抹抹嘴上油拍拍屁股马上走人还得收拾不是于是乎我们将年饭地点切换到饭店进行此时饭店类似取缔了我们自备食材这一块饭店就像餐饮服务商一样我们不用自己做饭店会给我们提供食物它会根据我们的不同需求注入不同的餐饮服务。从自家-》饭店整个流程控制权进行反转我们将年饭控制权交给了饭店因为饭店成为了年饭这一事件的策划者它是我们能不能成功吃上年饭的必要条件我们告诉饭店老板有几个人、带了小孩、口味需重一点等等我们需要做的就是提供一些基本参数然后饭店自会组织我们并不需要关心和干涉细节他们会处理所有问题一切就绪后会通知我们。写本文的目的是一直对控制反转和依赖注入不太理解在脑海中一直处于模糊的概念同时呢之前面试官问我关于依赖注入的理解我居然支支吾吾的说成依赖倒置原则Dependency Inversion Principle千万不要将依赖注入、依赖倒置、控制反转搞混淆了依赖倒置是完全不同的原理虽然它也可以提供类之间的松散耦合和反转依赖项。文中若有错误之处还望指出感谢您的阅读谢谢。
