Suppose I have MasterPackage
containing a Master
class, and BlasterPackage
containing Blaster
class. Since Master
needs a Blaster
to work, the higher level MasterPackage
depends directly on lower-level BlasterPackage
.
Using classic Dependency Inversion, one would add IBlaster
(or AbstractBlaster
) to MasterPackage
, thus inverting dependency between the packages.
But while facing this problem, I realized I could create a third package - let's name it MasterBlasterInterfaces
- and put IBlaster
there. That would "delegate" the dependency to that third, common package, and the original two packages would be now decoupled from one another.
But then, if I have a higer-level package called ThunderDome
, it will have to deal directly with BlasterPackage
, wouldn't it? I feel like it sort of violates encapsulation, while with direct dependency Master
could possibly abstract away the very existence of Blaster
.
So the question is:
Is there a good set of criteria to choose between inversion vs. delegation of dependencies? And how one vs. other impacts use of the packages by higher-level application layers?