traitは本当に悪者か？

Transcript

1. traitは本当に悪者か？ 他言語と比較する再利用機構の再考 フロントエンド・PHPカンファレンス北海道2026 あくしも @akshimo
2. • akshimo(あくしも) • 新潟からきました • フリーランスエンジニア
3. • PHPer以外含む初〜中級者を想定してます • 15分だとあまり踏み込んで話せないかも...AtSでぜひ聞いてください • あくまでも自分が「再考してみた」結果という一意見です Excuse
4. PHPを書いていた頃、 traitを嫌っていた
5. RubyではMixinがよく使われる印象
6. 実はtraitは良い奴だったのか？
7. PHP以外の言語では意外とtraitと似た機能が良く使われてた。 実はtraitってそんなに悪いやつじゃないんじゃないか？ PHPの”外”から改めてtraitについて考えてみよう 今日のコンセプト traitくんと仲直りしたい...
8. 1. traitのご紹介 2. 他言語を見てみる 3. traitとどう付き合うか？ 本日のお品書き
9. • 五十嵐 進士『WEB+DB PRESS Vol.130 PHPで複雑さに立ち向かう 第8回 トレイトでのコードの再利用とどう向き合うか』.技術評論社 • Jeremy Evans『研鑽Rubyプログラミング』.ラムダノート • meihei『改めて学ぶ Trait の使い方』 https://speakerdeck.com/meihei3/phpcon-odawara-2025 今回参考にさせていただいたもの
10. traitのご紹介
11. PHP は、コードを再利用するための「トレイト」という仕組みを実装しています。 トレイトは、PHP のような単一継承言語でコードを再利用するための仕組みのひとつです。 トレイトは、単一継承の制約を減らすために作られたもので、 いくつかのメソッド群を異なるク ラス階層にある独立したクラスで再利用できるようにします。 トレイトとクラスを組み合わせた 構文は複雑さを軽減させてくれ、 多重継承や Mixin に関連するありがちな問題を回避する こともできます。 トレイトはクラスと似ていますが、トレイトは単にいくつかの機能をまとめるためだけのもので す。 トレイト自身のインスタンスを作成することはできません。 昔ながらの継承に機能を加え て、振る舞いを水平方向で構成できるようになります。 つまり、継承しなくてもクラスのメン バーに追加できるようになります。 https://www.php.net/manual/ja/language.oop5.traits.php
12. 多重継承には「痛み」があった
13. 単一継承 Class A method() Class C method() Class D method() Class B method()
14. 単一継承 Class A method() Class C method() Class D method() Class B method() 水平方向の再利用
15. Dog Animal
16. Dog Animal Is-a
17. Bat Mammalian Hawk Bird Dragonfly Insect Is-a Is-a Is-a
18. Bat Mammalian Hawk Bird Dragonfly Insect 「飛ぶ」という特性 Flyable
19. trait Flyable { public function fly() { echo 'パタパタ'; } } class Hawk extends Bird { use Flyable; public function searchesForFood() { $this->fly(); … } } traitの例
20. 他言語を見てみる
21. traitっぽい(?)機能たち PHP コードがクラス内にコピー &ペーストされるのに近い。 状態（プロパティ）も持てる。 Ruby ModuleのMixin。柔軟にModuleを継承チェーンに差し込む。 TypeScript Mixinが可能。言語としての専用キーワードではなく、クラスを引数に取って新しいクラ スを返す「関数」を定義することで実現。 Java interfaceのdefault実装。PHPとは違って状態を持つことはできない。
22. Rubyでは本当に Mixinがよく使われるのか？
23. RubyとPHPでのtrait/Mixin Ruby PHP 定義ファイル率平均 10.2% 1.3% 定義ファイル率中央値 13.7% 0.4% 利用ファイル率平均 26.1% 6.4% 利用ファイル率中央値 17.0% 2.6%
24. • 不透明・暗黙的な依存 • 密結合 • 名前衝突が(やや)わかりづらい なぜPHPでtraitは避けられがちなのか？
25. 暗黙的な依存 trait AddressFormattable { public function fullAddress(): string { // traitの利用側にこれらのプロパティがあることに依存している return $this->address1 . $this->address2 . $this->address3; } } class DeliveryAdress { use AddressFormattable; private string $address1; … }
26. 不透明 class DeliveryAdress { use AddressFormattable; } $deliveryAddress = new DeliveryAdress(); // このメソッドはどこから来た？ $deliveryAddress->fullAddress();
27. 密結合 trait AddressFormattable { public function fullAddress(): string { // たとえprivateなプロパティだろうと、お互いに”壊す”ことが可能 $this->address1 = $this->address1 . $this->address2 . $this->address3; return $this->address1; } } class DeliveryAdress { use AddressFormattable; private string $address1; … }
28. 名前衝突が (やや)わかりづらい trait PropertiesTrait { public $same = true; public $different1 = false; public bool $different2; public bool $different3; } class PropertiesExample { use PropertiesTrait; public $same = true; public $different1 = true; public string $different2; readonly protected bool $different3; }
29. 名前衝突が (やや)わかりづらい trait PropertiesTrait { public $same = true; public $different1 = false; public bool $different2; public bool $different3; } class PropertiesExample { use PropertiesTrait; public $same = true; public $different1 = true; // Fatal error public string $different2; // Fatal error readonly protected bool $different3; // Fatal error }
30. • 不透明・暗黙的な依存 • 密結合 • 名前衝突が(やや)わかりづらい なぜPHPでtraitは避けられがちなのか？ DI・コンポジション(後述)の方が好まれるよね...
31. 一方Rubyでは
32. 継承ツリーへの差し込み String.ancestors => [String, ActiveSupport::ToJsonWithActiveSupportEncoder, MessagePack::CoreExt, Comparable, … Kernel, BasicObject]
33. 継承ツリーへの差し込み String.ancestors => [String, MyModule, ActiveSupport::ToJsonWithActiveSupportEncoder, MessagePack::CoreExt, Comparable, … Kernel, BasicObject]
34. Rubyで型はどこにあるのか？
36. 一般に、Rubyのイディオムでは型に基づく防御的なプ ログラミングを避けます。なぜなら、Rubyで気にする のは「オブジェクトがどんなメソッドに反応するのか」と 「そのメソッドがどんなオブジェクトを返すのか」だから です Jeremy Evans『研鑽Rubyプログラミング』.ラムダノート p148
37. ダック・タイピング
38. Ruby自体はオープン・クローズドの原則を完全に無視 しています。むしろ、積極的にクラスが変更に対して閉 じないようにしています。 Jeremy Evans『研鑽Rubyプログラミング』.ラムダノート p31
39. Mixinをさらに使いやすくした RailsのConcerns
40. Concerns are also a helpful way of extracting a slice of model that doesn’t seem part of its essence (what is and isn’t in the essence of a model is a fuzzy line and a longer discussion) without going full-bore Single Responsibility Principle and running the risk of ballooning your object inventory. David Heinemeier Hansson『Put chubby models on a diet with concerns』 https://signalvnoise.com/posts/3372-put-chubby-models-on-a-diet-with-concerns
41. そもそも、 PHPのtraitは5.4からで、 RubyのModuleは最初からある Rubyでは言語のコアな部分で Moduleが使われている （EnumerableやComparable）
42. traitやMixinの使われ方の違いは 言語の思想の違いなのではないか Rubyで使われてるからといって そのままPHPでマネするのは危険 （そりゃそうだ）
43. やはり仲直りはできないのか ...?
44. traitとどう付き合うか？
45. • 共通化したい場合、そもそも共通化すべきか？ （対象が同じ知識・意図か？） • Is-a 関係ではないか？ • コンポジション・DIで実現できないか？ まずはtrait以外の選択肢を検討する
46. trait Norifiable { public function notify(string $email): void { // 通知処理 } } class OrderAction { use Norifiable; } できるなら DI・コンポジションの方が良い
47. class Norifier { public function notify(string $email): void { // 通知処理 } } class OrderAction { public function __construct (private Norifier $notifier) {} } できるなら DI・コンポジションの方が良い
48. interface Norifiable { public function notify(string $email): void; } class Norifier implements Norifiable { // 通知処理の実装 } class OrderAction { public function __construct (private Norifiable $notifier) {} } できるなら DI・コンポジションの方が良い
49. 値オブジェクトも良い class Address { public function __construct ( private string $address1, private string $address2, private string $address3 ) {} public function fullAddress(): string { return $this->address1 . $this->address2 . $this->address3; } }
50. 無理に他言語をマネしても うまくいかない PHPの機能を使って PHPらしい コードを書こう
51. 暗黙的な依存 trait AddressFormattable { public function fullAddress(): void { // traitの利用側にこれらの変数があることに依存している return $this->address1 . $this->address2 . $this->address3; } } class DeliveryAdress { use AddressFormattable; … }
52. trait AddressFormattable { public function fullAddress(): string { return $this->address1() . $this->address2() . $this->address3(); } abstract private function address1(): string; abstract private function address2(): string; abstract private function address3(): string; } 抽象メソッドを介する
53. interface AddressFormatInterface { public function fullAddress(): string; } trait AddressFormatTrait { public function fullAddress(): string { return $this->address1() . $this->address2() . $this->address3(); } abstract private function address1(): string; abstract private function address2(): string; abstract private function address3(): string; } interfaceのdefault実装
54. class Adress implements AddressFormatInterface { use AddressFormatTrait; public function fullAddress(): string { // デフォルト以外の振る舞いをしたければオーバーライド } } interfaceのdefault実装
55. traitっぽい(?)機能たち PHP コードがクラス内にコピー &ペーストされるのに近い。 状態（プロパティ）も持てる。 Ruby ModuleのMixin。柔軟にModuleを継承チェーンに差し込む。 TypeScript Mixinが可能。言語としての専用キーワードではなく、クラスを引数に取って新しいクラ スを返す「関数」を定義することで実現。 Java interfaceのdefault実装。PHPとは違って状態を持つことはできない。
56. traitの使い所は割と既に FWやライブラリで 実装済みなことも多い traitが全面的に悪者なのではない
57. 他の言語を学ぶことでPHPでの設計にも良い効果がある => 「インターリービング」 学び（感想）
58. traitと臭ぇ(特性)コード には気をつけよう！