oop - 面向对象编程原则

Question

我想知道，我最近读了一篇文章，它谈到了使用单例模式的弊端，指出了全局变量出现的缺点，并且正确地指出单例违反了我们从 OOP 学校学到的许多规则，单一责任原则，编程到接口(interface)和抽象类而不是具体类......所有这些好东西。我想知道您如何使用类似的数据库连接类，您只需要一个到您的数据库的连接和一个 float 的数据库对象。作者谈到了依赖注入(inject)原则，在我看来，它与依赖倒置规则相得益彰。我如何知道和控制什么对象作为依赖项传递，而不是我创建了类并期望每个使用它的人都表现得很好并确保他们使用正确的资源这一事实？!

Answer 1

编辑:此答案假设您使用的是依赖项注入(inject)容器，可以是您自己编写的容器，也可以是您从库中获得的容器。如果没有，那么使用 DI 容器 :)

How do I know and control what object gets passed around as a dependency other than the fact that I created the class and expect everyone using it play nice and make sure they are using the right resource?!

根据契约(Contract)

口头契约 - 你写了一个设计规范，说“你不能直接实例化这个类”和“你不能传递你从依赖注入(inject)容器中得到的任何对象。如果必须的话传递容器”。

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

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

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

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

通过代码审查

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

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

如果他们在代码审查期间违反了您的规则，在他们修复代码之前，您不会让他们签到。或者，对于屡犯者，你可以让他们付给你一美元，让他们给你买午餐，或者你雇佣一个不同的承包商来代替他们。任何在你的团队中运作良好的东西:)