オブジェクト指向

ソフトウェアの売りはソフトさ、つまり変更可能性だ。
しかし、その変更可能性が故に変更が頻発すると、ソフトウェアの保守は難しくなる。
すると、プログラマはなるべく保守しやすいコードを書く必要が出てくる。
そして、最高に保守しやすいコードとは変更しないコードだ。

最高の戦略は戦わないことだ。みたいな孫子が言いそうなことになってしまった。

だが、実際にコードを書かなければバグは生まれないし、多くのバグはの変更によって生じている。

万物は流転し、要求は変更する。顧客の要求であっても自分の要求であってもそうなのだ。すなわち、変更しないコードなど存在しない。よって、最高に保守しやすいコードなど存在しない。 Q.E.D.

プログラマはこの二律背反から逃れられない。しかし、コードのすべての行が変更されるわけではない。どのようにコードが変更するかはわからないが、対象をよく観察することで変更する可能性のある場所は大体わかる。
実際に変更可能性がある箇所を見分けるのは難しい。コーディング前は実装に関する情報が足りないが故に動けず、コーディング中はどのように実装すべきかに注意が向いていて変更しそうな箇所、変更しなさそうな箇所を見分けようという意識が無い。
おそらく、注目している箇所が変更可能かどうかを意識するのはリファクタリングの最中であろう。

(ということは、実装とリファクタリングのサイクルを多くすればするほど品質は上がるのだろうか？あれ、XPに近いものを感じる…)

熟練者は目を持っているのだ。
変更する可能性がある場所と適切な間合いを保つための。¹

責任という概念

日本語における”責任”には”responsibility”が充てられている。ところで、responsibilityという単語は response + ability であり、 “応答できる能力”を表すことがわかる。

オブジェクト指向の文脈で責任という概念がある。
これは失敗したら引責辞任する、間違ったら批判を受けるといった意味ではない。むしろ responsibility, 応答できる能力を意味していると自分は考えている。²

オブジェクト指向のレイヤー

オブジェクトとは何だろうか。
この深淵なる問に答えられないのでとりあえず実体のことと言っておこう。 Martin Fowler³は３つの概念からオブジェクトを定義している。

オブジェクトを定義するために3つの別の概念が出てきてしまった。
これは自分の意見だが、概念・仕様レベルと実装レベルでは同じオブジェクトに対しても見ている立場が異なる。概念・仕様レベルはオブジェクトの外側から、実装レベルではオブジェクトの中身を見ているように感じる。そこで、不遜にもMartinの言葉を捻じ曲げ、自己流にオブジェクトを定義する。

オブジェクト指向を象るもの

これを脊髄で返せるようになれと誰かに教わった。
しかし、これは継承を無定義で使用できるとすると、自然に構成されるものなのではないかと考えるようになってきた。

カプセル化とポリモーフィズム

オブジェクトが責任の集合であるとするならば他のオブジェクトに公開する必要がある・ないものが出てくる。これを分別するとカプセル化が達成される。これらは通常public, protected, privateなどのアクセサで実現される。これは単なるデータ隠蔽だが、さらに高度なカプセル化も考えられる。すなわち、継承を使用することで子の型を知らなくても親の型を知っていれば子と応答できる。これは型をまるごと隠蔽したより高度なカプセル化と言える。また、それぞれの子に対し応答すると、それぞれの子は個別に実装された行動形態をとる。同じ応答に対し多様な行動形態をとることからポリモーフィズムという性質が導き出される。

is-a has-a use-a

プログラマではどうしようもない問題もある。変更がないだろうと思っていたが後々変更する必要が出てきたが担当者が居ない。あるソフトウェアを変更したいが金をかけすぎて変更できない。など、これらはプログラマの失敗のようにも見えるがどちらも経営の失敗であってプログラマの失敗ではない。 ↩
というか日常生活における責任という概念も応答可能性と同じだと思って生活してる。 ↩
アジャイルソフトウェア開発宣言、依存性の注入という用語の発案、リファクタリングに関する本の出版など ↩

ソフトウェア vs プログラマ

責任という概念