标签: dependency-inversion

"依赖倒置原则"(DIP)和"设计到接口原理"是否表达了相同的原则？如果没有,那会有什么区别？

编辑

稍微澄清和缩小上下文:通过接口我的意思是编程接口,如Java interface或C++中的纯抽象基类.不涉及其他"合同".

DIP声明:

• 高级模块不应该依赖于低级模块.两者都应该取决于抽象.
• 抽象不应该依赖于细节.细节应取决于抽象.

OCP声明:

软件实体(类,模块,函数等)应该是可以扩展的,但是关闭以进行修改.

我认为如果我们满足DIP,它也会涵盖OCP,那么,为什么我们将这两个原则分开呢？

我读过有关SOLID的文章但我没有看到OCP和DIP之间有任何区别.看看这个OCP的例子:

http://www.oodesign.com/open-close-principle.html

持有OCP的代码也满足DIP.任何人都可以给我一个持有OCP但不是DIP的代码示例吗？

如果我希望我的代码遵循SOLID原则,特别是依赖性反转原则,这是否意味着我必须为每个模块创建一个接口(抽象),即使它只有一个实现？

在我看来,并根据这些帖子:

http://josdejong.com/blog/2015/01/06/code-reuse/

http://blog.ploeh.dk/2010/12/02/Interfacesarenotabstractions/

为每个模块创建"抽象"是代码混乱并违反了YAGNI原则.

我的经验法则是:不要使用依赖注入,或者为模块创建接口,除非它有多个实现(第二个实现可以是用于数据库/服务器/文件模块的单元测试的模拟类).

有人可以为我清楚这一点吗？SOLID是否意味着我必须注入每个模块并对其进行抽象？如果是的话,是不是只是在很多时候我们根本不会使用它？

该依赖倒置原则说:

• 高级模块不应该依赖于低级模块.两者都应该取决于抽象.
• 抽象不应该依赖于细节.细节应取决于抽象.

我怎样才能在我的应用程序中找到高级和低级模块,对它们有什么清晰的定义吗？

在这篇博文中，这个励志海报描述了依赖倒置原则：

我不明白海报的意思：将灯直接焊接到墙上如何违反依赖倒置原则以及插头如何遵循依赖倒置原则。也许一些关于灯和电源插座的骨架 Java 或 C# 代码可能会有所帮助。

我是来自.NET世界的NodeJs开发的新手，我正在网上搜索有关在Javascript中对DI / DIP进行降级的最佳实践。

在.NET中，我会在构造函数中声明我的依赖关系，而在javascript中，我看到一个常见的模式是通过require语句在模块级别声明依赖关系。

对我来说，当我使用require时，我会耦合到特定文件，同时使用构造函数来接收我的依赖项更加灵活。

您会建议采用javascript的最佳做法吗？（我正在寻找架构模式，而不是IOC技术解决方案）

搜索网络时，我遇到了此博客文章（评论中有一些非常有趣的讨论）：https : //blog.risingstack.com/dependency-injection-in-node-js/

它使我的冲突非常好。这是博客文章中的一些代码，可让您了解我在说什么：

// team.js
var User = require('./user');

function getTeam(teamId) {  
  return User.find({teamId: teamId});
}

module.exports.getTeam = getTeam; 

一个简单的测试如下所示：

 // team.spec.js
    var Team = require('./team');  
    var User = require('./user');

    describe('Team', function() {  
      it('#getTeam', function* () {
        var users = [{id: 1, id: 2}];

        this.sandbox.stub(User, 'find', function() {
          return Promise.resolve(users);
        });

        var team = yield team.getTeam();

        expect(team).to.eql(users);
      });
    });

VS DI：

// team.js
function Team(options) {  
  this.options = options;
}

Team.prototype.getTeam …

我正在asp.net中构建一个简单的MVC应用程序.我想遵循依赖倒置原则,我不知道我是否做得对.

我目前正在研究身份验证系统.我有一个AccountController,里面使用Authenticator服务.Authenticator服务通过构造函数注入注入控制器.

public class AccountController : Controller
{
    private IAuthenticator _authenticator;

    public AccountController(IAuthenticator authenticator)
    {
        _authenticator = authenticator;
    }

    //
    // POST: /Account/Login

    [HttpPost]
    public ActionResult Login(LoginModel model, string redirectToUrl = null)
    {

     ...

    }

文件的结构是这样的:

但我想如果我想要完全颠倒控制器及其依赖关系之间的重要性,我将不得不将身份验证服务的接口移到控制器旁边.像这样的东西:

这样,客户端 - 控制器 - 以及服务的抽象将位于同一名称空间中.因此,服务接口的更改将来自客户端,并将传播到服务实现.而不是以前的方式,服务中发生的变化传播到客户端.依赖项是Inverted - 服务依赖于客户端.

当客户端和服务在不同的程序集中时,我可以看到这样做的好处,但是我不确定如果在同一个程序集中我应该这样做.

如果我这样做是正确的,我是否应该使用第一个文件结构或第二个文件结构,请告诉我.

谢谢,阿西尔

我正在学习设计模式和它周围的东西(特别是SOLID和Dependency inversion原理),看起来我正在失去一些东西:

遵循DIP规则,我应该能够通过不在类(组合)中创建对象,而是将对象引用/指针发送到类构造函数(聚合)来使类不那么脆弱.但这意味着我必须在其他地方创建一个实例:因此,具有聚合的一个类越灵活,另一个类就越脆弱.

请解释一下我错在哪里.

我正在通过以下链接来了解依赖反转原则中高级和低级模块的含义。

根据此处给出的说明，以下代码段是否是一个好/适当的示例？

public class HighLevel
{
    private IAbstraction _abstraction;

    public HighLevel(IAbstraction abstraction)
    {
        _abstraction = abstraction;
    }

    public void Act()
    {
        _abstraction.DoSomething();
    }

}

public interface IAbstraction
{
    void DoSomething();
}

public class LowLevel: IAbstraction
{
    public void DoSomething()
    {
        //Do something
    }
}