on 26-Jun-2020 (Fri)

Much of what we’re trying to accomplish with DI is related to the Dep Inversion Principle.
This principle states that higher-level modules in our applications shouldn’t depend on lower-level modules; instead, modules of both levels should depend on Abstraction

Not only does the principle prescribe loose coupling, it states that Absctraction should be owned by the module using the Abstraction.
In this context, “owned” means that the consuming module has control over the shape of the Abstraciton , and it’s distributed with that module,
rather than with the module that implements it.
The consuming module should be able to define the Abstraction in a way that benefits itself the most.

When you write loosely coupled code, you create many classes to create an applica- tion.
It can be tempting to compose these classes at many different locations in order to create small subsystems,
but that limits your ability to Intercept those systems to modify their behavior. Instead, you should compose classes in one single area of your application.

When you look at Constructor Injection in isolation, you may wonder, doesn’t it defer the decision about selecting a Dep to another place?
Yes, it does, and that’s a good thing. This means that you get a central place where you can connect col- laborating classes.
The Comp Root acts as a third party that connects consumers with their services.
The longer you defer the decision on how to connect classes, the more you keep your options open.
Thus, the C R should be placed as close to the application’s entry point as possible.

Assemblies are a deployment artifact: you split code into multiple assemblies to allow code to be deployed separately.
An architectural layer, on the other hand, is a logical artifact: you can group multiple logical artifacts in a single deployment artifact.
Even though the assembly that holds both the C R and the UI layer depends on all other modules in the system, the UI layer itself doesn’t.

As an example, the Control Freak anti-pattern happens when you create a new instance of a Volatile Dep by using the new keyword.

Every time you create a Volatile Dep , you explicitly (using new KW) state that you’re going to control the lifetime
of the instance and that no one else will get a chance to Intercept that particular object.

The most blatant example of Control Freak is when you make no effort to introduce Abstraction in your code.

Don’t conclude from this section that we generally oppose the use of Concrete Factory classes.

A Concrete Factory can solve other problems, such as code repetition, by encapsulating complex creation logic.

It, however, doesn’t provide any value with regards to DI. Use it when it makes sense.

Mary and Jens’ static ProductRepositoryFactory reads from the configuration file at runtime, but recall from section 2.3.3 that this is problematic:
Only the finished application should rely on configuration files. Other parts of the application, such as the ProductRepositoryFactory , shouldn’t request values from a configuration file but, instead, should be configurable by their callers

CommerceContext loads the connection string from a configuration

file — this is a trap. It causes every new CommerceContext to read the configuration

file, even though the configuration file typically doesn’t change while

an application is running. A CommerceContext shouldn’t contain a hard-coded

connection string, but neither should it load a configuration value from the

configuration system.

Mary loaded the connection string from the configuration file from within the CommerceContext

class (shown in listing 2.2). From the perspective of its consumers, the

dependency on this configuration value is completely hidden. As we alluded to

when discussing listing 2.2, this implicitness contains a trap.

Although the ability to configure a compiled application is important, only the

finished application should rely on configuration files. It’s more flexible for reusable

libraries to be imperatively configurable by their callers, instead of reading

configuration files themselves. In the end, the ultimate caller is the application’s

entry point. At that point, all relevant configuration data can be read from a configuration

file directly at startup and fed to the underlying libraries as needed.

We want the configuration that CommerceContext requires to be explicit.

Assembly dependencies are in fact transitive.

Remember, though, that dependencies aren’t defined by the number of modules, but the number of times each module depends on another module.