डिजाइन पैटर्न: फैक्टरी बनाम फैक्टरी विधि बनाम सार फैक्टरी

Question

मैं एक वेबसाइट से डिज़ाइन पैटर्न पढ़ रहा था

वहां मैंने फैक्ट्री, फैक्ट्री पद्धति और एब्सट्रैक्ट फैक्ट्री के बारे में पढ़ा लेकिन वे इतनी भ्रामक हैं, परिभाषा पर स्पष्ट नहीं हैं। परिभाषाओं के अनुसार

फैक्टरी - ग्राहक के लिए तात्कालिकता तर्क को उजागर किए बिना वस्तुओं को बनाता है और एक सामान्य इंटरफ़ेस के माध्यम से नव निर्मित वस्तु को संदर्भित करता है। फैक्टरी विधि का एक सरलीकृत संस्करण है

फैक्ट्री मेथड - वस्तुओं को बनाने के लिए एक इंटरफ़ेस को परिभाषित करता है, लेकिन उपवर्गों को यह तय करने देता है कि किस वर्ग को एक सामान्य इंटरफ़ेस के माध्यम से नए बनाए गए ऑब्जेक्ट को तुरंत और संदर्भित करना चाहिए।

एब्सट्रैक्ट फैक्ट्री - संबंधित कक्षाओं के परिवार को स्पष्ट रूप से उनकी कक्षाओं को निर्दिष्ट किए बिना बनाने के लिए इंटरफ़ेस प्रदान करता है।

मैंने एब्सट्रैक्ट फैक्ट्री बनाम फैक्ट्री मेथड के बारे में अन्य स्टैकओवरफ्लो थ्रेड्स को भी देखा लेकिन यूएमएल आरेखों ने मेरी समझ को और भी खराब कर दिया।

क्या कोई मुझे बता सकता है

1. ये तीनों पैटर्न एक दूसरे से कैसे अलग हैं?
2. कब कौन सा उपयोग करें?
3. और यदि संभव हो तो, इन पैटर्न से संबंधित कोई जावा उदाहरण?

Comments

जब मैं ओपी के रूप में लगभग एक ही सवाल के जवाब की तलाश में था, तो मुझे यह लेख मिला: फ्रॉम नो फैक्ट्री टू फैक्ट्री मेथड । यह एक नमूना परियोजना के विकास का अनुसरण करके अंतर्दृष्टि प्रदान करता है (शीर्षक में वर्णित कारखाना विधि विकासवादी चरणों में से एक है)।

— निक अलेक्सिएव

Answer 1

सभी तीन कारखाने प्रकार एक ही काम करते हैं: वे एक "स्मार्ट कंस्ट्रक्टर" हैं।

मान लीजिए कि आप दो प्रकार के फल बनाने में सक्षम होना चाहते हैं: सेब और नारंगी।

फ़ैक्टरी

फैक्टरी "निश्चित" है, इसमें आपके पास केवल एक कार्यान्वयन है जिसमें कोई उपवर्ग नहीं है। इस मामले में, आपके पास इस तरह एक वर्ग होगा:

class FruitFactory {

  public Apple makeApple() {
    // Code for creating an Apple here.
  }

  public Orange makeOrange() {
    // Code for creating an orange here.
  }

}

मामले का उपयोग करें: या तो निर्माणकर्ता को संभालने के लिए एक एप्पल या ऑरेंज का निर्माण थोड़ा बहुत जटिल है।

फैक्टरी विधि

फैक्ट्री पद्धति का उपयोग आम तौर पर तब किया जाता है जब आपके पास किसी कक्षा में कुछ सामान्य प्रसंस्करण होते हैं, लेकिन आप वास्तव में किस प्रकार के फल का उपयोग करना चाहते हैं, यह अलग-अलग करना चाहते हैं। इसलिए:

abstract class FruitPicker {

  protected abstract Fruit makeFruit();

  public void pickFruit() {
    private final Fruit f = makeFruit(); // The fruit we will work on..
    <bla bla bla>
  }
}

... तो आप FruitPicker.pickFruit()उपवर्गों में एक कारखाना विधि को लागू करके आम कार्यक्षमता का पुन: उपयोग कर सकते हैं :

class OrangePicker extends FruitPicker {

  @Override
  protected Fruit makeFruit() {
    return new Orange();
  }
}

सार कारखाना

