元ネタ
マジックメソッド（特に__construct()）は、Traitに「メソッドの引き上げ」をしてはいけない
http://qiita.com/ndxbn/items/0e3160b20f64cff0323b
半分、私信のようなblogになりますご容赦のほどを(笑
とりあえず、つれづれに「おいちゃんの見解」を。
発端
Traitは、メソッドの実装のコピペを回避するのに多用します。でも、マジックメソッド（特に__construct()）を引き上げると、思いの外「再利用可能な機会が狭まる」ので、やめたほうがいいなぁって感じました。
結論だけ先にかくと「大体のケースでyes」だと思う。
で、各論。
メソッドの使用率（メソッド名の重複率）が高い（と思う）
メソッド名の重複というより「役割の重複」が気になるかなぁ。
traitは「１つの、意味を持つ塊(コンストラクタ生成機能を基本的に除く)」なので。
「メソッド名が重複する」ってことは本質的に「意味合いが重複している可能性」が想起されるので、設計っつかクラス切りにそもそものミスがある可能性があるんじゃないか？ とか思ってみたりみたり。
コンストラクタは改修するのがつらい
traitでコンストラクタってそもそも「シングルトン以外」であんまり想像できてないしなぁｗ
普通に「あるデータ構造を持ってる」んなら、traitじゃなくて普通にclass切ってる気がする、おいちゃんなら。
データ構造に密接に関係する
「Getter/Sestterの乱用はアンチパターン」については、実はおいちゃんは些か懐疑的。
全面的に否定、ってほどではないんだけど、程度問題でもあるし、じゃぁ「コンストラクタに５つも６つも引数をもつのか？」って問われると、後日改修とかも考えて色々ともにょるので、微妙。
とはいえ一方で「イミュータブルなインスタンス」って実際魅力的ではあるので、だから「ガチ否定」まではいかない、という微妙スタンス。
traitが「あるクラスのデータ構造をがっつりと制御する」ってのも、おいちゃんの感覚だとあんまりピンとこない感じかなぁ。
traitは「部品」のイメージが強いので、せいぜいが「classを構成する一部分」なので。
そういう意味からも「イミュータブルなデータをコンストラクタ時に紐づけるための__construct()」は、あんまりtraitと相性がいいとは思わないかなぁ。
Method Pull Downするときに、変更コストが高くつく
ん…そもそもおいちゃん「Method Pull Down」したことないかもｗ
おいちゃん、記述の癖として「とりあえず子なり孫なりに実装、コピペするタイミングでコピペの代わりにpush up」って書き方をするので、Method Pull Downするタイミングが多分存在しないｗ
各マジックメソッドは、何に使われるのか
__get(), __set(), __call()は？ｗ
ちなみに__get()と__set()は、おいちゃんは「防御目的で使うことが多い( http://d.hatena.ne.jp/gallu/20140119/p1 )」ですｗ
アクセサは__callで実装するかなぁ。あんまりやらないけど、やるとしたら。
useしてる先のクラスで上書きすればいいんじゃね？
「絶対禁止」とまでは言わないにしても、まぁ基本「悪手の類」だよねぇｗ
なので、まぁ大きくまとめると「同意」。
細かい部分で細かく違うのは、個性とか好みとか方向性とかの類かなぁ、と思われ。
