DI

Question 1

On-demand approach

Answer 1

In the on- demand approach, whenever a consumer needs a new object-under-construction, the consumer creates or finds the dependencies needed by the object-under-constructionat the time the consumer instantiates the object-under-construction. In other words, the consumer is responsible for gathering all dependencies and is responsible for providing those dependencies to the object-under-construction via the initializer, a stored- property or a method.

Question 2

What are ephemeral dependencies?

Answer 2

they’re created and destroyed alongside the object-under-construction.

dependencies that can be instantiated at the same time as the object-under-construction

Question 3

On-demand approach, Initializing ephemeral dependencies

If dependencies don’t need to live longer than the object-under-construction, and can therefore be owned by the object-under-construction, then

Answer 3

the consumer can simply initialize the dependencies and provide those dependencies to the object-under- construction. These dependencies are ephemeral dependencies because they’re created and destroyed alongside the object-under-construction.

Question 4

Initializing ephemeral dependencies On-demand approach

Answer 4

Consumer know that concrete implementation of dependencies for object-under-construction.

object-under-construction doesn’t know it, because it uses protocol types for dependencies

Question 5

Pros of the on-demand approach

Answer 5

This approach is relatively easy to explain and relatively easy to understand.

Your code is testable because you can substitute nondeterministic side effect dependencies with deterministic fake implementations.

You can defer decisions. For example, you can use an in-memory data store implementation while you decide on a database technology. Changing from the in- memory implementation to the database implementation is easy because you can find all the in-memory instantiations and replace them with the database instantiations. This can be a bit tedious, so this is also a con that’s addressed in more advanced approaches.

• Your team can work on the same feature at the same time because one developer can build an object-under-construction while another builds the dependencies. The developer building the object-under-construction can use fake implementations of the dependencies while the other developer builds the real implementations of the dependencies.

Question 6

Cons of the on-demand approach

Answer 6

Dependency instantiations are decentralized. The same initialization logic can be duplicated many times.

Consumers need to know how to build the entire dependency graph for an object- under-construction. Dependencies can also have dependencies and so on. The consumer might have to instantiate a lot of dependencies. This is not ideal because multiple consumers using the same object-under-construction class will have to duplicate the dependency graph instantiation logic.

Question 7

Instantiating dependencies on-demand is a decentralized approach that

Answer 7

doesn’t scale well.

Question 8

The factories approach is all about centralizing

Answer 8

dependency instantiation.

Question 9

One goal of creating a factories class is to make it possible

Answer 9

for consumers to create objects-under-construction without having to know how to build dependency graphs required to instantiate objects-under-construction.

Question 10

Creating and getting transitive dependencies

Answer 10

To create an ephemeral transitive dependency, a dependency factory method can simply call another dependency factory included in the factories class.

Question 11

To get a reference to a long-lived transitive dependency, a dependency factory method should

Answer 11

include a parameter for the transitive dependency. By adding parameters, long-lived transitive dependencies can be provided to the dependency factory method.

Question 12

Resolving protocol dependencies

Answer 12

Dependency factory methods typically have a protocol return type to enable substitutability. When this is true, dependency factory methods encapsulate the mapping between protocol and concrete types. This is typically called resolution because a dependency factory method is resolving which implementation to create for a particular protocol dependency. In other words, these methods know which concrete initializer to use.

Question 13

Object-under-construction factory methods

Object-under- construction factory methods look just like dependency factory methods. The only difference is

Answer 13

object-under-construction factory methods are called from the outside of a factories class, whereas dependency factory methods are called within a factories class.

Question 14

Getting runtime values factory approach

Answer 14

These runtime values are typically called runtime factory arguments. As the name suggests, you handle this situation by adding a parameter, for each runtime value, to the object-under-construction’s or dependency’s factory method. At runtime, the factory method caller will need to provide the required values as arguments.

Question 15

Injecting factories goal

Answer 15

