ファクトリー（オブジェクト指向プログラミング）

オブジェクト指向プログラミングにおいて、ファクトリは他のオブジェクトを作成するためのオブジェクトです。正式には、新しいと想定される何らかのメソッド呼び出しから、変化するプロトタイプまたはクラス^{[1]のオブジェクトを返す}関数またはメソッドです。^{[a]より広義には、}新しいオブジェクトを返すサブルーチンは、ファクトリメソッドまたはファクトリ関数のように、ファクトリと呼ばれることがあります。ファクトリパターンは、関連する多くのソフトウェア設計パターンの基礎となっています。

クラスベースのプログラミングでは、ファクトリはクラスのコンストラクターの抽象化ですが、プロトタイプベースのプログラミングでは、ファクトリはプロトタイプ オブジェクトの抽象化です。コンストラクターは、指定されたプロセス (クラスのインスタンス化) によって 1 つのクラスのインスタンスとしてオブジェクトを作成するという点で具体的ですが、ファクトリは、さまざまなクラスをインスタンス化するか、オブジェクト プールなどの他の割り当て手段を使用してオブジェクトを作成できます。プロトタイプ オブジェクトは、クローン化によってオブジェクトを作成するために使用されるという点で具体的ですが、ファクトリは、さまざまなプロトタイプをクローン化するか、他の割り当て手段によってオブジェクトを作成できます。

ファクトリは、さまざまな方法で実装できます。ほとんどの場合、ファクトリはメソッドとして実装され、その場合はファクトリ メソッドと呼ばれます。関数として実装される場合もあり、その場合はファクトリ関数と呼ばれます。言語によっては、コンストラクターがファクトリです。ただし、ほとんどの言語ではそうではなく、コンストラクターは、キーワード を使用するなど、言語に慣用的な方法で呼び出されますnew。一方、ファクトリは特別なステータスを持たず、通常のメソッド呼び出しまたは関数呼び出しを介して呼び出されます。これらの言語では、ファクトリはコンストラクターの抽象化ですが、コンストラクターはファクトリではないため、厳密には一般化ではありません。

