क्या फैक्टरी पैटर्न काम करता है?

Question

सिंगलटन और रजिस्ट्री पैटर्न मेरे लिए तुरंत समझने के लिए बहुत ही सरल और आसान थे लेकिन कारखाना पैटर्न कुछ ऐसा रहा है जो मैं अपने दिमाग को 100% की व्याख्या करने में सक्षम नहीं हूं। मुझे लगता है कि मैं इसे अब समझ सकता हूं, मैंने नीचे एक नमूना कोड लिखा है, कृपया समीक्षा करें और मुझे बताएं कि क्या यह फैक्टरी पैटर्न का उचित उपयोग है। नमूना PHP में है ...

<?php 
/** 
* Factory.class.php 
*/ 
class Factory { 
    public static $_database; 
    public static $_cache; 
    public static $_session; 

    // Build our User object with all it's dependencies 
    public static function makeUserObject() 
    { 
     $user = new User(); 
     $user->setDatabaseObject(self::$_database); 
     $user->setCacheObject(self::$_cache); 
     $user->setSessionObject(self::$_session); 
     return $user; 
    } 

    // other objects will be here someday...... 
} 

/** 
* User.class.php 
*/ 
class User 
{ 
    public function __construct() { } 

    // inject Database Object 
    public function setDatabaseObject($databaseConnectionObject) 
    { 
     $this->_databaseObject = $databaseConnectionObject; 
    } 

    // inject Cache Object 
    public function setCacheObject($cacheObject) 
    { 
     $this->_cacheObject = $cacheObject; 
    } 

    // inject Session Object 
    public function setSessionObject($sessionObject) 
    { 
     $this->_sessionObject = $sessionObject; 
    } 

    // other methods here for User object........... 
} 

/** 
* index.php Main page that puts it all together 
* assume that classes are autoloaded into this page already 
*/ 
// Set our Database + Cache + Session objects into the Factory Object 
Factory::$_database = new Databse(); 
Factory::$_cache = new Cache(); 
Factory::$_session = new Session(); 

// Create our User object 
// The factory class will build the User object and inject all 
// it's dependencies for us =) 
$user = Factory::makeUserObject(); 

?> 

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

---

अद्यतन # 1

यह इस यहाँ एक ब्लॉग पोस्ट मैं यहाँ पढ़ http://www.potstuck.com/2009/01/08/php-dependency-injection/ वे एक "फैक्टरी" ही कहते हैं पर आधारित है, मैं गया एक रजिस्ट्री का उपयोग करके और बहुत से लोग मुझे "फैक्ट्री" में देखने के लिए कह रहे हैं और जो कुछ भी मैंने पढ़ा है, वह अभी तक मेरे सिर पर क्लिक नहीं किया जब तक कि मैं इस कलाकृति को पढ़ता हूं लेकिन ऐसा लगता है कि यह "कारखाना" नहीं है?

---

अद्यतन # 2
wikipedia http://en.wikipedia.org/wiki/Factory_object वस्तु उन्मुख कंप्यूटर प्रोग्रामिंग में से, एक कारखाने वस्तु अन्य वस्तुओं बनाने के लिए एक वस्तु है। यह एक कन्स्ट्रक्टर का एक अमूर्त है, और इसका इस्तेमाल सिंगलटन पैटर्न जैसे विभिन्न आवंटन योजनाओं को लागू करने के लिए किया जा सकता है। एक फैक्ट्री ऑब्जेक्ट में आम तौर पर हर प्रकार की वस्तु के लिए एक विधि होती है जो इसे बनाने में सक्षम होती है। ये विधियां वैकल्पिक रूप से मानकों को स्वीकार करती हैं कि ऑब्जेक्ट कैसे बनाया जाता है, और फिर बनाई गई वस्तु को वापस कर दें। फैक्ट्री ऑब्जेक्ट्स उन परिस्थितियों में उपयोग किए जाते हैं जहां किसी विशेष प्रकार की वस्तु को पकड़ना एक नई वस्तु बनाने से अधिक जटिल प्रक्रिया है। फैक्ट्री ऑब्जेक्ट ऑब्जेक्ट की क्लास (यदि लागू हो) गतिशील रूप से बनाने का निर्णय ले सकता है, इसे ऑब्जेक्ट पूल से वापस कर सकता है, ऑब्जेक्ट पर जटिल कॉन्फ़िगरेशन कर सकता है, या अन्य चीजें।