The goal is to be able to unit test an object-under-construction without needing the factories class at all.

Question 16

You can give this power to objects-under-construction from the outside using one of two Swift features:

Answer 16

closures or protocols.

Question 17

Using closures to give this power to objects-under-construction from the outside

Answer 17

Here are the steps:
Declare a stored-property in the object-under-construction with a signature such as:let makeUseCase: () -> UseCase.

Add an initializer parameter to the object-under-construction with the same closure type.

Go to the factories class and find the factory method that creates the object-under- construction.

Use initializer injection, in the object-under-construction factory method, to inject a closure that creates a new dependency. To do this, open a closure in the object- under-construction’s initializer call. Inside the closure, call the dependency factory method for the dependency in question and return the new instance. The closure captures the factories class instance so the object-under-construction essentially holds on to the factories object without knowing.

Now, the object-under-construction can easily create a new instance of a dependency by invoking the factory closure, whenever.

Question 18

Give this power to objects-under-construction from the outside by using protocols

Steps

Factory approach

Answer 18

Here are the steps:
Declare a new factory protocol that contains a single method for the dependency that the object-under-construction needs to create.
The factories class will already conform to this protocol because the dependency factory method in the protocol should match the implemented factory method in the factories class. Simply declare conformance in the factories class.
Add a stored-property and initializer parameter of the factory protocol type to the object-under-construction. This allows you to inject the factories object into the object-under-construction; however, the object-under-construction will only see the single factory method defined in the protocol. The object-under-construction does not know it is injected with the factories object because the protocol restricts the object-under-construction’s view.
Go into the object-under-construction’s factory method in the factories class and update the initialization line to inject self. self is the factories object which conforms to the new factory protocol you declared.

Question 19

Stateless class means

Answer 19

that class don’t have any stored properties and can have all methods static

Question 20

Pros of the factories approach

Answer 20

Ephemeral dependencies are created in a central place. This gives you a lot of power to switch out entire subsystems by changing a couple of lines of code.
Substituting a large amount of dependencies during a functional UI test is much easier because all your dependencies are initialized in one class. Developers typically want to fake out the entire networking and persistence stack during UI tests because developers want deterministic tests so their builds don’t constantly break with false positives.
Consumers are more resilient to change because they no longer need to know how to build dependency graphs. That’s one less responsibility for all consumers. This helps your team work in parallel because code is more loosely coupled.
Code is generally easier to read because all of the initialization boilerplate is moved out of the classes that do interesting work.

Question 21

Cons of the factories approach

Answer 21

In a large app, a single factories class can become extremely large. You can break up large factories classes into multiple classes.

This approach only works for ephemeral objects. Longer-lived objects need to be held somewhere. Ideally, all dependencies should be centrally managed regardless of lifespan. You’ll learn how to do this in the next section.

Question 22

Single-container approach

A container is like a

Answer 22

factories class that can hold onto long-lived dependencies. A container is a stateful version of a factories class.

A container class looks just like a factories class except with stored properties that hold onto long-lived dependencies

Question 23

Ways to store properties in single container approach

Answer 23

You can either initialize constant stored properties during the container’s initialization or you can create the properties lazily if the properties use a lot of resources.

However, lazy properties have to be variables so constant properties are better by default.

Question 24

Dealing with long-lived properties in

factory vs container approaches

Answer 24

To get a reference to a long-lived transitive dependency, a dependency factory method simply gets the dependency from a stored property.

in factory: add a parameters to factory methods.

Question 25

Object-under-construction factory methods in container approach

Answer 25

Just like dependency factory methods from above, these factory methods also don’t need to have parameters for long-lived dependencies. This is a huge benefit for consumers because consumers don’t have to manage anything in order to create objects-under-construction.

Question 26

Substituting long-lived dependency implementations

Answer 26

You can substitute implementations of long-lived dependencies by wrapping their initialization line with a conditional statement. This is possible as long as the long- lived stored properties use a protocol type.

