妙な関西弁もどきとアジャイルもどき
http://www.atmarkit.co.jp/fdotnet/nagilemind/nagilemind01/nagilemind01_01.html
もし仮に、これが数十行にもなったとするわな？それはつまり、自分の中のモデルとソース・コードがかけ離れとるいうことや。それは自分の設計モデルやない。「自分の設計モデルをシンプルに分かりやすく表したソース・コード」やない。設計モデルをアカウンタビっとらんソース・コード、いうわけやな。
要は、設計モデルがそのままソース・コードになるようにするわけや。
うーん，そのやり方は実はこれと大差ないな
8) 実世界に対応したクラスを設計せよ
http://labs.cybozu.co.jp/blog/akky/archives/2006/02/10.html
少なくともオブジェクト指向の世界ではそういう設計はお奨めしないよ．
UMLもフローチャートもどっちも分かり難い．さらに，それらを直接ソースコードに置き換えれば，いかに悲惨な結果が待っていることか容易に想像が付く．
例えば、物体の運動を考えるとしょうか。
「リンゴを上向きに放ったら、どないな動きをするんやろ？」みたいなこっちゃわな。
いい喩えだ．これは次の実に簡単な式で表されることが知られている．
ma=F*1
「名前付けは、モデリング（設計行為）なんや」
「モデリング」と設計とを混同しないでもらいたい*2．名前付けが設計の重要な一部を占めるのは事実だけど，名前付け「だけ」できても，それは設計ではない．*3
「名前の変更＝モデルの変更（設計の見直し）＝リファクタリング」や
．．．ここまで来るとアホらしくてやってられんな．リファクタリングの誤用もここに極まれり*4．ここで述べているのはUML屋によるUML屋のためのモデリングでしかなく，断じてアジャイルではない．
