ナイーブなオブジェクト指向・YAGNI・リファクタリング

近年ではオブジェクト指向分析におけるオブジェクト識別のむづかしさが指摘され、それを克服するためのアプローチとして「ユースケース」の考え方が普及しつつあります。
しかしやはりナイーブなオブジェクト指向にもとづくOOAD手法を一度は通過しておく必要があります。
でないとユースケースのメリットもその問題点も見えてこないでしょう。

ふーん，「ナイーブなオブジェクト指向」を先に使った人がおられたのですね．
でもこれ，Coad / Yourdon が「ナイーブなオブジェクト指向」と言っているということではなくて， 羽生田さんがユースケース以前の OOA / OOD (Coad / Yourdon も含む) のことを「ナイーブな」と表現しているだけですよね？
対象は微妙に違うけど，言葉の使い方としてはこっちと同じなのでまぁいいか．

ともあれ (JW)，私が「ナイーブなオブジェクト指向」と表現したのは，あくまでも複数の役割や責務を詰め込んだ大きすぎるクラスを作ってしまうようなことで，それが今も昔も未熟さ故の過ちであるということは議論の余地がないと思うのですが (だから「レガシーな」ではなくて「ナイーブな」にしたわけ)．
別にリッチなドメインモデルが「ナイーブなオブジェクト指向」だと言うつもりはありません．ひがさんもそんなことは言ってないと思うけど．っていうか，

私の書き方が悪くて誤解を受けた方がいるかもしれませんが、この話は、振る舞いを持たないDTOだとか、状態を持たない業務ロジッククラスの話とは、直接リンクしません。

と書いてるし．

ところで，「YAGNI」ってなんだか思考停止の免罪符に使われているような気がしたのは私だけ？ (^^;
「リファクタリング」も濫用されすぎのような気が．

リファクタリングはより具体的な技術のことで、 小さな「振る舞いを保持したままの変化」（リファクタリングと呼ばれている）から成り立っている。 システムをリファクタリングするときは、数分以上、システムが壊れたままにしてはいけない。 それから、振る舞いがしっかり決まっていないものをどうやってリファクタリングしてよいかは私も分からない。

先送りした分析の問題に対処するのはリファクタリングなんだろうか？ うーみゅ．．．