Question

A类需要B类的实例。我应该在A构造函数中创建B实例，还是在启动类A的情况下创建实例并将实例传递给A构造函数？

计划A：

"\"

计划B：

class A { constructor() { this.b = new B(); } }

Answer 1

您的计划B绝对是更好的方法，因为它可以使您的class A更灵活，并且消除了对class B的工作方式的依赖。

Answer 2

如果A

将来不应将B类替换为C类
B类未使用某些外部依赖项，例如ajax或数据库或其他东西。

OR

您的应用程序是概念证明，或者您确实有时间限制

计划B在所有其他情况下都很好。

它将为您带来快速更改A类行为的灵活性，赋予更多通用性，并通过模拟此依赖项来帮助进行测试。

所以我要说计划A与简单有关，计划B与灵活性和测试有关。在每种情况下选择所需的任何内容

希望这会有所帮助。

Answer 3

第一种策略是合适的，因为这两个类之间的关系彼此无关，它们之间没有确切的形式，并且子实例没有特殊的特征，否则这些特征会使手动提供它们有任何好处。

后一种注入类的依赖关系的策略要灵活得多。这在一种类型化的语言中更加明显，在这种语言中，您可以清楚地定义描述对象“看起来”的类而不是实际实现的类抽象或接口，例如使用TypeScript：

class Process {
  private storage: StorageInterface;

  constructor(storage: StorageInterface) {
    this.storage = storage;
  }
}

interface StorageInterface {
  store(data: any): Promise<void>;
}

很明显，Process期望提供功能store的对象的实例，但是它并不关心实际实现是什么样子-取决于实现{ {1}}：

StorageInterface

现在，我们对于希望使用class PostgresStorage implements StorageInterface { public async store(data: any): Promise<void> { // do some postgres query } } class FilesystemStorage implements StorageInterface { public async store(data: any): Promise<void> { // store in the filesystem } }实例的“存储”类型具有完全的灵活性，而不是它自己管理它可以使用的存储，它具有创建无限存储类型而无需修改的能力代码库的其余部分，以及Process与之交互的内容更加清晰。

Process

Answer 4

在JS世界中，面向对象方法与强类型经典语言中的方法有些不同。也许平台的这种改变是一个很好的机会，可以回顾您关于如何重用的心态，并在考虑构图的同时进行更横向的思考。

https://en.wikipedia.org/wiki/Composition_over_inheritance

ES6类和类实例作为构造函数中的参数

4 个答案: