見出し画像

【オブジェクト指向】データを隠蔽しよう(dataと@dataってなんで使い分けるの?)

今回は、社内でオブジェクト指向についての勉強会を行うことになりましたので、その内容を残します。

「オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方」2−3章の内容を扱っています。

個人的にはとてもおすすめな一冊です。(現在第8章で読破はまだですが。)

では、見ていきましょう。

今回は「変更を歓迎するコードを書く」についての内容です。

1 変更を歓迎するコードを書こう!

「コードは必ず変更される」(Code will be changed)という言葉をよく聞きます。

コードは基本的に無常なので、変更に強いコードを書く必要があります。

では、どうすれば変更に強いコードになるのか。

この本によると「データではなく、振る舞いに依存する」ことで変更に強いコードが作れるようです。

具体的にはどういうことでしょう?

実際に見てみましょう。

2 インスタンス変数の隠蔽について

インスタンス変数というデータに依存しないことで、変更に強いコードを作れます。

そのために、データはラッパーして隠蔽していくことになります。

まだ、いまいちピンとこないですね。

2ー1 変数の参照方法について(直接か間接か)

Rubyでデータを参照する際、下のように、

直接参照(下の例だと@cog)
ラッパーしたものを参照(下の例だとcog)

することができます。

でも、これって何が違うんでしょう?

結局どっちも10を取ってきますよね。

ちなみに、コグって自転車のこの部分のことみたいです。

https://jitensha-biyori.jp/other/7733/


2ー2 データに依存した場合

では、下のように、直接参照をして、いくつかのメソッドを作ってみましょう。

一見問題はなさそうですし、実際ちゃんと動きます。

これだと、変更に弱いんです。

例えば、何かの変更で、計算の際にはcogの値を1.1倍したものを使わなければならないとしたらどうでしょう?

下のように、全てのメソッドで変更が必要になってきます。

大変ですし、漏れもありそうですね。

これがデータに依存した場合です。

2ー3 振る舞いに依存した場合

次は、メソッドを使った場合です。

特に何もなければ、下のように、「@cog」を使った時とほとんど変わりませんね。

では、先ほどと同様の変更が出てきたらどうでしょう。

「cog」は振る舞いなので、下のように振る舞いの定義をしている部分だけを変えれば良いわけです。

これなら変更にも柔軟に対応できますね。

でも、1.1倍にするくらいなら直接参照でもさほど変更は大変ではないかもしれません。

置換すれば良いですしね。

では、もっと複雑に、「_の場合は1.1倍、bの場合は1.2倍」になったらどうでしょう。

そんな場合も、メソッドで行っていた場合には、やはり簡単に変更ができてしまいますね。

このように、振る舞いに依存すると、変更が簡単になりましたね。

3 データ構造の隠蔽について

では次に、データ構造の隠蔽について考えていきましょう。

配列などのデータ構造に依存すると、どんな問題点があるのでしょう。

下のような、配列とそれを格納するメソッドがあるとします。

3−1 データ構造に依存した場合

上の例では、「diameter」のメソッドはdata[0]にリムが入っており、data[1]にタイヤのサイズが入っていること(データ構造)知っています。

つまり、依存関係にあります。

なお、リムタイヤは次のような場所のようです。

https://www.kokusen.go.jp/news/data/n-20181107_2.html

もしデータ構造が変わって、タイヤがdata[2]に格納されるようになったらどうでしょう。

変更するのは大変そうですね。

3ー2 振る舞いに依存した場合

では、振る舞いに依存させてみましょう。

下のように構造体Struct使うのが良いようです。

これで、例えばwheel.rimdata[0]の値を参照できるようになりました。

第2章と状況は同じですね。

これによって、各メソッドは何番目に何が入っているのかを知る必要がなくなりました。

依存関係がなくなりましたね。

また、もし仮にタイヤがdata[2]に格納されることになっても、構造体に入れる部分のみ変更すれば良いですね。

これで変更に強いコードになりました。


いかがだったでしょうか。

今回は以上となります。

サポートをしていただけたらすごく嬉しいです😄 いただけたサポートを励みに、これからもコツコツ頑張っていきます😊