2

適切なDocBlockコメントとは、次のようなコメントです。

クラス自体は次のとおりです。 

class Factory_DomainObjects
{
    /**
     * Build domain object
     *
     * @param $name
     *
     * @return M_UserObject|M_TransactionObject
     */
    public function build($name)
    {
        $class = 'M_' . $name . 'Object';
        return new $class();
    }
}

引数 Core_Objectに応じて階層から1つのオブジェクトを返します。$name

現在Core_Object、階層は次のようになっています。
ここに画像の説明を入力してください

@returnタグにM_UserObject|M_TransactionObjectタイプの説明を付けました。PHPStormの自動競合を提供し、PHPdoc標準に準拠しています。

-しかし、それはまさにあなたが望むものです、問題は何ですか？
-はい、いいえ、読み続けてください:)

問題：階層がこのようなものに成長した
場合はどうなりますか？Core_Objectここに画像の説明を入力してください

これ@returnにより、タグの説明が混乱します。 

/**
 * @return M_TransactionObject|M_UserObject|M_Foo|M_Foo1|M_Foo2|M_Foo3|M_Bar|M_Bar1|M_Bar2|M_Bar3
 */

これまでに見つけた唯一の回避策：buildオブジェクトごとに個別のメソッドを使用する、つまり 

/**
 * Build user domain object
 * 
 * @return M_UserObject
 */
public function buildUser()
{
    return new M_UserObject();
}

/**
 * Build transaction domain object
 * 
 * @return M_TransactionObject
 */
public function buildTransaction()
{
    return new M_TransactionObject();
}

私の回避策にはどのような落とし穴があると思いますか？代わりに何を提案しますか？

4

3 に答える 3

6

ここでの簡単な答えは、単一のメソッドから複数のオブジェクトタイプを返すべきではないということです。詳細を説明させてください。

私が「タイプ」と言うとき、私はすべてが何らかの方法で同じタイプ情報を共有しないオブジェクトを意味します。あなたの場合、それらはすべてCoreObjectです（ちなみにこれは恐ろしい名前です）。だから私は単にreturntype-hintにラベルCoreObjectを付けてそれで済ませます。

ただし、このような処理の推奨される方法は、インターフェイスを使用し、メソッドにそのインターフェイスの実装を返すようにすることです。すべてのリターンタイプに共通のインターフェイスがない場合は、さまざまなメソッドを実装する必要があります（少なくとも、または場合によってはさまざまなファクトリ）。

于 2013-03-25T14:48:13.997 に答える
1

現在はできません。

このチケットを見て、いつ実装されるかを確認してください：http: //youtrack.jetbrains.com/issue/WI-6027

クラスごとに個別のメソッドを使用したくない場合は、ローカル変数にPHPDoc @varコメントを使用することをお勧めします（これは非常に不便です。使用方法によって異なります）。

/** @var M_FooObject $myFoo */
$myFoo = $factory->build('Foo');
于 2013-03-25T13:25:10.293 に答える
1

推奨される方法は、最初に一般的なタイプを配置し（Factoryが特定のタイプのサブタイプを作成する場合、これはそのタイプではありません）、次にすべてのサブタイプ（または重要なサブタイプ）を追加できます。

これは通常、PHPStormで非常にうまく機能し、PHPDocにまったく違反していません。

/**
 * @return M_TransactionObject|M_UserObject|M_Foo|M_Foo1|M_Foo2|M_Foo3|M_Bar|M_Bar1|M_Bar2|M_Bar3
 */

これは、やりすぎ。私は通常、 @ returnタグを持つ3つ以上の（サブ）タイプを持っていません。これは大まかな目安だと思います。

例えば：

 * @return M_UserObject|M_TransactionObject

私の目には大丈夫です。同等のヒント移動は次のとおりです。

 * @return array|string[]

また

* @return Iterator|string[]

最初のタイプは定義された使用法を示し（たとえば、最後の行はgetIterator()のIteratorAggregate）、代替タイプはIDE-Typehintingの欠陥を回避するのに役立ちます（PHPStormはこれで非常に優れています）。

HTH。@ircmaxellが書いていることは間違いではありませんが、最初の戻り型を彼の意味に任せれば（インターフェースはそこに行きます）、代替型が型ヒント専用であることを理解していれば問題ありません。ファクトリメソッドが多くの異なる「タイプ」を返す場合、それらすべてが1つのインターフェイスを共有する必要があります。これは重要。たとえば、長いリストが表示された場合、1つのタイプがあり、その1つのタイプがインターフェイスです。

于 2013-04-12T01:03:52.187 に答える