问题标签 [dependency-inversion]

如何修改此类以遵循 DIP（依赖倒置原则）以删除构造函数中的两个 ArrayList 依赖项？接口应该如何？

让我感到困惑的一件事是，新的引用不仅指向ArrayList<type>类的构造函数。而且我不知道如何处理这种情况......

}

}

}

}

}

}

这是来自 VTC 设计模式视频教程我的问题是这个例子是否违反了依赖倒置原则？

因为 TestConnection 类依赖于具体实现，因为 factory.createConnection() 返回具体实现而不是抽象。

我可以通过这样做来解决这个问题吗？

}

Headfirst Design Patterns 中的这个示例违反了“依赖倒置原则”，即“依赖于抽象。不依赖于具体类”。

上面的示例违反了规则，因为 DependentPizzaStore（高级组件）依赖于比萨饼（低级组件）的具体实现。

为了解决这个问题，我们使用工厂方法模式。

现在 PizzaStore（高级组件）仅依赖于 Pizza 具体类的 Pizza 抽象，并且具体 Pizzas 依赖于 Pizza 抽象，因为它们扩展了它。

我的问题是：NYPizzaStore 类是否也违反了“依赖倒置原则”，因为它依赖于 CheesePizza() 和 VeggiePizza()，它们是 Pizza 的具体实现。

命令模式具有三个主要组件：调用者、命令和接收者。Client 向Invoker提供调用ReceiverM上 的特定方法所需的信息，而实际调用的是Command对象（由Receiver提供）。M

a) 为了实现CP，我们必须将Invoker 的逻辑与命令的数量分离，这样当我们增加命令的数量时，Invoker类就不必改变。我们通过让Command对象和Invoker依赖于抽象（即接口）来做到这一点。

因此，CP不只是DIP的特定实现吗？

b) 如果CP确实是DIP的实现，那么CP与其他类型的DIP实现究竟有什么不同？也就是说，我们不能说所有其他的DIP实现也有Invoker对象（即更高级别的模块）、Command对象（即为更高级别的模块提供行为的依赖项），而 Receiver 将被视为依赖对象的任何方法（即较低级别的模块）调用？

谢谢你

编辑：

一个）

依赖对象将依赖项保持为一个字段，并将其用于所有后续方法调用。

如果依赖对象不将此依赖项保留为字段，因此它不会将其用于所有后续调用，而是始终接收新的依赖项对象，那么我们是否可以争辩说我们有一个CP而不是DI？

反之亦然——如果 Invoker 总是调用相同的命令对象，那么我们是否可以争辩说我们有DI而不是CP，而不管实际执行的工作命令对象是什么？

b）我理解你试图表达的观点，但我仍然在区分什么是行为和什么是命令时遇到了一些重大问题。在我看来，将命令传递给 Invoker 也可以解释为注入依赖对象完成其工作所需的行为。是真的那么明确还是更主观？因此，我们如何判断一个对象所做的工作是命令还是行为？

依赖倒置原则指出：高级模块不应该依赖于低级模块。

考虑到这一点，我的老：

变成了

我根据业务逻辑层保留 UI，以便我可以轻松附加另一个 UI 实现。我的业务逻辑层是大脑。

但这是否违反了依赖倒置原则？UI 比业务逻辑更高，对吧？

感谢您的帮助。

我有一个会发展的基础应用程序。现在 UI 包括 BLL。DAL 是一个为其目的服务的独立库。

我现在没有时间做所有事情，所以我想绕过有助于解耦的模式（IoC，DI，正如我在这里提出的那样）。

我想创建我的 BLL 并直接参考 DAL。这将使我有机会开始创建我现在需要的单独 UI。

我的问题是我能做到吗？我现在可以专注于创建我的 3 层并逐渐应用设计模式以使我的代码更好吗？

添加信息：

我有足够的时间，因为我的第一个应用程序不会在第二个应用程序的开发过程中使用。所以我将有时间优化我的编码结构。我能做些什么来尽可能有效地将 UI 拆分为 UI + BLL 的问题。我的想法是，我将在 BLL 中移动 DAL 初始化并将 BLL 初始化放入 UI。还有什么我可以做的，它会在以后应用 IoC/DI 时对我有更多帮助吗？

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

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

文件的结构是这样的：

但我在想，如果我想完全颠倒控制器及其依赖项之间的规范，我将不得不将身份验证服务的接口移动到控制器旁边。像这样的东西：

这样，客户端 - 控制器 - 和服务的抽象将位于同一个命名空间中。因此，服务接口的变化将来自客户端，并将传播到服务实现。而不是前一种方式，服务中发生的变化被传播到客户端。依赖是倒置的——服务依赖于客户端。

当客户端和服务位于不同的程序集中时，我可以看到这样做的好处，但我不确定当涉及到同一个程序集时是否应该这样做。

让我知道我是否正确执行此操作以及我应该使用第一个文件结构还是第二个文件结构。

谢谢， 阿西尔

我有一个 WCF 服务，我在那里尝试遵循依赖倒置原则。我有一些疑问并在下面列出。下面给出依赖原理之前和依赖原理之后的代码。

依赖原则之前的代码：-

依赖原则后的代码：-

1）但我收到错误“提供的服务类型无法作为服务加载，因为它没有默认（无参数）构造函数。要解决此问题，请向类型添加默认构造函数，或传递实例类型的主机”。

但是提供默认参数并不能解决我的问题。请给出解决问题的解决方案。

2）节点节点=新节点（）；// 我怎样才能删除这个依赖？[请看代码]

3）依赖倒置原则和wcf是好方法吗？

谢谢。

我能够使用名为“Castle Windsor”的依赖注入容器来实现依赖倒置原则。但在我的情况下，创建 Nodes 类的对象似乎不被称为“依赖”。

我读过这样的。

“仅数据对象通常不称为“依赖项”，因为它们不执行某些需要的功能。” 有什么想法吗？

谢谢。

依赖倒置原则说：

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

我如何在我的应用程序中实际找到高级和低级模块，它们有什么明确的定义吗？

DIP 指出：

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

OCP 规定：

软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。

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