अमूर्त कारखाने का उपयोग आमतौर पर निर्भरता इंजेक्शन / रणनीति जैसी चीजों के लिए किया जाता है, जब आप वस्तुओं का एक पूरा परिवार बनाने में सक्षम होना चाहते हैं जो "एक ही तरह" की आवश्यकता होती है, और कुछ सामान्य आधार वर्ग होते हैं। यहाँ एक अस्पष्ट फल से संबंधित उदाहरण है। यहाँ उपयोग मामला यह है कि हम यह सुनिश्चित करना चाहते हैं कि हम गलती से एक Apple पर OrangePicker का उपयोग न करें। जब तक हम एक ही कारखाने से हमारे फल और पिकर प्राप्त करते हैं, वे मेल खाते हैं।

interface PlantFactory {

  Plant makePlant();

  Picker makePicker(); 

}

public class AppleFactory implements PlantFactory {
  Plant makePlant() {
    return new Apple();
  }

  Picker makePicker() {
    return new ApplePicker();
  }
}

public class OrangeFactory implements PlantFactory {
  Plant makePlant() {
    return new Orange();
  }

  Picker makePicker() {
    return new OrangePicker();
  }
}

Comments

+1 यह उत्तर है जो इन पैटर्नों की मेरी समझ के लिए सबसे अधिक समान है। कॉलिंग कोड (क्लाइंट) के उदाहरण जोड़ने से भी मदद मिलेगी? प्रश्न जो मुझे बहुत परेशान करता है: क्या हम कह सकते हैं कि एब्सट्रैक्ट फैक्ट्री पैटर्न सिर्फ फैक्ट्री मेथड पैटर्न के साथ फैक्ट्री है (यदि यह सच है, तो मैं इस विषय पर स्पष्ट हूं)?

— croraf

यह वह उदाहरण है जिसे मैंने बरसों से देखा है।

— ताज़टिंगो

यह एक शानदार व्याख्या है! धन्यवाद!

— एंड्रे एंड्रेड

@ AndréAndrade फैक्टरी विधि कैसे लागू करें ? एक छोटा कोड samle pls :) जो इसके उपयोग पर मेरे संदेह को स्पष्ट करेगा

— अर्नब दत्ता

Answer 2

1. ये तीनों पैटर्न एक दूसरे से कैसे अलग हैं?

फैक्टरी: ग्राहक के लिए तात्कालिकता तर्क को उजागर किए बिना वस्तुओं को बनाता है।

फैक्ट्री मेथड: किसी ऑब्जेक्ट को बनाने के लिए एक इंटरफेस को परिभाषित करें, लेकिन उपवर्गों को यह तय करने दें कि कौन सी क्लास को तत्काल करना है। फैक्टरी विधि उपवर्गों के लिए एक वर्ग आक्षेप को स्थगित करने देती है

सार फैक्टरी: संबंधित या आश्रित वस्तुओं के परिवारों को उनके ठोस वर्गों को निर्दिष्ट किए बिना बनाने के लिए एक इंटरफ़ेस प्रदान करता है।

एब्सट्रैक्ट पैटर्न किसी अन्य वर्ग को ऑब्जेक्ट बनाने की जिम्मेदारी सौंपने के लिए कंपोजीशन पैटर्न का उपयोग करता है जबकि फैक्ट्री मेथड डिजाइन पैटर्न इनहेरिटेंस का उपयोग करता है और ऑब्जेक्ट बनाने के लिए व्युत्पन्न क्लास या सब क्लास पर निर्भर करता है।

2. कब कौन सा उपयोग करें?

फैक्टरी: क्लाइंट को बस एक क्लास की जरूरत होती है और उसे इस बात की परवाह नहीं होती है कि उसे कौन सा ठोस कार्यान्वयन मिल रहा है।

फैक्ट्री विधि: क्लाइंट को यह पता नहीं होता है कि रनटाइम बनाने के लिए किन ठोस वर्गों की आवश्यकता होगी, लेकिन सिर्फ एक वर्ग प्राप्त करना चाहता है जो काम करेगा।

AbstactFactory: जब आपके सिस्टम को उत्पादों के कई परिवार बनाने होते हैं या आप कार्यान्वयन विवरणों को उजागर किए बिना उत्पादों का एक पुस्तकालय प्रदान करना चाहते हैं।

सार फैक्ट्री कक्षाएं अक्सर फैक्ट्री विधि के साथ लागू की जाती हैं। फैक्ट्री मेथड्स को आमतौर पर टेम्प्लेट मेथड के भीतर कहा जाता है।