ファクトリの概念がデザイン パターンであるかどうかについては用語が異なります。デザイン パターンにはファクトリ パターンはなく、代わりにファクトリを使用する 2 つのパターン (ファクトリ メソッド パターンと抽象ファクトリ パターン) があります。一部の情報源では、この概念をファクトリ パターンと呼んでいます[ 2 ^{] [3]。}一方、この概念をプログラミングイディオムと見なしている情報源もあります [ ⁴ ] 。ファクトリ パターンまたはファクトリ パターンという用語は、ファクトリを使用するより複雑なパターン (ほとんどの場合、ファクトリ メソッド パターン) に対してのみ使用されます。このコンテキストでは、ファクトリの概念は単純なファクトリと呼ばれることがあります。 ^[4]他のコンテキスト、特にPython言語では、この記事のように、ファクトリという用語が使用されます。 [5] より広義では、ファクトリは、何らかのメソッド呼び出しからオブジェクトを返すオブジェクトだけでなく、^{ファクトリ}関数(関数がオブジェクトでない場合も) やファクトリ メソッドのように、オブジェクトを返すサブルーチンにも適用される場合があります。 [6

OOP は 、メソッド ディスパッチによるオブジェクト使用のポリモーフィズムを提供します。これは、メソッドが呼び出されるオブジェクトの型によって決定される単一のディスパッチによる、正式にはサブタイプポリモーフィズムです。ただし、これはコンストラクターでは機能しません。コンストラクターは、既存のオブジェクトを使用するのではなく、何らかの型のオブジェクトを作成するためです。より具体的には、コンストラクターが呼び出されたときには、ディスパッチするオブジェクトはまだ存在しません。^[b]

コンストラクターやプロトタイプの代わりにファクトリを使用すると、オブジェクトの使用だけでなく、オブジェクトの作成にもポリモーフィズムを使用できます。具体的には、ファクトリを使用するとカプセル化が提供され、コードが特定のクラスやオブジェクトに結び付けられないことを意味します。そのため、クラス階層やプロトタイプは、それらを使用するコードを変更することなく変更またはリファクタリングできます。クラス階層やプロトタイプはクラス階層やプロトタイプから抽象化されます。

より技術的に言えば、ファクトリがコンストラクタを一般化する言語では、ファクトリは通常、コンストラクタが使用できる場所であればどこでも使用できます。 ^[c]つまり、コンストラクタを受け入れるインターフェースは、一般にファクトリも受け入れることができます。通常、クラスとインスタンス化を指定する必要はなく、オブジェクトを作成するものだけが必要です。

たとえば、Pythonでは、collections.defaultdictクラス^{[7]には、ファクトリを呼び出すことでデフォルト値が生成される}defaultdict^[d]型のオブジェクトを作成するコンストラクタがあります。ファクトリはコンストラクタに引数として渡され、コンストラクタ、またはコンストラクタのように動作する任意のもの（オブジェクトを返す呼び出し可能オブジェクト、つまりファクトリ）になります。たとえば、listリストのコンストラクタを使用する場合:

# collections.defaultdict([default_factory[, ...]]) 
d  =  defaultdict (リスト)

ファクトリ オブジェクトは、特定の種類のオブジェクトを取得することが、単に新しいオブジェクトを作成するよりも複雑なプロセスである状況で使用されます。特に、複雑な割り当てや初期化が必要な場合に使用されます。オブジェクトの作成に必要なプロセスには、作成するオブジェクトの決定、オブジェクトの有効期間の管理、オブジェクトの特殊な構築と破棄に関する懸念の管理などがあります。ファクトリ オブジェクトは、オブジェクトのクラス(該当する場合) を動的に作成したり、オブジェクト プールから返したり、オブジェクトに対して複雑な構成を実行したりすることなどを決定する場合があります。同様に、この定義を使用すると、シングルトン パターンによって実装されたシングルトンは正式なファクトリです。つまり、オブジェクトを返しますが、1 つのインスタンスを超えて新しいオブジェクトを作成しません。

ファクトリの最も単純な例は、コンストラクターを呼び出して結果を返すだけの単純なファクトリ関数です。Pythonfでは、クラスをインスタンス化するファクトリ関数は次Aのように実装できます。

def  f ():
    戻り値 A ()

シングルトン パターンを実装する単純なファクトリ関数は次のとおりです。

def  f (): 
    f . objがNone の場合 : f . obj = A () f . objを返す  
          
     

f . obj  = なし

これは、最初に呼び出されたときにオブジェクトを作成し、その後は常に同じオブジェクトを返します。

ファクトリはさまざまな方法で呼び出されますが、最も一般的なのはメソッド呼び出し (ファクトリ メソッド) ですが、ファクトリが呼び出し可能なオブジェクトである場合は関数として呼び出されることもあります (ファクトリ関数)。言語によっては、コンストラクターとファクトリの構文が同一である一方、コンストラクターの構文は特殊です。Python、Perl、Ruby、Object Pascal、F#など、コンストラクターとファクトリの構文が同一である言語では、 ^[e]コンストラクターを透過的にファクトリに置き換えることができます。異なる言語では、インターフェイスでそれらを区別する必要があり、コンストラクターとファクトリを切り替えるには呼び出しを変更する必要があります。

Java や Python のように、オブジェクトが動的に割り当てられる言語では、ファクトリは意味的にコンストラクタと同等です。ただし、一部のオブジェクトを静的に割り当てることができるC++などの言語では、ファクトリは静的に割り当てられたクラスのコンストラクタとは異なります。これは、後者はコンパイル時にメモリ割り当てを決定できますが、ファクトリの戻り値の割り当ては実行時に決定する必要があるためです。コンストラクタを関数の引数として渡すことができる場合、コンストラクタの呼び出しと戻り値の割り当ては実行時に動的に行う必要があり、ファクトリの呼び出しと同様または同一の意味を持ちます。

ファクトリはさまざまなデザイン パターン、特にデザイン パターン オブジェクト ライブラリなどの創造パターンで使用されます。多くの言語でファクトリを実装するための特定のレシピが開発されています。たとえば、ファクトリ メソッド パターン、ビルダー、シングルトンなどのいくつかのGoF パターンは、この概念の実装です。一方、抽象ファクトリ パターンは、ファクトリのコレクションを構築する方法です。

一部のデザイン パターンでは、ファクトリ オブジェクトには作成可能なあらゆる種類のオブジェクトに対応するメソッドがあります。これらのメソッドは、オプションでオブジェクトの作成方法を定義するパラメータを受け入れ、作成されたオブジェクトを返します。

ファクトリオブジェクトはウィジェットツールキットやソフトウェアフレームワークでよく使われ、ライブラリコードではフレームワークを使用するアプリケーションによってサブクラス化される可能性のある型のオブジェクトを作成する必要があります。また、テスト駆動開発でもクラスをテストできるようにするために使われます。 ^[8]

ファクトリは、作成するオブジェクトの具体的な型を決定し、ここでオブジェクトが作成されます。ファクトリはオブジェクトに抽象インターフェイスを返すだけなので、クライアント コードは、作成されたばかりのオブジェクトの具体的な型を知らず、その負担もかかりません。ただし、具体的なオブジェクトの型は抽象ファクトリによって認識されます。具体的には、次のことを意味します。

• クライアント コードは、具体的なデータ型についてはまったく認識せず、具体的な型に関連するヘッダー ファイルやクラス 宣言を含める必要もありません。クライアント コードは、抽象型のみを扱います。具体的な型のオブジェクトは、ファクトリによって実際に作成されますが、クライアント コードは、抽象インターフェイスを通じてのみ、そのようなオブジェクトにアクセスします。
• 新しい具体的な型を追加するには、クライアント コードを変更して別のファクトリを使用するようにします。この変更は通常、1 つのファイル内の 1 行で済みます。これは、クライアント コードを変更して新しい型をインスタンス化するよりもはるかに簡単です。クライアント コードを変更すると、新しいオブジェクトが作成されるコード内のすべての場所を変更する必要があります。

ファクトリーは次の場合に使用できます。

1. オブジェクトを作成すると、コードを大幅に重複させずに再利用することは不可能になります。
2. オブジェクトを作成するには、構成クラス内に含めるべきではない情報またはリソースにアクセスする必要があります。
3. アプリケーション内で一貫した動作を確保するには、生成されたオブジェクトの有効期間を集中管理する必要があります。

ファクトリ、特にファクトリ メソッドはウィジェット ツールキットやソフトウェア フレームワークでよく使用されます。これらのフレームワークでは、ライブラリ コードで、フレームワークを使用するアプリケーションによってサブクラス化される可能性のある型のオブジェクトを作成する必要があります。

並列クラス階層では、多くの場合、ある階層のオブジェクトが別の階層の適切なオブジェクトを作成できるようにする必要があります。

ファクトリメソッドは、テスト駆動開発でクラスをテストするために使用されます。 ^[9]このようなクラスが、自動ユニットテストの対象とできないFoo別のオブジェクトを作成する場合（常に利用できるとは限らない実稼働データベースと通信するなど）、オブジェクトの作成はクラス の仮想ファクトリメソッド内に配置されます。テストでは、（ のサブクラス）が作成され、仮想ファクトリメソッドがオーバーライドされて、偽のオブジェクトが作成されて返されます。その後、ユニットテストで を使用して、実際のオブジェクトを使用する場合の副作用を招くことなくの機能をテストします。 DangerousDangerouscreateDangerousFooTestFooFoocreateDangerousFakeDangerousTestFooFooDangerous

デザイン パターンでの使用以外にも、ファクトリ、特にファクトリ メソッドにはさまざまな利点とバリエーションがあります。

ファクトリメソッドには、明確な名前があります。多くのオブジェクト指向言語では、コンストラクターの名前は、そのコンストラクターが属するクラスと同じである必要があります。そのため、オブジェクトを作成する方法が複数ある場合は、あいまいさが生じる可能性があります (オーバーロードを参照)。ファクトリ メソッドにはそのような制約はなく、わかりやすい名前を付けることができます。これらは、代替コンストラクターと呼ばれることもあります。たとえば、 2 つの実数から複素数を作成する場合、実数は直交座標または極座標として解釈できますが、ファクトリ メソッドを使用すると、次のC#の例に示すように、意味は明確になります。

パブリッククラスComplex { public double _real ; public double _imaginary ;  

      
      

    パブリックスタティックComplex FromCartesian ( double real 、double imaginary ) { return new Complex ( real 、imaginary ); }      
    
           
    

    パブリックスタティックComplex FromPolar ( double係数、double角度) { return new Complex (係数* Math . Cos (角度)、係数* Math . Sin (角度)); }      
    
               
    

    プライベートComplex ( double real 、double imaginary ) { this . _real = real ; this . _imaginary = imaginary ; } }    
    
          
          
    


複素積= Complex.FromPolar ( 1 , Math.PI ) ;​​​    

このように曖昧さを解消するためにファクトリ メソッドが使用される場合、クライアントにファクトリ メソッドの使用を強制するために、生のコンストラクターがプライベートにされることがよくあります。

ファクトリ メソッドは、オブジェクトの作成をカプセル化します。これは、作成プロセスが非常に複雑な場合、たとえば、構成ファイルの設定やユーザー入力に依存する場合に役立ちます。

例として、画像ファイルを読み取るプログラムを考えてみましょう。プログラムはさまざまな画像形式をサポートしており、各形式はリーダー クラスによって表されます。

プログラムがイメージを読み込むたびに、ファイル内の情報に基づいて適切なタイプのリーダーを作成する必要があります。このロジックは、ファクトリ メソッドにカプセル化できます。このアプローチは、シンプル ファクトリとも呼ばれています。

パブリッククラスImageReaderFactory {パブリックスタティックImageReader createImageReader ( ImageInputStreamProcessor iisp ) { if ( iisp . isGIF ()) { return new GifReader ( iisp . getInputStream ()); } else if ( iisp . isJPEG ()) { return new JpegReader ( iisp . getInputStream ()); } else { throw new IllegalArgumentException ( "不明な画像タイプです。" ); } } }   
         
          
              
        
           
              
        
         
              
        
    

クラス Factory 
{ 
    public  static  function  build ( string  $type ) :  FormatInterface 
    { 
        $class  =  "Format"  .  $type ; 
        return  new  $class ; 
    } 
}

インターフェース FormatInterface  {}

クラス FormatString は FormatInterface {}を実装します。 クラスFormatNumber はFormatInterface {}を実装します。 
    

try  { 
    $string  =  Factory :: build ( "String" ); 
}  catch  ( Error  $e )  { 
    echo  $e -> getMessage (); 
}

try  { 
    $number  =  Factory :: build ( "Number" ); 
}  catch  ( Error  $e )  { 
    echo  $e -> getMessage (); 
}

ファクトリ メソッドの使用には 3 つの制限があります。1 つ目は既存のコードのリファクタリングに関するもので、他の 2 つはクラスの拡張に関するものです。

• 最初の制限は、既存のクラスをファクトリを使用するようにリファクタリングすると、既存のクライアントが壊れてしまうことです。たとえば、Complex クラスが標準クラスである場合、次のようなコードを持つクライアントが多数存在する可能性があります。

  複素数c =新しい複素数( - 1 , 0 );     
  

2 つの異なるファクトリが必要であることがわかったら、クラスは変更されます (前述のコードに変更されます)。ただし、コンストラクターがプライベートになったため、既存のクライアント コードはコンパイルされなくなります。

• 2 番目の制限は、パターンがプライベート コンストラクターの使用に依存しているため、クラスを拡張できないことです。サブクラスは継承されたコンストラクターを呼び出す必要がありますが、そのコンストラクターがプライベートである場合はこれを行うことができません。
• 3つ目の制限は、クラスが拡張される場合（例えば、コンストラクタをprotectedにするなど、これはリスクがあるが実現可能）、サブクラスは、すべてのファクトリーメソッドをまったく同じシグネチャで再実装する必要があることです。たとえば、クラスがStrangeComplexを拡張する場合Complex、すべてのファクトリーメソッドの独自のバージョンを提供しない限りStrangeComplex、呼び出し

  StrangeComplex.FromPolar ( 1 , Math.Pi ) ;​​​ 
  

  Complexサブクラスの期待されるインスタンスではなく、スーパークラスのインスタンスが生成されます。一部の言語のリフレクション プログラミング(リフレクション) 機能を使用すると、この問題を回避できます。

これら3つの問題は、基礎となるプログラミング言語を変更してファクトリをファーストクラスのクラスメンバーにすることで軽減できる（仮想クラスも参照）。^[10]