オブジェクト指向設計実践ガイドの中身について〜 attr_readerを用いる理由

Question

「オブジェクト指向設計実践ガイド Rubyでわかる進化しつづける柔軟なアプリケーションの育て方」の２章の中身で一点気になった点を質問させてください。

２章では、以下のコードは良くないコードとして紹介されていました。

class Gear
  def initialize(chainring, cog)
    @chainring = chainring
    @cog = cog
  end
end

  def ratio
    @chainring / @cog.to_f     # <-- 破滅への道
  end
end

上のコードではなく、次のようにattr_renderを使ってカプセル化すべきだとあります。

class Gear
  attr_reader :chainring, :cog
  def initialize(chainring, cog)
    @chainring = chainring
    @cog = cog
  end
end

  def ratio
    chainring / cog.to_f
  end
end

このようにする理由として、@cogのインスタンス変数が10箇所で参照されていたとすると、＠cogを修正する必要が生じた場合、修正するために何箇所ものコードを変更する必要があるからとあります。
しかしながら、もし変更するとしてもコード①のinitializeメソッドを修正するだけでやりたい動きができるのではないでしょうか。実際やってみましたが、問題なく動きました。

上のような例の場合、直接インスタンス変数を参照しに行く書き方が良くない理由をご教授いただけたらと思います。
何卒、宜しくおねがいします。

Comments

[Daregada]

`attr_render`ではなく`attr_reader`では?

[shun0211]

誤記ですね、修正しました。もし分かれば回答いただけるとうれしいです。。

[Daregada]

タイトルも修正を(タイトル見て、「ん」と思って覗いたので)

Answer 1

オートマの車を想像するとよいかと思います。

車の速度によって歯車のcogが変わる場合はinitialize一箇所を書き換えるだけでは対応できず
@cogを参照する場所で対応が必要になります。

Answer 2

私もその本を買って勉強中です。
この章で「@cogのインスタンス変数が10箇所で参照されていたとすると、＠cogを修正する必要が生じた場合、修正するために何箇所ものコードを変更する必要がある」と言っているのは、
今は引数から得て@cogに入れた値そのものが使われるが、「@cogを元に演算した結果を使わなければならなくなる場合」が来るかもしれない。その時に修正が大変だ、ということを言ってます。
attr_reader :cog とすることで、otnさんのご指摘の問題が出てきますが、
一方 そうしておいて　 def ratio（および至るところ）で @cogではなく cog を使っておけば その時点で attr_reader を消して、
def cog @cog * (foo? ? FooAjaster : BarAjaster) end
とすれば修正完了

ということを言ってます

その割にはいつまでも attr_reader　が消えないのは、はてな、でありますが。

Comments

[shun0211]

winterboumさん回答ありがとうございます。
お互いがんばっていきましょう！

本題ですが、「@cogを元に演算した結果を使わなければならなくなる場合」には、下のようにすれば変更する部分が一箇所で済むように思うのですが、こちらはなにか問題があるのでしょうか？

def initialize(chainring, cog)
@chainring = chainring
@cog = cog * (foo? ? FooAjaster : BarAjaster)
end

[winterboum]

別のところで、元々の @cog をそのまま使う必要が有る場合に、困ります。

[winterboum]

あと、foo? が初期化時には決まっていないとか変わりうるという場合もこまるな。

[shun0211]

ご回答ありがとうございます！
確かに上のように定義してしまった場合、もう元々の@cogは使えなくなってしまいますね。
一応元々の@cogを使えるようにするために下のように別で定義するということで理解しました。
def cog
@cog * (foo? ? FooAjaster : BarAjaster)
end

Answer 3

@cogのインスタンス変数が10箇所で参照されていたとすると、＠cogを修正する必要が生じた場合、修正するために何箇所ものコードを変更する必要があるからとあります。

しかしながら、もし変更するとしてもコード①のinitializeメソッドを修正するだけでやりたい動きができるのではないでしょうか。

のあたりが具体的に何を言わんとしているのか分かりませんが、
少なくとも後者のコードは、chainring とcogというアクセサメソッドをパブリックに公開してしまっているので、クラス外からも自由に参照でき、カプセル化という観点からは望ましくないです。

クラス内のメソッドで、インスタンス変数を直接アクセスするのか、アクセサメソッド経由でアクセスするのかは、一律に決められる物では無く、ケースバイケースで判断すべき物と思います。
アクセサメソッド経由の場合も、アクセサメソッドをパブリックにするかどうかは慎重な検討が必要です。

Comments

[shun0211]

回答ありがとうございます！
本では、下のようにあり後者のコードを押しているのですが、otn様が言われているカプセル化と本で言っているカプセル化は違うのでしょうか。

>> 変数はそれらを定義しているクラスからでさえも隠蔽しましょう。隠蔽するにはメソッドで包みます。
>> Rubyにはかんたんにカプセル化用のメソッドを作る方法として、attr_readerが用意されています。

[otn]

↑は、言っていることがおかしいですね。
本来の「カプセル化」は、クラスの中に実装に関する情報を閉じ込めて、クラス外からアクセス出来なくすることです。クラス外からはインターフェース仕様に従ったアクセスのみ認める。
この人は、「@変数名」を直接書かないことをカプセル化と言っているようです。

安易にアクセサメソッドを作って、インスタンス変数の値をクラス外から直接アクセス出来るようにすることはカプセル化に反します。

[winterboum]

「attr_reader を使ったカプセル化」ですが、何で読んだか思い出せませんが、attr_reader自身を言ってはおらず、カプセル化のための準備の様な意味合いで有ったように思います。
同じクラス内なら インスタンス変数でアクセス出来るわけですが、インスタンス変数そのものではなく、演算するとか、他のモデルからの摂りこみなどに修正するなどの変更時に、予め attr_readerしておいて、@cogではなくcogを使っておけば、def cog でカプセル化するのが容易にできる
というような趣旨であったと思います

[otn]

回答に書いたのですが、
> クラス内のメソッドで、インスタンス変数を直接アクセスするのか、アクセサメソッド経由でアクセスするのかは、一律に決められる物では無く、ケースバイケースで判断すべき物と思います。アクセサメソッド経由の場合も、アクセサメソッドをパブリックにするかどうかは慎重な検討が必要です。

細かい話をすると、同一クラス内のメソッドにも、インスタンス変数を使った実装その物のメソッドと、それらとやや縁遠いメソッドがあり得ます。
「インスタンス変数とやや縁遠いメソッドにおいては、クラス外のメソッドに準じてインスタンス変数を直接アクセスしないことにしましょう」というのは妥当な考えです。
つまり、ケースバイケースということです。

少なくとも、後者のために「パブリックな」アクセサメソッドを定義するのは間違っています。

[winterboum]

＞少なくとも、後者のために「パブリックな」アクセサメソッドを定義するのは間違っています。
ここは同意です。
便利なのでつい使ってしまいますが。。。

[shun0211]

横からすいません。
インスタンス変数と縁遠いメソッドとはどのようなメソッドなのでしょうか？

[otn]

イメージできなければ、そのコメントは忘れてください。
要はケースバイケースで、メソッドごとにやり方を考えるべきと言うことです。