- [Eric] The dependency and version principle

- Eric] 依存性とバージョンの原理

gives us guidance to not design our high-level modules

は、高レベルのモジュールを設計しないようにするためのガイダンスを与えてくれます。

to depend on our low-level modules,

を低レベルのモジュールに依存させることができます。

but that sounds counterintuitive,

が、直感に反するような気がします。

because it advises us to think about designs

というのも、デザインについて考えることを勧めているからです。

in a manner that's really the opposite

逆を言えば

of what we're used to.

私たちが慣れ親しんでいるものの中から

We're used to thinking about designs

私たちは、デザインについて考えることに慣れています

as top-down decompositions.

をトップダウンで分解しています。

We take a problem and we factor it

私たちは問題を取り上げ、それを因数分解します。

into a high-level set of components

を上位の構成要素にする

that depend on a lower level set of components.

下位のコンポーネントのセットに依存するもの。

We often think of the high-level components

私たちがよく考えるのは、ハイレベルなコンポーネント

as some kind of policymakers

政策決定者としての

that are commanding a set of low-level components

低レベルのコンポーネントの集合を指令している。

who are really carrying out all the real work.

ということです。

The problem with this approach

この方法の問題点

is that it typically tightly couples

は、通常、緊密に結合していることです。

our high-level components to our low-level ones.

高水準のコンポーネントを低水準のコンポーネントに変換します。

A symptom of this tight coupling

このタイトなカップリングがもたらす症状

is that it's often difficult to take

を取るのが難しい場合が多いということです。

that high-level component and then to go reuse it

そのハイレベルなコンポーネントを再利用するために

with the totally different underlying implementation

全く異なる実装で

of the low-level components.

低レベルコンポーネントの

If our design is right,

私たちの設計が正しければ。

that's something we really should be able to do.

というのは、本当にできるはずなんです。

The dependency inversion principle

依存関係逆転の原理

tells us to think of this in a different way,

は、別の意味で考えろということです。

by reversing the direction of this dependency.

この依存関係の方向を逆転させることで

It tells us really two things.

それは、実に2つのことを物語っている。

First, as we've said, high-level modules

まず、これまで述べてきたように、高レベルのモジュール

should not depend on low-level modules,

は低レベルのモジュールに依存しないようにする必要があります。

actually both should depend on abstractions.

実際には、どちらも抽象的なものに依存するはずです。

And second, the principal offers that abstractions

そして第二に、プリンシパルは、抽象的なものを提供します。

should not depend on details,

は、ディテールに依存してはならない。

actually details should depend on abstractions.

を、実際に詳細が抽象化されたものに依存する必要があります。

Both of these statements require some explanation.

どちらも説明が必要です。

Let's take a look at an example.

一例を見てみましょう。

Consider this remote control class.

このリモコン教室を考えてみましょう。

It has a click method that's called one user indicates

1ユーザーというクリックメソッドを持っています。

they want to control a television.

テレビを操作したい

The remote control depends

リモコンに依存する

on a lower level class call television,

テレビを呼び出す下位クラスで

and that class offers two methods,

で、このクラスは2つのメソッドを提供しています。

turn TV on and turn TV off.

テレビをつける、テレビを消す

So when the user clicks,

だから、ユーザーがクリックしたときに

the remote control click method has the logic to toggle

リモコンのクリックメソッドにトグルするロジックがあります。

between the on and off states by calling the turn TV on

を呼び出すことで、オンとオフの状態を切り替えることができます。

and turn TV off methods respectively.

とテレビの電源を切る方法があります。

So this design looks straightforward enough,

だから、このデザインは素直に見えるんです。

but there is room for improvement.

が、改善の余地がある。

For starters, this remote control controls only televisions

まず、このリモコンで操作できるのはテレビだけです。

and more specifically the television represented

であり、特にテレビはその代表的なものです。

by the concrete television class.

具体的なテレビのクラスによって。

What if we want to control another kind of television

別の種類のテレビを制御したい場合はどうすればよいのか

or even another kind of device with an on-off switch?

あるいは、オン・オフスイッチのある別の種類のデバイス？

It's not hard to notice that we have a high level component,

ハイレベルなコンポーネントを搭載していることに気づくのは難しいことではありません。

our remote control depending directly

当社のリモコンは、直接的に

on a low-level component,

を低レベルのコンポーネントで使用することができます。

the concrete television class.

