<< 前 ホーム 次 >>

bakaid: 200805021

いや、やっぱり消そう。何回もおんなじこと書いてるもんな。

--

SBPPに『プロジェクトが良い状態』であるときの特徴が
次のようにあげられています:

* once and only one (一度、ただ一度だけ)

* lots of little pieces (たくさんの小さなカケラ)

* replacing objects (オブジェクトを置き換えられる)

* moving objects (オブジェクトを移せる)

* rate of change (変更頻度)

『プロジェクトが良い状態』というのは、『設計が良い
状態』と言い替えることができます。

once and only onceとlots of little picesについては、
もう説明する必要もありません。

replacing objectsというのは、pluggableということも
できるでしょう。オブジェクトを差し替えることで新しい
機能を実現する。

moving objectsは、再利用ということですね。ある
オブジェクトを別のコンテキストに移しても動くように
する。

rate of changeについてはまたあとで書きます。

で、自分なりに上のを言い替えると:

* lots of little pieces

* once and only once

* low coupling, high cohesion

* rate of change

ということになります。まぁ、大して変わってないん
ですけど。

lots of little piecesがまず最初にやらなきゃいけない
こと。

でも、lots of little piecesでやると、細切れのカケラが
たくさんできちゃう。とりあえず重複するものはなくす。
それがonce and only once。

でも、まだカケラが無秩序に散らばってる状態。で、
関係のないものは切り離して、関係するものはまとめる。
それがlow coupling, high cohesion。

でも、関係するかどうかっていうのは、結構判断しにくい
こともある。だから、その目安としてrate of changeを
使う。頻繁に変更されるところと、そうでないところとを
分ける。

『Code Complete』には、他にも拡張性だとか再利用性だ
とかfan-inだとかfan-outだとかいろいろ書いてあるけど。
そういうのは気にしなくっていい。そういうのは上の
4つの特徴でぜんぶカバーされるから。

--

なんか、once and only onceを軽んじてるような書き方
ですけど、そうじゃないんです。手順として考えたら
こうなるっていうだけで。once and only onceが達成
できたら、それだけで良い設計といえるほどだっていう
のは変わりません。

--

やっぱり、こうやって書くと、設計とコーディングを
切り離すことはできないとわかりますね。lots of little
piecesにしても、once and only onceにしても、rate of
changeにしても、コード上の話なわけで。

必ずしも設計とコーディングがイコールというわけじゃ
ないですけど。でも、設計の一部としてコーディングが
あると。設計っていうのは、結構広い活動だから。

本家Permlink

<< 前 ホーム 次 >>


Copyright © 1905 tko at jitu.org

バカが征く on Rails