DRYを勘違いしてたお orz

ちょっと感動したので(笑

DRY(Don't Repeat Yourself)ってのがあるです。
たぶん、割と多い説明として「ソースコードの再利用/繰り返しを避ける(二度手間すんな)」という文脈で使われていて、おいちゃんもそう認識していたです。
で…その文脈において、つまり「ソースコードの再利用」については、おいちゃん的には是非こもごも(この辺本気で語るとすげぇ長くなるんで後日)。

たまさか、DRYについてちと調べる機会がありまして………んむぅささやかだけどえれぇ勘違いしてるよおいちゃん orz
http://d.hatena.ne.jp/kwatch/20090105/1231162464
経由
http://c2.com/cgi/wiki?DontRepeatYourself

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

そうなのそれなの！
おいちゃん的には「随所に関所 http://d.hatena.ne.jp/gallu/20080225/p1 」。

当初「デバッグ用」で思いついた発想ではあったんだけど、実際のところ「設計のあらゆるところ」で非常に重要で。
それは「重複させたくない」んぢゃなくて「変更するときは一箇所変更すればいいでしょ？ 二箇所以上とかミス誘発するからやめて！」っていう発想なの！

だから、この辺を見て、異様に腑に落ちた。
http://ja.wikipedia.org/wiki/Don%27t_repeat_yourself

DRY 原則がうまく適用されたとき、システムに対するいかなる要素の変更も、論理的に関連のない他の要素の変更にはつながらない。さらに、論理的に関連した要素は予測できる形で統一的に変更され、したがってそれらの変更は同期が取れたものとなる。

んで。
DRYを想起するときにいつも思い出すのがMECE(Mutually Exclusive and Collectively Exhaustive)。
コンサルとか経営学とかそっちの領域の単語なんだけど、結局のところDRYと「とても似た発想」だと思う。
…いやまぁどこに行っても「無駄な重複って困ってるし苦労してるんだなぁ」とかげふんごふんがふん。

DRYもMECEも、いわばこの辺は「１部品のあるべき姿」。
で、この「独立した部品群」をキレイに「隙間があって隙が無いように http://d.hatena.ne.jp/gallu/20100506/p1 」組み立てて、キレイなプログラムが出来上がるんだと思う。

うん。
やっぱり「関数とクラスをどうきるか」は、本当に、ものすごく重要だし「シンプルだけど難しい」領域なんだなぁ、と、改めてしみじみ。

でも。「なぜ共通化したいのか」の原理原則が念頭にあれば、そんなに無茶なことにはならないし。
よしんば「ひでぇきり方」しても、それはまぁ「こまめなPDCA(リファクタリング)」で修正するよね？ っていう程度に、最近のおいちゃんは楽天的(笑