具体的なテレビ番組のクラス。

So according to our principal, that can't be good.

だから、校長先生に言わせれば、それはよくないことなんです。

But how else would we approach this?

しかし、他にどのようにアプローチすればいいのでしょうか？

Let's think through what the high level policy

ハイレベルなポリシーとは何かを考えよう

for this design should be.

であるべきだと考えています。

What's the high level policy?

ハイレベルなポリシーとは？

Well as Robert Martin,

ロバート・マーティンのようにね。

the originator of this principle says,

この原理の発案者はこう言っています。

"It's the abstraction that underlies the application."

"アプリケーションの根底にあるのは抽象的なものだ"

So, how's this for an improved high-level policy

そこで、ハイレベルな政策の改善について、次のように考えています。

or abstraction, or remote control

または抽象化、または遠隔操作

that can control anything with an on off button,

オン・オフボタンで何でもコントロールできる。

a TV, a light, a sprinkler system, and so on.

テレビ、照明、スプリンクラーなどなど。

Let's express that in our class diagram.

それをクラス図で表現してみましょう。

To do that,

そのためには

we're going to create an abstraction for an on-off device.

今回は、オン・オフのデバイスを抽象化したものを作成します。

More specifically, we're going to create an interface

具体的には、インターフェースとして

on off device that supports two methods,

2つの方式をサポートするオンオフ装置。

turn on and turn off.

をオンにし、オフにします。

Next, we'll have our remote control

次に、リモコンを用意します

depend on that abstraction by composing our remote control

リモコンを構成することで、その抽象性に依存します。

with an on-off device.

オンオフ装置付き

And remember before the remote control dependent

そして、リモコン依存の前に覚えておいてください。

on a concrete type, that television class.

を具体的な型であるテレビジョンクラスで使用します。

So, now a remote control no longer depends

つまり、リモコンはもはや依存しない

on a low level class.

低レベルのクラスで

Instead, it actually depends on an abstraction

その代わり、実際には抽象化されたものに依存しています。

that's that on off device interface.

というのが、そのオン・オフのデバイス・インターフェースです。

This goes the other way too

これは逆もまた真なり

remember that our principal also tells us

校長先生もおっしゃっていることですが

that abstractions should not depend on details,

抽象化されたものは細部に依存すべきではない、ということです。

rather details should depend on abstractions.

というより、詳細は抽象的なものに依存すべきなのです。

Well, let's examine the television class now

さて、今度はテレビ教室を検証してみよう

and notice first that it implements

を実装していることにまず注目してください。

the on-off device interface,

は、オン・オフのデバイス・インターフェースです。

no longer does it expose its proprietary turn TV on

もはや、独自のテレビをオンにすることを公開しない

and turn TV off methods.

とテレビを消す方法。

So rather than our abstraction, the on-off device,

だから、私たちが抽象化した、オン・オフの装置ではなく

depending on the low level details of the television,

テレビの低レベルなディテールに応じて

that is it's turned TV on and turn TV off methods,

つまり、テレビの電源を入れたり切ったりする方法です。

it is the television that is depending

テレビ次第

on the high level of abstraction,

を高い抽象度で表現しています。

that is the turn on and turn off methods

というのがターンオンとターンオフの方法です。

in the on off device interface.

をオン・オフデバイスのインターフェイスで表示します。

So this is often the reverse of how we think of design,

つまり、これはデザインの考え方とは逆のことが多いのです。

but by adhering to the dependency and version principle,

が、依存性とバージョンの原則を遵守することによって。

we really free our high-level components

ハイレベルなコンポーネントを解放します。

from being dependent on the details of low-level components.

低レベルのコンポーネントの詳細に依存しないようにする。

This really helps us avoid rigidity,

これは、硬直化を防ぐのにとても有効です。

fragility and immobility.

脆弱性、不動性

The dependency in version principle

バージョン原則の依存性

tells us that all relationships between components

は、コンポーネント間のすべての関係を教えてくれます。

shouldn't involve abstract classes and interfaces,

は、抽象クラスやインターフェースに関わるべきではありません。

not concrete classes, in doing so helps us design software

具体的なクラスではなく、ソフトウェアの設計を支援します。

that's reusable and resilient to change,

再利用可能で、変化に強い。

because these abstractions allow the details

なぜなら、これらの抽象化により、詳細な

between the components to remain isolated from each other.

を互いに分離しておく必要があります。