第7章 カプセル化

モジュールとして分割するべきかを決める基準として、最も大事なことは他の部分から隠蔽すべき秘密を持っているかどうか

レコードのカプセル化

レコード構造はプログラミング言語の一般的な機能
関連するデータを一緒にグループ化して、緩いデータの群れの代わりに、意味のあるデータ単位を提供する
しかし、単純なレコード構造には、レコードに格納されている値と計算した値の明確な区別を共用されるなどの欠点もある

変更可能なデータなら、オブジェクトにする方が良い

手順

コレクションのカプセル化

コレクションの変数へのアクセスはカプセル化していても、getterがコレクションそのものを返してしまうと、コレクションを保持するクラスを介さずにその中身を変更できてしまう

一般的な解決方法は、取得用のメソッドを用意しそれにコピーを返すようにすること

手順

オブジェクトによるプリミティブの置き換え

単純な表示以上のことをするなら、ちょっとしたデータでもクラスにするべき

手順

問い合わせによる一時変数の置き換え

変数の代わりに関数を使うことで、似通った関数で計算ロジックが重複するのを防げる
問い合わせによる一時変数の置き換えに適した一次関数はほんの一部に限られる

手順

クラスの抽出

手順

クラスのインライン化

クラスが役割を終えて、存在価値がなくなったときに行う
他には2つのクラスをリファクタリングをして特性の配置を変えたいとき
この場合は、一つのクラスにまとめてからクラスの抽出を行う

手順

委譲の隠蔽

委譲先のオブジェクトがインターフェースを変更すると、呼び出し元のオブジェクトも変更する必要がある
これらの依存関係を断ち切るために、委譲先オブジェクトを隠すための委譲用メソッドを作る

手順

仲介人の除去

委譲の隠蔽を使いすぎると、オブジェクトはただの仲介人になってしまう
その場合、仲介人の除去で消す

手順

アルゴリズムの置き換え

アルゴリズムに手を加えて動作を少し変えたいとき、まずは必要な変更がしやすい形に置き換えてから行うほうがかんたんな場合もある

手順

感想

レコード構造とは…
ハッシュとかみたいなもの?
レコード wikipedia によると構造体とからしい
rubyならStructとか

コレクションのカプセル化について
言語仕様の問題な気がする
これが問題になるのは参照渡しになっているケースっぽい?
値渡しなら、関係ない気がする