तो शायद यह एक "फैक्टरी ऑब्जेक्ट" एक तरह से afterall में है ...

Answer 1

सारांशित और प्रश्न यहाँ

नीचे से मेरी टिप्पणी बढ़ाया तरह अन्य लोगों ने कहा, यह एक फैक्टरी नहीं है बस क्योंकि इस नाम के साथ एक पैटर्न मौजूद नहीं है। यह या तो सार फैक्टरी या फैक्टरी मोड है, हालांकि व्यावहारिक रूप से लोग अक्सर या तो फैक्टरी कहकर या यह मेरे साथ ठीक है।

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

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

यदि आप इसके लिए DI कंटेनर अब का उपयोग नहीं करना चाहते हैं, तो आप Zend_Application and how they bootstrap resources पर एक नज़र डाल सकते हैं। यह एक विकल्प है और add DI containers later.

वास्तव में, आपके पिछले प्रश्नों में से बहुत से विषयों को ज़ेंड फ्रेमवर्क में पहले ही हल किया गया है, उदाहरण के लिए छोड़ दिया गया है। कक्षाएं कॉन्फ़िगर करें। मैं ज़ेडएफ का उपयोग नहीं कह रहा हूं, लेकिन आप यह देखने के लिए देख सकते हैं कि वे चीजें कैसे करते हैं। बेशक, आप otherframeworks पर भी देख सकते हैं।

पीएचपी उदाहरण के साथ कुछ पैटर्न साइटें:

• http://sourcemaking.com/creational_patterns
• http://www.fluffycat.com/PHP-Design-Patterns/
• http://www.ibm.com/developerworks/library/os-php-designptrns/?S_TACT=105AGX44&S_CMP=ART
• http://www.ibm.com/developerworks/opensource/library/os-php-designpatterns/index.html?ca=drs-tp1308

Answer 2

अधिक मेरे लिए बिल्डर पैटर्न की तरह लग रहा। वास्तव में आप किस फैक्ट्री पैटर्न का मतलब रखते थे, AbtractFactory या FactoryMethod? हालांकि, वे दोनों विरासत से निपटते हैं और आप कोड सिर्फ "जटिल" वस्तु को इकट्ठा करते हैं।

Answer 3

शामिल नहीं है मेरे लिए एक कारखाने की तरह लग रहे - एक के अंदर से बाहर बिल्डर हो सकता है; 0)

फैक्टरी कार्यान्वयन और इन्स्टेन्शियशन छुपा का एक तरीका है?। और वहाँ आम तौर पर कुछ विधानसभा किया जा रहा है, लेकिन संक्षेप में ....

public interface IUser 
    { 
     void DoSomething(); 
    } 

    public class DumbUser : IUser 
    { 

     public void DoSomething() 
     { 
      // duh... what should i do? 
     } 

    } 

    public class SmartUser : IUser 
    { 

     public void DoSomething() 
     { 
      // calclulating prime numbers while baking bread 
     } 

    } 


    public class UserFactory 
    { 
     public static IUser CreateUser() 
     { 
      Random r = new Random(Environment.TickCount); 

      return r.Next(10) > 5 ? (IUser) new SmartUser() : new DumbUser(); 
     } 
    } 

    public class YourProgram 
    { 
     public void Run() 
     { 
      IUser user = UserFactory.CreateUser(); 
      user.DoSomething(); 
     } 
    } 