3. और यदि संभव हो तो, इन पैटर्न से संबंधित कोई जावा उदाहरण?

फैक्टरी और FactoryMethod

आशय:

एक ऑब्जेक्ट बनाने के लिए एक इंटरफ़ेस को परिभाषित करें, लेकिन उप-वर्गों को यह तय करने दें कि किस क्लास को तत्काल करना है। फैक्ट्री मेथड एक क्लास को सब क्लास में तत्काल डिफरेंशन देता है।

यूएमएल आरेख :

उत्पाद: यह उन फैक्टर्स के इंटरफ़ेस को परिभाषित करता है जो फ़ैक्टरी विधि बनाती है।

कंक्रीटप्रोडक्ट: इम्प्लीमेंट्स उत्पाद इंटरफ़ेस

निर्माता: फैक्टरी विधि की घोषणा करता है

ConcreateCreator: एक कंक्रीटप्रोडक्ट की आवृत्ति वापस करने के लिए फ़ैक्टरी विधि लागू करता है

समस्या कथन: फ़ैक्टरी विधियों का उपयोग करके खेलों का एक कारखाना बनाएँ, जो खेल इंटरफ़ेस को परिभाषित करता है।

सांकेतिक टुकड़ा:

फैक्टरी पैटर्न। कारखाने के तरीकों का उपयोग कब करें?

अन्य रचनात्मक पैटर्न के साथ तुलना:

1. डिज़ाइनर फैक्ट्री मेथड (कम जटिल, अधिक अनुकूलन योग्य, उपवर्ग प्रोलिफ़रेट) का उपयोग करके शुरू होता है और डिज़ाइनर पता चलता है जहाँ डिज़ाइनर को अधिक लचीलेपन की आवश्यकता होती है, वहां एब्सट्रैक्ट फ़ैक्टरी, प्रोटोटाइप या बिल्डर (अधिक लचीला, अधिक जटिल) की ओर विकसित होता है।

2. एब्सट्रैक्ट फैक्ट्री क्लासेस को अक्सर फैक्ट्री मेथड्स के साथ लागू किया जाता है , लेकिन उन्हें प्रोटोटाइप का उपयोग करके भी लागू किया जा सकता है

आगे पढ़ने के लिए संदर्भ: सोर्सिंग डिजाइन-पैटर्न

Comments

फैक्ट्री मेथड के लिए, क्या इसे सुपरक्लास परिभाषित नहीं किया जाना चाहिए?

— टोनी लिन

Answer 3

फैक्ट्री - जटिल वस्तु बनाने के लिए अलग से फैक्ट्री क्लास।

Ex: फलों की वस्तु बनाने के लिए FruitFactory वर्ग

class FruitFactory{

public static Fruit getFruit(){...}

}

फैक्ट्री मेथड - फैक्ट्री के लिए पूरे अलग वर्ग के बजाय, उस क्लास में केवल एक विधि को एक फैक्ट्री के रूप में जोड़ें।

उदाहरण के लिए:

Calendar.getInstance() (Java's Calendar)

सार कारखाना विधि - कारखाने का कारखाना

Ex: आओ हम कंप्यूटर भागों के लिए कारखाना बनाना चाहते हैं। तो कई प्रकार के कंप्यूटर होते हैं जैसे लैपटॉप, डेस्कटॉप, सर्वर।

इसलिए प्रत्येक कंपार्टमेंट प्रकार के लिए हमें कारखाने की आवश्यकता होती है। तो हम नीचे की तरह कारखानों का एक हाईलेवल कारखाना बनाते हैं

ComputerTypeAbstractFactory.getComputerPartFactory(String computerType) ---> This will return PartFactory which can be one of these ServerPartFactory, LaptopPartFactory, DesktopPartFactory.

अब ये 3 ही फिर से कारखाने हैं। (आप स्वयं पार्टफैक्ट्री के साथ काम कर रहे होंगे, लेकिन हुड के तहत, अमूर्त कारखाने में आपने जो प्रदान किया है, उसके आधार पर अलग कार्यान्वयन होगा)

  Interface-> PartFactory. getComputerPart(String s), 
Implementations -> ServerPartFactory, LaptopPartFactory, DesktopPartFactory.

Usage:
new ComputerTypeAbstractFactory().getFactory(“Laptop”).getComputerPart(“RAM”)

संपादित करें: टिप्पणियों में आपत्तियों के अनुसार सार फैक्टरी के लिए सटीक इंटरफेस प्रदान करने के लिए संपादित किया गया।

Comments

इसके पीछे विचार यह ComputerFactoryहोगा कि आपके पास एक सामान्य निर्माण इंटरफ़ेस ( getScreen(); getKeyboard(); getDiskdrive(); ...) है, जैसा कि आपके सुझाव के अनुसार प्रति कंप्यूटर प्रकार का इंटरफ़ेस नहीं है। यदि आप एक ही कथन में एक ही शब्द का दो बार उपयोग करते हैं, तो आप एक डिज़ाइन समस्या को सूँघ सकते हैं: Laptop Factory.get Laptop Part ()।

— xtofl

नहीं नहीं नहीं, कोड पर बिल्कुल मत जाओ। यह समझने के लिए सिर्फ एक धर्मशास्त्र था। यदि आप इंटरफेस के साथ सटीक उदाहरण चाहते हैं, तो यह है। ऑब्जेक्ट: इंटरफ़ेस -> कंप्यूटरपार्ट, कार्यान्वयन -> रैम, एचडीडी, प्रोसेसर फैक्टरी: इंटरफ़ेस-> पार्टफैक्टरी। getComputerPart (स्ट्रिंग s), कार्यान्वयन -> ServerPartFactory, LaptopPartFactory, DesktopPartFactory। सार फैक्टरी: ComputerType.getPartFactory ("स्ट्रिंग s") उपयोग: नया ComputerType ()। getFactory ("लैपटॉप") getComputerPart ("RAM")

— रवि K

मैंने आपकी चिंता का ख्याल रखने के लिए अद्यतन उत्तर दिया है। वास्तव में अमूर्त कारखाना केवल कारखाने के तथ्य के अलावा और कुछ नहीं है। मैंने पहले उदाहरण केवल संदर्भ के लिए दिया था (मान लें कि पाठक वास्तविक कार्यान्वयन के दौरान इंटरफेस का ध्यान रखेंगे)। फिर भी सूचित करने के लिए धन्यवाद। इसका सुधार करना हमेशा अच्छा होता है। :)

— रवि के

नहीं abstract Factory, कारखाने का कारखाना नहीं है ... यह एक abstract classया एक interfaceवस्तु बनाने में सक्षम है जिसे विभिन्न कंक्रीट कारखानों के साथ लागू / विस्तारित किया जाएगा। कोड विवरण के लिए स्वीकृत उत्तर देखें। और कृपया अपने उत्तर को अपने अनुसार निकालें या संपादित करें।

— जुलिएन__

मुझे फैक्ट्री पद्धति की व्याख्या पसंद है, जो कि इतना नाम क्यों है इसका अनावरण करने के लिए पर्याप्त है। इस पैटर्न में, कारखाना विधि है, न कि वह वर्ग जो आमतौर पर सहायक विधियों को बनाने में सहायक सहायक समूह नहीं है, बल्कि अपने आप ही सार्थक है। अन्य अधिक विस्तृत जवाब दुर्भाग्य से इस बिंदु से चूक गए।

— wlnirvana

Answer 4

प्रत्येक डिज़ाइन पैटर्न यह सुनिश्चित करने में मदद करता है कि लिखित, कार्य कोड को छुआ नहीं गया है। हम सभी जानते हैं कि एक बार जब हम काम करने वाले कोड को छू लेते हैं, तो मौजूदा कार्य प्रवाह में दोष होते हैं, और यह सुनिश्चित करने के लिए बहुत अधिक परीक्षण की आवश्यकता होती है कि हमने कुछ भी नहीं तोड़ा।

एक फैक्ट्री पैटर्न इनपुट मानदंड के आधार पर वस्तुओं का निर्माण करता है, इस प्रकार यह सुनिश्चित करता है कि आपको कोड लिखने की आवश्यकता नहीं है यदि ऐसा है तो इस तरह का ऑब्जेक्ट बनाएं और इस तरह का ऑब्जेक्ट बनाएं। इसका एक अच्छा उदाहरण एक यात्रा वेबसाइट है। एक यात्रा वेबसाइट केवल यात्रा (उड़ान, ट्रेन, बस) या / प्रदान कर सकती है और होटल या / और पर्यटक आकर्षण पैकेज प्रदान कर सकती है। अब, जब कोई उपयोगकर्ता अगले का चयन करता है, तो वेबसाइट को यह तय करने की आवश्यकता होती है कि उसे किन वस्तुओं को बनाने की आवश्यकता है। क्या यह केवल यात्रा या होटल की वस्तु भी बनाना चाहिए।

