小井土＠オーエスケイです。
＃割り込みます。
> 寺田＠東工大です．
> ホソカワさん，コメントありがとうございます．
>
> > 私は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 的な再利用法が少し分かってきた
ので，
> この違和感も解消しつつあります．
視点を変えて、Catが将来追加されることが確実ならAnimal クラスを導入しても
良いと思います。
しかし、実際はwolfが追加されたとします。
すると、犬族クラスをスーパークラスにした方が、適切な抽象化だったとわけです。
要するに、抽象化する場合、具象クラスが明確になってから抽象クラスを導入する
方が、圧倒的に良いクラス構造を導けるわけです。
YAGNIは、抽象クラスは、似たクラスが複数必要になって必要に応じて作りましょう
といっているのだと思います。