memo/20111206

オブジェクト指向の一つの華、「カプセル化」について。

リンク	備考
「ぐへへお姉ちゃんパンツ何色」から始めるクラス解説	小人閑居して

読み物として面白かった！

文書として面白い。内容も間違っていないと思います。けど、getter、setterが活きる本当の例としては弱いかな、と思います。

---

私がカプセル化を例で説明するとすれば、以下をあげます。

具体例	備考
壁掛け時計の時刻設定を、実行できるひとを限定する	カプセル化が活きない、悪い例
オフィスのエアコンの温度設定を、実行できるひとを限定する	カプセル化が活きる、良い例

壁掛け時計は、全員が針を設定することができますが、全員が正しい時刻にあわせたいので、問題がおきません。過剰に冗長なプログラムは悪です。setterに意味がないのでgetterにも意味がありません。

オフィスのエアコン設定は、全員の希望温度が違います。そのため、折衝役となる人物を立てることに大いにメリットがあります。

ノウハウとして抽象化すると、「プログラミング対象に対して 自分のアタマでよく考える プロセスが大事」であって、「カプセル化やgetter/setterが、ソフトウェア開発技法として有効であるとは、必ずしも言えない」となります。

---

話題が飛びますが、別の例で、シングルトンパターンていうのも、ほとんど役に立たないと思っています。通常はAPI仕様書に、「このオブジェクトは1プロセスで1つだけ作成すること」と書けばよい。
シングルトンが活きるのは、ソースを公開しあわない他チーム(他社)にAPIを提供する場合で、利用側チームのプログラムの「使い方違反」のバグ対応に徹夜でつき合わされないよう、予防線をはる場合です。
互いのソースが読める環境では、利用側のソースをみて「プロセス内で2個つくってるよ、利用法の誤りです」と言えるでしょう。
また、シングルトンパターンを実装しさえすれば、プロセス内で1つしかオブジェクトができないということを、ドキュメントに書かなくて済むわけではありません。
なので、シングルトンはほとんど役に立ちません。

---

私は、若いころはオブジェクト指向大好きで妄信派でしたが、現在は、5kステップ以下のプログラムではオブジェクト指向の有効性は疑わしく、2kステップ以下では意味がない、と思っています。
大事なのはオブジェクトという分析軸だけに固執せず、何が共通で何が可変なのかをよく考えて、プログラム構造にとりいれることだと思います。

リンク	備考
新装版 マルチパラダイムデザイン	ジェームス・O・コプリン (著)。オブジェクト指向の先を論じている良書です。

---

追記: 2013/2/6

人間は、シンプルにバイクや自転車の絵を描いてだれかに伝えようとしたとき、横から見た絵を描くと思う。

これって、実はすごいこと。どの方角から見た絵を描けば、そのものの特徴を一番分かりやすく表現できるかを瞬間的にぐるっと検索して、よし、ここだ、と決めて、イメージを紙に投影する。

(memo/20120618から引用。)


オブジェクト指向や、ソフトウェア工学にもそれと似ている部分があります。作ろうとしているソフトウェアは、分子構造の立体モデルみたいにボコボコです。それを一体どの方向からソースコードに投影すれば、シンプルかつ特徴を捉えた投影になるのか。それを考えることが大事なんですよね。