अब, यदि आप अपने पोर्टफोलियो में किसी अन्य वेबसाइट को जोड़ने की कल्पना करते हैं, और आप मानते हैं कि उसी कोर का उपयोग किया जाता है, उदाहरण के लिए, एक कारपूलिंग वेबसाइट, जो अब कैब की खोज करती है और ऑनलाइन भुगतान करती है, तो आप अपने कोर पर एक अमूर्त कारखाने का उपयोग कर सकते हैं। इस तरह से आप बस कैब और कारपूल के एक और कारखाने में तस्वीर लगा सकते हैं।

दोनों फैक्ट्री का एक-दूसरे से कोई लेना-देना नहीं है, इसलिए इसका अलग-अलग फैक्ट्री में रखने के लिए अच्छा डिजाइन है।

उम्मीद है कि यह अब स्पष्ट है। इस उदाहरण को ध्यान में रखते हुए वेबसाइट का फिर से अध्ययन करें, उम्मीद है कि इससे मदद मिलेगी। और मुझे वास्तव में उम्मीद है कि मैंने पैटर्न का सही ढंग से प्रतिनिधित्व किया है :)।

Answer 5

इस उत्तर के लिए, मैं "गैंग ऑफ़ फोर" पुस्तक का उल्लेख करता हूँ।

हैं कोई "फैक्टरी" और न ही "सरल फैक्टरी" और न ही "आभासी फैक्टरी" पुस्तक में परिभाषाओं। आमतौर पर जब लोग "फैक्टरी" पैटर्न के बारे में बात कर रहे होते हैं, तो वे किसी ऐसी चीज के बारे में बात कर सकते हैं जो एक वर्ग की एक विशेष वस्तु बनाता है (लेकिन "बिल्डर" पैटर्न नहीं); वे "फ़ैक्टरी विधि" या "एब्सट्रैक्ट फ़ैक्टरी" पैटर्न का उल्लेख कर सकते हैं या नहीं भी कर सकते हैं । कोई भी "फ़ैक्टरी" को लागू कर सकता है क्योंकि वह ऐसा नहीं करेगा क्योंकि यह कोई औपचारिक शब्द नहीं है (ध्यान रखें कि कुछ लोगों की कंपनियों के समुदायों की अपनी शब्दावली हो सकती है)।

पुस्तक में केवल "एब्सट्रैक्ट फ़ैक्टरी" और "फ़ैक्टरी विधि" की परिभाषाएँ हैं।

यहाँ पुस्तक की परिभाषाएँ हैं और दोनों का इतना संक्षिप्त विवरण क्यों इतना भ्रमित कर सकता है। मैं कोड उदाहरणों को छोड़ देता हूं क्योंकि आप उन्हें अन्य उत्तरों में पा सकते हैं:

फैक्ट्री मेथड (GOF) : ऑब्जेक्ट बनाने के लिए एक इंटरफ़ेस को परिभाषित करें, लेकिन उपवर्गों को यह तय करने दें कि कौन सी क्लास को तुरंत करना है। फैक्ट्री मेथड उपवर्गों को एक क्लास डिफरेंट इन्फ्रारेड की सुविधा देता है।

एब्सट्रैक्ट फैक्ट्री (GOF) : अपने ठोस वर्गों को निर्दिष्ट किए बिना संबंधित या आश्रित वस्तुओं के परिवारों को बनाने के लिए एक इंटरफ़ेस प्रदान करें।

भ्रम का स्रोत : अक्सर, कोई भी व्यक्ति "फ़ैक्टरी विधि" पैटर्न में "फ़ैक्टरी" के रूप में उपयोग किया जा सकता है। यह वर्ग परिभाषा के अनुसार सारगर्भित है। इसलिए इस वर्ग को "एब्सट्रैक्ट फैक्ट्री" कहना आसान है। लेकिन यह सिर्फ कक्षा का नाम है; आपको इसे "एब्सट्रैक्ट फैक्ट्री" पैटर्न (वर्ग नाम! = पैटर्न नाम) के साथ भ्रमित नहीं करना चाहिए। "एब्सट्रैक्ट फ़ैक्ट्री" पैटर्न अलग है - यह एक अमूर्त वर्ग का उपयोग नहीं करता है ; यह एक बड़ी वस्तु या वस्तुओं के हिस्सों को बनाने के लिए एक इंटरफ़ेस (जरूरी नहीं कि एक प्रोग्रामिंग भाषा इंटरफ़ेस) को परिभाषित करता है जो एक दूसरे से संबंधित हैं या किसी विशेष तरीके से बनाए जाने चाहिए।

