按接口设计与 IoC/DI 比较
很长一段时间以来，我一直使用基于接口/继承的多态性来设计应用程序，以获得松散耦合的代码。据我所知（到目前为止）DI 框架/IoC 只是提供了使这“更容易”的工具，但是，额外的抽象级别似乎是多余的，并且会花费您额外的开销。
我能想到的唯一原因是，如果一个大型团队已经了解特定的 DI/IoC 框架，那么每个人都可以达成共识。
从我的角度来看，DI 似乎在做与界面设计相同的事情，我希望比这更多，有人可以向我解释为什么使用 DI/IoC 框架是更好的策略吗？
我真的希望我对 DI/IoC 的理解是错误的。
For a long time I've been designing applications using Interface/Inheritance based polymorphism, to gain loosely coupled code. As far as I can see (so far) DI frameworks/IoC merely provide tools to make this "easier", however, the additional level of abstraction seems to be redundant and costs you additional overhead.
The only reason I can think of is if a large team already know a particular DI/IoC framework then everyone can be on the same page.
From my perspective, DI seems to be doing the same thing as design by interface, I hope there's more to it than that, could anyone explain to me why using a DI/IoC framework is a better strategy?
I really hope I've got it wrong about DI/IoC.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，您可以阅读这个需要阅读并编辑其中任何缺失的点...
如果您期望 DI 容器 a) 是非凡的复杂野兽或 b) 一个全新的设计范例，我认为您正在以正常的防御方式做出反应一种接近过度炒作的概念的方式。
虽然人们可以投入大量精力以各种神秘的方式使用 DI 容器，并且其中有很多与 AOP 重叠的功能，但典型的最佳点是直接自动装配依赖项，而无需任何“所有团队需要了解“任何事情”或“开销”（您是指概念还是性能？如果是后者，您是否测量了实际应用程序中的影响？）。
但请理解这一点：-通过减少摩擦和增加可塑性而实现的自由和对干净设计的关注，这是因为你丢弃了大量的样板代码（以及如果情况发生变化就需要重新调整它），IOC 容器对我来说至关重要开发生态系统的一部分。虽然他们只是到处做了一些
新，但他们的影响与他们正在做的实际（少量）工作并不成正比。至于它们是否与基于普通接口的编程和良好的设计原则不同，我将它们视为更小的东西 - 一种仅支持其中一个 SOLID 原则。
Firstly, can you read this required reading and edit in any missing points from there...
If you're expecting DI containers to a) be extraordinary complex beasts or b) a whole new design paradigm, I reckon you're reacting in the normal defensive way one approaches an over-hyped concept.
While one can invest a lot of effort into using DI containers in all sorts of arcane ways, and there's lots of power in there wrt overlaps with AOP etc., the typical sweet spot is for straightforward auto-wiring of dependencies without any "all the team needing to understand" anything or "overhead" (do you mean conceptual or perf? If the latter, have you measured the impact in an actual app?).
But do understand this:- the freedom and focus on clean design enabled by the reduction in friction and increased malleability resulting from you chucking away a lot of boilerplate code (and the necessity to rejig it if things change) IOC containers are for me a critical part of a development ecosystem. While they're only doing a few
news here and there, their impact is not in proportion with the actual (small) bit of work they're doing.As for whether they're different to normal interface based programming and good design principles, I'd view them as something much smaller - a tool that enables just one of the SOLID principles.
不，DI/IoC 与通过接口设计不同。
DI/IoC 引擎实际上只是一个大型实例工厂。它使您不必编写和维护自己的。
好处是更少的维护（您不必编写它）和更多的受众来查找和报告错误。如果编写 DI/IoC 引擎的团队比您和您的团队更好，您就可以使用更高质量的软件。如果您选择一种比您自己开发的解决方案更广泛流通的解决方案，那么外部人员就有可能通过阅读广泛使用的书籍来了解如何使用它。您团队中的人员将通过了解知名框架并获得经验来丰富他们的简历。
我鼓励您继续进行界面设计，但 DI 的意义远不止于此。
No, DI/IoC is not the same thing as designing by interface.
A DI/IoC engine is really just a big instance factory. It saves you from having to write and maintain your own.
The benefits are less maintenance (you don't have to write it) and a larger audience to find and report bugs. If the team that wrote the DI/IoC engine is better than you and your team, you get to use higher quality software. And if you choose one that is in wider circulation than your home-grown solution, there's a chance that outsiders will know how to use it from reading books that are widely available. People on your team will have their resumes enhanced by knowing and gaining experience with a well-known framework.
I'd encourage you to continue to design to interfaces, but there's more to DI than that.