コンポジションのgetter連鎖

Question

よろしくお願いします。

現在、クラス設計を行っています。

has-aの関係が多かったので、コンポジションを多く使いました。
例えば、下記のようなクラス構成だったとします。

Houseクラス
 ┗Bathroomクラス
   ┗Bathクラス
     ┗Waterクラス
       ┗temperatureフィールド

この時、Houseインスタンスからtemperatureフィールドの値を取得しようとすると、Getterの嵐になってしまうのですが、これは設計としては普通でしょうか？
わかりにくくて申し訳ありません。

Getterは出来るだけ定義したくないという思想で設計をしたかったので、不安です。
ご教示をよろしくお願いします。

Answer 1

あまりプログラムの事情もわからずに設計の良し悪しは申し上げられませんが、お気付きの通り良くない設計です。
何が良くないかというと、Getterだらけになることそのものではありません。Getterだらけになっているのは結果です。

この例だと、「お風呂の水温」を家の外側で取得しなければいけないことがすでに設計の誤りです。
家を与えられたとき、その家のお風呂の水温を使って何かする処理、というのを家の外側で書かないといけないのが抽象化不足なのです。
処理そのものをお風呂の中に、家の中に、閉じ込められませんか？
もっと大きな処理要求を家にメソッドとして持たせるようにできませんか？

動作状況のログを取るような目的だとそうも言っていられなかったりしますが。

Comments

[yuba]

この設計ポリシーをデメテルの法則と呼びます。

[退会済みユーザー]

デメテルの法則、初めて聞きました。心に留めておきます。
確かに、家の外からお風呂の温度がわかったところで、利用することは出来ません。
今一度、見なおしてみます。
ありがとうございました。

Answer 2

こんにちは。

Getterの嵐になってしまう

この嵐ですが、下記イメージでしょうか?

house.getBathroom().getBath().getWater().getTemplature();

もし、YESなら、これでは情報の隠蔽になりません。正にGetterの暗黒面に該当すると思います。
もし、houseの外から、風呂の温度を取得する必要があるのなら、

house.getBathTemplature();

だと思います。

そして、実は、風呂の温度を家の外から取得できると言うことは、風呂桶には温度計が付いていて、Bathroomもしくは、Houseの中にお風呂のコントローラが設置されていると思います。
つまり、温度は温度計が計測し、その温度情報は風呂の水の中にあるのではなく、お風呂のコントローラが保持している姿になるケースが多いように感じます。

つまり、house.getBathTemplature()は、Houseに含まれるBathControllerからお湯の温度を獲得するわけですね。
更にどちらかと言うと、getBathTemplature()で取得できる値は設定温度で、他に風呂の温度が規定範囲内か外かのフラグを返す関数が別途ある印象を受けます。

要するに、yubaさんの見解に賛成です。

---

【追記】
iwamoto_takaakiさんへのコメントを見て追記しています。

PNG画像データは構造を持っていますね。その各構造をオブジェクト指向的なクラスとして実装するのは間違いと私は考えています。
「PNG画像データに何かメッセージを送って何らかの処理をさせる」がオブジェクト指向的な発想ですね。
しかし、PNG画像データは単にデータに過ぎず、自律的に何かの処理を行うのは違和感が強いです。

そのようなデータを保持することが主目的な構造データは「構造体」です。
それは、全てのデータはpublicフィールドで保持し、メソッドはコンストラクタくらいしか持たないものをイメージしています。

そのように考えるとすっきり設計できるのではないでしょうか？
逆に、この概念を排除すると、今回悩まれているようにPNG画像データのような多少複雑な構造を持つデータのハンドリングが悩ましくなります。

Comments

[退会済みユーザー]

house.getBathroom().getBath().getWater().getTemplature();
まさしく、そのイメージです。

BathControllerですね。まさしく、うちにも付いています。
has-aの関係しか見ず、実際の相対関係が見えていませんでした。浅はかでした。
今一度、設計を見なおしてみます。
ありがとうございました。

[退会済みユーザー]

遅くなり申し訳ございません。
追記をいただきありがとうございます。
お教え頂いたとおり、構造体を使って設計をやり直しております。
なんとか、png.frameset(idx).GetBitmap(x,y)ぐらいまでに収めることができました。
ツールの構造上、「どのPNGファイルの、どのフレームの、どこの座標の」までの
紐付きが必要のようなので、ここらへんが限界のようです、、、
最後までご教授をいただきありがとうございました。
元々はHouseクラスについての質問だったので、
誠に勝手な私見となってしまいますが、
一番具体的に歩を進めることができましたので、ベストアンサーにさせていただきます。

Answer 3

知りたいのは”お風呂の温度”ですよね。だったら、Bath．getWaterTemparature（）で取得出来るべきかなと思います。当然お湯がなかったら、NoWaterExceptionが帰ってきます。

私は実際のコードが言語に近いほうが、良い設計だと思います。

オブジェクト指向を学ぶ際は、実行可能なコードを書くことを強くおすすめします。概念的になりすぎて、実際のコードに反映出来ないのであれば、オブジェクト指向のコードの勉強として意味が無いです。（実際のプログラムでは無いですよね？念のため・・・）

Comments

[退会済みユーザー]

おっしゃるとおり、Waterにgetterがあるのはおかしいと感じます。
また、Waterがない場合もありますね。それはBathが知っているべきでした。
ありがとうございました。

こちらは、実際のプログラムではないです。わかりやすい例えを考えて、
辿り着いた先がHouseとtemperatureでした・・・

実際のプログラムは、PNG画像の情報を表にまとめるツールを作っているのですが、

PNG
　┗Chunk
　　　┗ColorData
　　　　　┗RED(RGBのうちの１つ)

このPNGインスタンスを生成して、外からREDの情報を取得しようとしたとき、
どうしてもgetterが汚くなってしまったので、ご相談をさせていただきました。

[iwamoto_takaaki]

それなら、getter自体は仕方が無いかもしれません。
自然言語にすると”このPNGのこのchunkのREG”見たいな指定でしょうか。

ただし階層が深すぎるときは呼び出し側でメソッドを分割することを考えた方がいいかもしれません。呼び出し側のコードがわからないのでどのように分割すると綺麗なのか提案出来ませんが、やはりわかりやすい名前がつく範囲に分割することをおすすめします。

[退会済みユーザー]

遅くなり申し訳ございません。
コメントをありがとうございます。
下記でChironianさんからコメントいただきました、構造体を
使っての設計を行っております。
png.frameset(idx).GetBitmap(x,y)ぐらいまでに収めることができました＾＾；

Answer 4

"この時、Houseインスタンスからtemperatureフィールドの値を取得しようとする" 用途が多ければ非常に使いづらいので、別途Utiltilyを作成して簡単に属性を取得できるクラスを設けるくらいでしょうか。

アクセサメソッドが多くなってしまう問題とクラス階層が深くなってしまう話はそこまで密接な関係ではないように思えますし、あまりに煩雑だと思うのであればCommons-OGNLのようなライブラリを使うなどで回避するでしょう。

DataTransferObjectのような、属性の出し入れしか提供しないクラスであれば、つけてもつけなくても一緒です。

Comments

[退会済みユーザー]

Commons-OGNLやDataTransferObjectなど、
初めて聞きました。
申し訳ありません。心に留めておきます。
実は、家の外からさらにWaterの量やBathの広さ等、
色々取得しようとしています。
Utilityも検討いたします。
ありがとうございました。