データと振る舞いの分離
リンク先(makotanさん)を読みましたが、データと振る舞いを分けるメリットが
よく分かりません。逆にデメリットばかりが思いつきますが。
「データ構造を公開することによる疎結合性を妨害」という点では、永続化されるようなデータの構造は、もともとpublicですから特に問題にはならないと思います。
「ポリモーフィックな振る舞いを持てない」ということはないと思います。
HogeLogicというインターフェースがあって、HogeALogicImplとHogeBLogicImplがHogeLogicを実装していれば、使う側から見れば、HogeLogicという使用とお話をするだけであり、実装は関係ありません。継承ももちろんOKです。
「いくつかのデザインパターンの適用を妨げる(Compositeパターン等)」という点では、Compositeパターンのような構造に関するメソッドは、データ側にあって問題ありません。振る舞いを分離した方がいいといってるのは、業務ロジックです。
なんだか、データと業務ロジックを分離するとオブジェクト指向のメリットが失われるように思われる方もいるようですが、そんなことはないと思いますよ。
話を簡単にするために常にデータと振る舞いを一緒にするというのは、それはそれでOK。
ただし、機能が増えるにしたがって役割多すぎなクラスになる危険性があるということです。最初は、データと構造を一緒にしておいて、機能が増えてきたらリファクタリングすればいいという考えもあるかもしれません。しかし、それは、リファクタリングではありません。利用する側から見てインターフェースが変わってしまうからです。