Question 27

Creating and holding a container

Answer 27

Unlike factories, you should only ever create one instance of a container.

Question 28

Pros of the single-container approach

Answer 28

A container can manage an app’s entire dependency graph. This removes the need for other code to know how to build object graphs.
Containers manage singletons; therefore, you won’t have singleton references floating in global space. Singletons can now be managed centrally by a container.
You can change an object’s dependency graph without having to change code outside the container class.

Question 29

Cons of the single-container approach

Answer 29

Putting all the long-lived dependencies and all the factory methods needed by an app into a single container class can result in a massive container class. This is the most common issue when using DI. The good news is that you can break this massive container up into smaller containers. You’ll read about this in the next section.

Question 30

Object scopes for DI containers

Answer 30

Every object has a lifetime. You want to explicitly design when objects come and go.

Question 31

Type of object scopes for DI containers

Answer 31

App scope
User scope
Feature scope
Interaction scope

Question 32

App scope

Answer 32

Traditional singletons fall under this scope. Objects in the app scope are created when the app launches and are destroyed when the app is killed. Typical dependencies you find in this scope include authentication stores, analytics trackers, logging systems, etc.

Question 33

User scope

Answer 33

User scope objects are created when a user signs in, and they’re destroyed when a user signs out. Some apps allow users to sign in to multiple accounts. In this case, the app could have multiple user scopes alive at the same time. Most dependencies, such as remote API’s and data stores, are usually found in this scope. This scope also typically contains more specific versions of dependencies found in the app scope. For instance, the app scope could have an anonymous analytics tracker while a user scope could have a user specific analytics tracker.

Scopes are very powerful because they help convert a bunch of mutable state into immutable state. For that reason, you can go even further with scopes by designing shorter lived scopes.

Question 34

Feature scope

Answer 34

Objects in a feature scope are created when the user navigates to a feature and are destroyed when the user navigates away. Feature scopes are handy when a feature needs to share data amongst many objects that make up the feature.

Question 35

Interaction scope

Answer 35

Objects in an interaction scope are created when a gesture is recognized and are destroyed when the gesture ends. This is handy when you are building a complex user interaction. This is an example of a very short-lived scope.

Question 36

Container hierarchy

Answer 36

A container manages the lifetime of the dependencies it holds. Because of this, each scope maps to a container.

This is how the dependencies that are in the user scope are all created and destroyed at the same time, because the scoped container owns these objects.

Question 37

Designing a container hierarchy

There’s one simple rule to building container hierarchies:

Answer 37

A child container can ask for dependencies from its parent container including the parent’s parents and so on, all the way to the root container. A parent container cannot ask for a dependency from a child container.

Question 38

The container hierarchy is

Answer 38

an object graph itself; therefore, you can use initializer injection to provide child containers with parent containers.

Question 39

Child container vs parent container

How they interact with each other?

Answer 39

The child container’s initializer needs to have a parameter for the parent container. The child container can then hold a reference to the parent container in a stored-property. This gives the child access to all the factory methods and stored properties in the parent container.

Question 40

Capturing data and handling optionals in container hierarchies

Answer 40

Besides managing the lifetime of dependencies, a container can also capture data model values. This is extremely helpful if the data model value is immutable for the lifetime of the container. Capturing data in a container is a way to convert mutable values into immutable values. This makes the code inside a container more deterministic because the logic does not have to consider a change in the captured value.

Question 41

Pros of the container hierarchy

Answer 41

Scoping allows you to design dependencies that don’t have to be singletons.

By capturing values in a scope, you can convert mutable values into an immutable values.

Container classes are shorter when you divide container classes into scoped container classes.

Question 42

Cons of the container hierarchy

Answer 42

Container hierarchies are more complex than a single-container solution. Developers that join your team might encounter a learning curve.

Even when containers are broken up into scoped containers, complex apps might still end up with really long container classes.