网站建设有哪些规章制度,网页版面,wordpress自定义附近上传路径,怎么在百度发布自己的文章依赖注入(Injecting dependencies)经常听起来会让人感觉到很难以理解#xff0c;会让大家感觉这是很复杂的编程技术#xff0c;但是事实上并不是这样#xff0c;依赖注入非常方便使用#xff0c;它会让你的程序非常便于理解#xff0c;同时也更容易进行测试。
依赖注入的… 依赖注入(Injecting dependencies)经常听起来会让人感觉到很难以理解会让大家感觉这是很复杂的编程技术但是事实上并不是这样依赖注入非常方便使用它会让你的程序非常便于理解同时也更容易进行测试。
依赖注入的工作方式 任何好的程序都是由很多互相协作的类来实现复 杂的逻辑的。在传统的使用方法中每个对象都会把自己的引用传递给它协作的对象但是这样会造成对象间的高度耦合同时不容易对程序进行测试。接下来我们看一个例子 从这个例子中我们可以看出来DamselRescuingKnight在容器中创造了他自己的 RescueDamselQuest请求不过这使得DamselRescuingKnight和 RescueDamselQuest紧紧耦合同时也限制了骑士能做的事情如果美少女需要救援骑士可以轻松胜任但是如果恶龙需要治服或者...其他各种事情这时骑士根本无能为力。除此之外这样的设计也很难去进行测试在这个例子中当 embarkOnQuest()被调用又调用到 embark()到时需要我们在 embark()中插入断点但是这很难实现也就是说我们没法很好的测试DamselRescuingKnight的功能。 耦合是一个双头怪兽一方面它高耦合的代码很难测试很难复用同时也很难理解。而且它还可能造成whack-a-mole这样的bug(就像我们在打鼹鼠时一样我们注重一处的代码可是在其他地方却引发了更多的bug)另一方面其实一些适当的耦合其实也是有用的完全的飞耦合让我们很难实现有些功能。为了能够高效的开发类之间必须能够互相了解 适当的耦合是必须的但是必须要控制好这个度。通过使用DI对象所需要的依赖会在创建时由熟悉各个对象的第三方提供也就是将每个对象需要的依赖在它在创建时注入给它。接下来我们将看到一个真正全能的骑士他不仅能够击败邪恶势力拯救美少女同时也能够下厨做美食他能够回应你的各种请求。 如上面所示BraveKnight并不像DamselRescuingKnight它不需要创建任何请求取而代之的是在构造器中或获取它需要的request。这种DI一般被称为constructor injection。不仅如此上面的quest如果是个接口那么我们可以实现任何形式的request。 重点是BraveKnight不需要和任何已实现的Quest耦合它并不需要去了解这个接口是如何实现的。这就是DI最重要的特性-----低耦合性。这个特性的一个很重要的用途是我们在进行测试时可以可mock掉这个接口。而在高耦合的设计中这很难实现。 在这里使用了叫做Mockitode的mock对象framework通过它我们可以创造一个实现了Quest接口的mock利用来实例化BraveKnight并且通过构造函数注入mockquest这时我们就可以调用embarkOnQuest()方法并且去验证embark()是否确实被调用了一次。
