2017-06-06 12 views
1

最近、私は、インタフェースの実装をカバーするためにTraitを使用することを意味する複数の記事に出くわしました。 例:特性を使用してインタフェースの実装要件をカバーする

interface ArticleInterface 
{ 
    /** 
    * @return mixed 
    */ 
    public function getTitle(); 
} 

trait ArticleTrait 
{ 
    /** 
    * @return string 
    */ 
    public function getTitle() 
    { 
     return "article_title"; 
    } 
} 

abstract class AbstractArticle implements ArticleInterface 
{ 
    use ArticleTrait; 
} 

Someも、インタフェースを実装する形質はPHPのコアで利用可能であるべきだと思います。

したがって、私はこのデザインパターンを守らなければならないのかという質問に対して適切な回答を得ようとしていますか? 「はい」の場合、PHPDocの記述はインターフェースと特性の両方に記述する必要があります(重複していることを意味します)。 このデザインを使用する際に注意すべきその他の詳細はありますか?

+0

Imo、このケースでは特性が適しています。「実際の」継承なしでいくつかのデフォルト実装を提供します。ボイラープレートコードを減らす簡単な方法。これはJavaの[インタフェースのデフォルトメソッド](https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html)のように見えます。このデザインの欠点はありません。 – Timurib

答えて

3

特性は、コンパイラ支援のコピー&ペーストを提供します。それらはコードの再利用の一形態です。クラス継承は、子クラスが親クラスで定義されたコードを共有するように垂直方向にコードを再利用する一方で、特性は水平方向にコードを再利用することを可能にします:インターフェイス共有クラスは、その特性で定義されたコードを使用できます。あなたは複数兄弟実装同じインターフェイスを共有している場合

だから、そう、あなたはコードの重複を減らすために特性を使用することができます。しかし、いいえ、クラスがインターフェイスを実装している場合(例のように)、特性によってはあまり複雑でない複雑さが加わります。

私は1つの重要な点を追加したいと思います:形質はそれ自身ではなく、ストア状態です。特性のメンバー変数は、最終的に特性を消費するオブジェクトに格納されます。あなたがその形質の "私的な"ものとみなされる(したがってオブジェクトで利用できない)いくつかの状態情報を持っているなら、再使用のために形質を使用しないでください。代わりに、サービスデリゲートを使用します。

+0

その後PHPDocsはどうですか?インターフェースと特性の両方にあるべきですか? – user2816626

+0

これは、特性とインターフェースが現在独立しているからです。特性がこれまでにインターフェースを実装している場合は、単一のソース文書が理にかなっています。 – bishop

関連する問題