面向对象编程原则

Question

我想知道，我最近读了一篇文章，谈到了使用单例模式的弊端，指出了全局变量发生的缺点，正确地说，单例模式违反了我们从OOP学校学到的许多规则，单一责任原则，编程接口和抽象类，而不是具体的类……所有这些好东西。我想知道如何使用数据库连接类，在这个类中，您只需要一个到数据库的连接和一个浮动的数据库对象。作者谈到了依赖注入原则，在我看来，它与依赖倒置规则很好地站在了一起。除了我创建了类，并期望每个使用它的人都玩得很好，并确保他们使用正确的资源之外，我如何知道和控制哪些对象被作为依赖项传递？！

Answer 1

编辑:此答案假设您正在使用依赖注入容器，要么是您自己编写的容器，要么是从库中获得的容器。如果不是，则使用DI容器:)

除了我创建了类并期望每个使用它的人都表现良好并确保他们使用正确的资源这一事实之外，我如何知道和控制哪些对象作为依赖项传递？！

按合同列出的

口头契约--你可以写一份设计规范，说明“你不应该直接实例化这个类”，“你不应该传递从依赖注入容器中获得的任何对象。如果有必要的话，传递容器”。

编译器契约--你给他们一个依赖注入容器，然后他们通过抽象接口从容器中获取实例。如果您只想使用单个实例，您可以为它们提供一个命名实例，它们使用名称和接口提取该实例。

ISomething instance = serviceLocator.ResolveInstance<ISomething>(
  "TheInstanceImSupposedToUse");

您还可以将所有的具体类设置为私有/内部/拥有什么，并且只为它们提供一个抽象接口来操作它们。这将阻止它们自己实例化类。

// This can only be instantiated by you, but can be used by them via ISomething
private class ConcreteSomething : ISomething
{
    // ...
}

由代码评审生成的

您制定了公平的组范围编码和设计标准，并确保组中的每个人都能理解这些标准。

您使用源代码控制机制，并要求在代码签入之前进行代码审查。您将仔细阅读它们的代码，了解它们链接到什么、它们包含哪些头文件、它们实例化了哪些对象以及它们传递了哪些实例。

如果他们在代码审查过程中违反了您的规则，那么在他们修复代码之前，不要让他们签入。对于屡教不改的人，你可以让他们付给你一美元，让他们请你吃午饭，或者你雇一个不同的承包商来取代他们。在您的团队中运行良好的:)

Answer 2

对于那些批评基于SRP的单例模式的人，这里有一个opposing view。此外，我还发现依赖注入容器可能会产生与它们解决的问题一样多的问题。也就是说，我使用了一个有希望的折衷方案，如another post中所述。

Answer 3

依赖注入容器(即使是您自己开发的容器，这并不是一种完全不常见的做法)通常是非常可配置的。在该场景中，您要做的就是对其进行配置，以便对该实现实现的接口的任何请求都将由该实现来满足。即使它是一个单例。

例如，看一下这里使用的Logger单例：http://www.pnpguidance.net/News/StructureMapTutorialDependencyInjectionIoCNET.aspx