Answer 4

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

फैक्ट्री विधि का विचार ढांचे से संबंधित है: आप कुछ ढांचे कोड में उपयोग करना चाहते हैं, लेकिन वास्तविक उपयोगकर्ता कार्यान्वयन व्युत्पन्न कक्षाओं में है, यानी आपके ढांचे के उपयोगकर्ता अपने स्वयं के ऐप लिख रहे हैं - यही वह समय है जब आप आपके ढांचे के उपयोगकर्ता को बताने की जरूरत है "अब उपयोगकर्ता ऑब्जेक्ट बनाएं", जो फ़ैक्टरी विधि पर कॉल है। उपयोगकर्ता को इसे लागू करना होगा। इसे गोफ के अनुसार वर्चुअल कंस्ट्रक्टर भी कहा जाता है।

बिल्डर आमतौर पर तब उपयोग किया जाता है जब वस्तु के विभिन्न प्रतिनिधित्व होते हैं, जो वास्तव में यहां मामला नहीं है। मेरी आंखों में, कैश, डेटाबेस और सत्र को सिंगलेट्स के रूप में कार्यान्वित किया जा सकता है, इस प्रकार शामिल जटिलताओं को आसान बनाते हैं। अन्यथा, मैं एक सेवा लोकेटर का उपयोग करने का सुझाव दूंगा जो आपको GetDatabase, GetSession इत्यादि की अनुमति देता है। फिर, आपको सृजन पर उपयोगकर्ता ऑब्जेक्ट (और कई अन्य ऑब्जेक्ट्स) में लोकेटर को पास करना होगा। उलझन यह है कि इस लोकेटर को विभिन्न वर्गों में पुन: उपयोग किया जा सकता है।

Answer 5

यह कारखाना पैटर्न ठीक है, लेकिन आपको इसे Factory पर कॉल करने से बेहतर नामकरण सम्मेलन की आवश्यकता हो सकती है। इसके अलावा इसमें निर्भरता इंजेक्शन का निशान भी शामिल है।

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

उदाहरण के लिए, StackOverflow उपयोगकर्ताओं को उनके प्रतिष्ठा स्कोर के आधार पर विभिन्न अधिकार देता है। परिकल्पित शब्दों में, यह उपयोगकर्ताओं के निम्नलिखित प्रकार हो सकता है:

NewbieUser  [1-100] 
BeginnerUser [101-1000] 
AverageJoeUser [1001-5000] 
VeteranUser  [5001-20000] 
PowerUser  [20001-50000] 
GodModeUser  [50001-100000] 

और यदि कोई उपयोगकर्ता अपने प्रतिनिधि को देख द्वारा बनाई जा सकती है। और कक्षा को सीधे संदर्भित करके संबंधित उपयोगकर्ता ऑब्जेक्ट को तुरंत चालू करना। यदि आप सोच रहे हैं तो जॉन स्कीट किसी भी श्रेणी में प्रकट नहीं होता है। यहाँ प्रत्यक्ष इन्स्टेन्शियशन साथ एक भद्दा कार्यान्वयन है:

if(reputation >= 1001 and reputation <= 5000) { 
    AverageJoeUser user = new AverageJoeUser(); 
} 

तो बाद में सड़क हम वर्ग के नाम या जिस तरह से उपयोगकर्ताओं को बदलने के लिए थे नीचे instantiated कर रहे थे, हर एक ऐसा उदाहरण दिया जहां लक्ष्य बनाया गया था होता पाया जाता है और परिवर्तित करने की। यदि आप मुझसे पूछें तो काफी काम है। इसके बजाए, अगर हमने यहां फैक्ट्री पैटर्न का इस्तेमाल किया था, तो बदलाव फैक्टरी वर्ग के अंदर एक ही विधि में जाएगा।

class UserFactory { 
    public static User createUser(Integer reputation) { 
     ... 
    } 
}