6

私は OOP の概念を理解しようとしてきましたが、ほとんどの概念の背後にある一般的なアイデアは理解できましたが、実際の実装に関するアドバイスが必要であることがよくあります。そのようなケースの 1 つがファクトリ メソッドです。

Web インターフェイスとコマンドライン インターフェイスの両方から受信するリクエストを処理する PHP アプリを作成しているので、両方のタイプのリクエストをカバーする次の単純なクラス継承構造を考え出しました。

abstract class Request {
}

class HttpRequest extends Request {
}

class CliRequest extends Request {
}

次に、によって返される値に応じて、具体的な Request インスタンスを返すファクトリ メソッドが必要ですphp_sapi_name()。

public function create() {
    if(php_sapi_name() === 'cli')
        return new CliRequest();
    else
        return new HttpRequest();
}

私の質問は：どこに置くのですか？少なくとも 3 つの可能性が考えられます。

1)別のクラスの静的メソッド:

class RequestFactory {
    public static function create() {
        // ...
    }
}

2)別のクラスの通常のメソッド (最初にクラスをインスタンス化する必要があります):

class RequestFactory {
    public function create() {
        // ...
    }
}

3)抽象親クラスの静的メソッド:

abstract class Request {
    public static function create() {
        // ...
    }
}

各ソリューションの長所と短所は何ですか?また、どれが「適切」と見なされますか?またその理由は何ですか?

4

6 に答える 6

1

これらすべての可能性は期待どおりに機能します。カプセル化の目的であるIMHOとは何ですか。それでは、Factory Method パターンのエッセンスを見てみましょう。

オブジェクトを作成するためのインターフェイスを定義しますが、インターフェイスを実装するクラスにインスタンス化するクラスを決定させます。Factory メソッドを使用すると、クラスはインスタンス化をサブクラスに任せることができます。

あなたがしようとしていることがこの定義に完全に一致するかどうかはわかりません。

代わりに、インスタンス化プロセスがクラスにカプセル化された「 Simple Factory 」と呼ばれるものを実装したいようです。

しかし、この種のメソッドを「リクエスト」オブジェクトのインターフェースを定義する抽象クラスに直接入れることは、悪い考えのようには見えません。

Nicolas が言ったように、これは Java、C#、および Cocoa の世界ではかなり一般的なパターンです。

これらの理由から、私の選択は3番目のオプションになります

于 2013-04-12T11:47:48.637 に答える
0

親クラスで静的メソッドを使用することは、私にはまったくひどい解決策ではないようです。Java の Calendar クラスを見てください。 Locale やその他の基準に応じて Calendar インスタンスを返す getInstance メソッド (実際には多くのメソッド) があります。

于 2013-04-10T15:04:36.720 に答える