What to use in B's configuration: A or A's configuration?

Question

When I have a class A in a module amod as follows

// module amod

type AConfig = {
  x: number;
  // ...
};

class A {
  constructor(public config: AConfig) {}
  // ...
}

export {A, type AConfig}

and want to decare a class B in a separate module bmod that makes use of A, what would be the better approach?

Approach 1:

// module bmod

import {A, type AConfig} from 'amod';

class B {
  protected _a: A;
  constructor(aConfig: AConfig) {
    this._a = new A(aConfig);
  }
}

Approach 2:

// module bmod

import {type A} from 'amod';

class B {
  protected _a: A;
  constructor(a: A) {
    this._a = a;
  }
}

So far, I always went with approach 2 because it seemed to me as if it only had advantages. For example, I can give the same instance a to multiple instances of B, or use decorators.

However, I now understood that there is also at least one big disadvantage of approach 2: Any module cmod that wants to make use of B must not only depend on bmod but also on amod (to create the instance of A passed to the B constructor), which can easily introduce subtle bugs due to different versions of amod between bmod and cmod and thus requires careful version management. That would not be necessary for approach 1.

Is there a common design for this problem, or at least a best practice?

Answer 1

You are right to be considerate of what dependencies your classes expose.

However, I think you have a similar issue in both cases: In both your approaches, users of B are forced to transitively depend on amod when it seems like you might not want them to.

Instead, consider a trick I often find myself using for design questions like these:
Think of the class you are designing (B) on its own terms, not in terms of other classes it might use. What's actually important to this class on its own? What does it really need? Questions like these can lead you to design with lower coupling and higher cohesion, and to just make more clean and useful classes in general.

Applying those questions to this situation you could get the following answers:

1. "You really need an implementation of A interface in order to create B, where you could use any A implementation. Or you want to compose B through dependency injection of A interface."
2. "You should only need XYZ knowledge to create B, it can deal with its own internal implementation."

.. there may, of course, be more nuanced answers but these are good enough to give you the idea.

If your answer is similar to 1 then passing A to B's constructor is fine, though you could abstract it to make B depend on a A interface instead of concrete A if you want.

If your answer is similar to 2 then just pass the knowledge that B needs to its constructor. Then B is free to use whatever hidden implementation it wants without the user needing knowledge of it.

That knowledge you pass to B could be AConfig (which again may be an interface) but you need to ask yourself if that's really what B needs. Rather you could just pass BConfig data to B and then internally configure A (or whatever) from that data without the user needing knowledge of amod at all.

Hope this gives you a fresh point of view for designing these classes.