Answer 6

AbstractProductA, A1 and A2 both implementing the AbstractProductA
AbstractProductB, B1 and B2 both implementing the AbstractProductB

interface Factory {
    AbstractProductA getProductA(); //Factory Method - generate A1/A2
}

फैक्ट्री मेथड का उपयोग करके, उपयोगकर्ता एब्सट्रैक्टप्रोडक्टा का A1 या A2 बनाने में सक्षम हो सकता है।

interface AbstractFactory {
    AbstractProductA getProductA(); //Factory Method
    AbstractProductB getProductB(); //Factory Method
}

लेकिन सार फैक्ट्री में 1 से अधिक फैक्ट्री मेथड (उदा: 2 फैक्ट्री मेथड) होते हैं, उन फैक्ट्री विधियों का उपयोग करके यह वस्तुओं / संबंधित वस्तुओं के सेट का निर्माण करेगा। एब्सट्रैक्ट फैक्ट्री के उपयोग से, उपयोगकर्ता एब्सट्रैक्टप्रोडक्टा, एब्सट्रैक्टप्रोडक्शन के A1, B1 ऑब्जेक्ट्स बनाने में सक्षम हो सकता है

Answer 7

किसी ने भी मूल पुस्तक के डिजाइन पैटर्न को उद्धृत नहीं किया है : पुन: प्रयोज्य ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर के तत्व , जो अनुभाग के पहले दो पैराग्राफ में जवाब देता है "रचनात्मक पैटर्न की चर्चा" (जोर मेरा):

वस्तुओं के वर्गों द्वारा एक प्रणाली को पैरामीटर बनाने के दो सामान्य तरीके हैं। एक रास्ता उपवर्ग का है वर्ग है कि वस्तुओं बनाता है; यह फ़ैक्टरी विधि (107) पैटर्न का उपयोग करने से मेल खाती है। इस दृष्टिकोण का मुख्य दोष यह है कि इसे उत्पाद के वर्ग को बदलने के लिए एक नए उपवर्ग की आवश्यकता हो सकती है। इस तरह के बदलाव कैस्केड कर सकते हैं। उदाहरण के लिए, जब उत्पाद निर्माता खुद एक कारखाना विधि द्वारा बनाया जाता है, तो आपको इसके निर्माता को भी ओवरराइड करना होगा।

किसी सिस्टम को पैरामीटर बनाने का दूसरा तरीका ऑब्जेक्ट कंपोजीशन पर अधिक निर्भर करता है : एक ऑब्जेक्ट को परिभाषित करें जो उत्पाद ऑब्जेक्ट्स के वर्ग को जानने के लिए जिम्मेदार है, और इसे सिस्टम का एक पैरामीटर बनाता है। यह एब्सट्रैक्ट फैक्ट्री (87), बिल्डर (97), और प्रोटोटाइप (117) पैटर्न का एक प्रमुख पहलू है। तीनों में एक नया "फ़ैक्टरी ऑब्जेक्ट" बनाना शामिल है जिसकी ज़िम्मेदारी उत्पाद वस्तुओं को बनाना है। एब्सट्रैक्ट फैक्ट्री में कई वर्गों की वस्तुओं का उत्पादन करने वाली फैक्ट्री है। बिल्डर के पास फैक्ट्री ऑब्जेक्ट है जो एक जटिल उत्पाद का निर्माण करता है एक समान रूप से जटिल प्रोटोकॉल का उपयोग करके। प्रोटोटाइप में किसी वस्तु के प्रोटोटाइप ऑब्जेक्ट की प्रतिलिपि बनाकर फ़ैक्टरी ऑब्जेक्ट है। इस मामले में, फैक्टरी ऑब्जेक्ट और प्रोटोटाइप एक ही ऑब्जेक्ट हैं, क्योंकि उत्पाद को वापस करने के लिए प्रोटोटाइप जिम्मेदार है।