データクラスと機能クラスを分けることで起きる弊害
どこにでも機能を書けてしまうため、凝集度が下がる
問題の特定時に調べないといけない範囲が広い
1つのことを変更するために、修正すべき範囲が広い
修正によるデグレが起きていないことを確認するためのテストが大量に必要
アプリケーション層の機能クラスと、Viewが密結合する 複数の機能クラスに、同じドメインロジックが重複する
View駆動良くないmrsekut.icon
機能クラスを、tableのCRUD操作単位にしてしまう
機能クラスと、tableが密結合するということか #?? 汎用的にするが、個々で微妙に要件が異なる場合に対応できない
対応すると、flugの引数を取ったりしてしまう
逆に、具体的なmethodを作るとmethod数がめちゃくちゃ増えるので探すのが大変
これも結構渋い問題なんだよなmrsekut.icon
物が多すぎると探せない
初見のときに、そこを一望していても、今後誰かに似たようなものを追加されているかも知れない
毎回確認するのも大変なので結局、独自のものを各々が作るようになってしまう
こうやって見ると、そもそもSymfony使っている時点で、やっぱり良い設計を実践するのって無理だな、と思うんだけどどうだろう フレームワークが、データクラスと機能クラスの分離を半ば強制してくる
工夫すればどうにかなるものなのか？
どうやって解決するのか？
要は、データと機能を同じ場所に書く
参考