寺田＠東工大です．
ホソカワさん，コメントありがとうございます．
> 私はYAGNIをこのように捕らえています。例えば、Dogというクラスが必要になりまし
> た。ここで、将来を考えて、抽象クラスAnimalを作り、それを継承してDogクラスを
> 作るようなことは、YAGNIになってしまいます。メソッドがAnimalに属するべきかDog
> に属するべきかなどを考えているのなら、（Animalなしで）Dogクラスをストレート
> に書きます。後で、Catクラスが必要になって初めて、Animal クラスを考えるのだと
> 思います。
>
> 寺田さんは、Animalクラスを作るのでしょうか？
・・・う〜〜む，正直なところ，分かりません．
Cat クラスが将来的に必要になると予想できる場合には作ってしまうかもしれません．
Dog クラスが他のアプリでも有効であると予想され，今後もぜひ再利用したいと思う場
合には，将来を考えてついつい Animal クラスを作ってしまいそうです．
+---------+
| Package |
+---------+-------+
| +----------+ | +----------+
| | Animal | <-------| Client |
| +----------+ | +----------+
| △ | アプリケーション固有のクラス
| ｜ | 再利用不可
| +----------+ |
| | Dog | |
| +----------+ |
+-----------------+
再利用可能なパッケージ
Animal 導入により：
１．Animal としての責務と，Dog に固有の責務を明確に分離できる
２．Client が（ Dog ではなくて）Animal に依存することを明示できる
３．責務が明確なので，Dog に対する誤った拡張（誤った責務追加）が未然に防げる
４．もちろん，Cat が必要になった場合には拡張が容易．
つまり，責務や依存関係が明確になるので，逆にこの方がシンプルだ，という考え方
もあるのではないか，と思います．
また，Animal や Dog の再利用を意識することで，Animal の独立性を高くすることが
できます．例えば，図の例では Animal と Client を相互参照にしない，とかです．
でも，確かに，結局 Cat クラスが登場しなかったら，なんだか馬鹿みたいです．
だから，YAGNI が言わんとすることも理解できます．
私の考えでは，たとえ無駄になることがあっても Animal クラスを抽出しようという努
力が，再利用に結びつくのではないか，と思っていました．ですから，この努力を否定
してしまう YAGNI の原則にはちょっと違和感を覚えました．
しかし，山田さんや上手さんのコメントから XP 的な再利用法が少し分かってきたので，
この違和感も解消しつつあります．
いまいち自分でも考えに整理がついていないようで，申し訳ありません．