Chapter 3: Manging Dependencies

Question 1

When does an object depend on another object?

Answer 1

When one object changes, the other might be forced to change in turn.

Question 2

When does an object have a dependency?

Answer 2

Following this code: https://github.com/efrapp/design-principles/blob/ch-3/gear.rb

An object has a dependency when it knows:

• The name of another class. Gear expects a class named Wheel to exist.
• The name of a message that it intends to send to someone other than self. Gear expects a Wheel instance to respond to diameter.
• The arguments that a message requires. Gear knows that Wheel.new requires a rim and a tire.
• The order of those arguments. Gear knows that Wheel takes positional arguments and the first should be rim, the second, tire.

Question 3

How do we solve the “explicit reference to another class” problem?

Answer 3

Instead of hard-code a reference to a class we can inject that reference as a dependency.

Question 4

What technique do we use to solve the “explicit reference to another class” problem?

Answer 4

Dependency Injection.

Question 5

What are the consequences to use an “explicit reference to another class”?

Answer 5

1. If the name of the referenced class change we need to change any code where were we are referencing that class
2. We are declaring that we can collaborate ONLY with the class we are explicitly referring to. If in the future we need to collaborate with another kind of object, we can’t, even if that object has the qualities needed to do it.

Question 6

What can we do when we can’t remove a dependency from our code?

Answer 6

We can isolate it.

Question 7

What are the techniques to isolate a dependency?

Answer 7

• Isolate Instance Creation

- Isolate Vulnerable External Messages

Question 8

How does the “Isolate Instance Creation” work?

Answer 8

When we can’t inject a dependency due to constrains in the app we can explicitly expose the dependency. For this we can use:

• move the dependency to the initialization method in the class we’re referecing it.
• move the dependency in its own explicitly defined method. This new method lazily creates a new instance of the dependency using the Ruby’s ||= operator.

Question 9

How does the “Isolate Vulnerable External Messages” work?

Answer 9

This technique deals with the "messages that are sent to someone other than self" problem. For this, we can remove the external dependency and encapsulate it in a method of its own.
This technique becomes necessary when a class contains embedded references to a message that is likely to change.

Question 10

What are positional arguments?

Answer 10

They are arguments with an specific, fixed position in the definition of a function/method.

Question 11

Why do positional arguments are bad?

Answer 11

Because, if for some reason, the order of them changes in the definition of the method, all the senders of it will be forced to change in turn.

Question 12

How do we solve the positional arguments dependency?

Answer 12

If we have control of the definition of the method, we can use keyword arguments.

Question 13

How do we deal with positional arguments in an external interface?

Answer 13

We don’t always have the opportunity to control the signature of the method, like external interfaces. For this, we can wrap the external method with one controlled by us and supply keyword arguments.

Question 14

What is a factory?

Answer 14

An object whose purpose is to create other objects.

Question 15

What is the dependency direction?

Answer 15

Dependencies always have a direction. The direction means who depends on who.

Question 16

What are the three truths about code related to changes?

Answer 16

• Some classes are more likely than others to have changes in requirements
• Concrete classes are more likely to change than abstract classes
• Changing a class that has many dependents will result in widespread consequences.

Question 17

How the likelihood of change affect the direction of the dependency?

Answer 17

Every class in an application has a rank of how likely it is to undergo a change compared with others, this can be a class written by you, a base class of the language, or a class in a framework. This rank is a key point to consider when choosing the direction of dependency.

Question 18

Why does an abstraction is more reliable than a concrete class?

Answer 18

Abstraction is always safer than depending on a concretion because by its very nature, the abstraction is more stable.

Question 19

What are the zones derived from the intersection of Dependents and Likelihood of change thrusts?

Answer 19

• Zone A (Abstract zone): classes that have little likelihood of change but contain many dependents. Abstract classes ought to be here.
• Zone B (Neutral zone): classes rarely change and have few dependents.
• Zone C (Neutral zone): opposite to zone A, these classes tend to be more concrete, which make them more likely to change but few classes depend on them.
• Zone D (Denger zone): it is the danger zone because changes are costly. They have many dependents and more likelihood of change.