🍿 🤘🏻 📺 स्विफ्ट और आईओएस यूनिवर्स में फैक्ट्री मेथड और एब्सट्रैक्ट फैक्ट्री 🤭 🍆 🗽

शब्द "कारखाना" प्रोग्रामर द्वारा उनके (या अन्य) कार्यक्रमों पर चर्चा करते समय सबसे अधिक बार उपयोग किया जाता है। लेकिन इसमें अंतर्निहित अर्थ बहुत अलग हो सकता है: यह एक ऐसा वर्ग हो सकता है जो वस्तुओं को उत्पन्न करता है (बहुरूपी या नहीं); और एक विधि जो किसी भी प्रकार (स्थिर या नहीं) के उदाहरण बनाती है; यह होता है, और यहां तक कि सिर्फ किसी भी निर्माण विधि ( निर्माणकर्ताओं सहित)।

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

और मुझे यह निबंध जोशुआ केरिव्स्की ( "औद्योगिक तर्क" के प्रमुख ) द्वारा लिखने के लिए प्रेरित किया गया था, या बल्कि, उनकी पुस्तक "रिफैक्टिंग टू पैटर्न" , जो कि शताब्दी की शुरुआत में मार्टिन फावलर द्वारा स्थापित पुस्तकों की एक श्रृंखला के भाग के रूप में प्रकाशित हुई थी (आधुनिक प्रोग्रामिंग क्लासिक के प्रसिद्ध लेखक - पुस्तक " पुस्तक " परावर्तन " )। अगर किसी ने पहली बार (या मुझे बहुत कुछ पता है) पढ़ा या सुना भी नहीं है, तो इसे अपनी रीडिंग लिस्ट में ज़रूर शामिल करें। यह Refactoring और एक और भी अधिक क्लासिक पुस्तक, Objective Design Techniques के लिए एक योग्य अगली कड़ी है । डिजाइन पैटर्न

अन्य बातों के अलावा, इस पुस्तक में डिज़ाइन पैटर्न का उपयोग करके कोड में विभिन्न "गंध" से छुटकारा पाने के लिए दर्जनों व्यंजन शामिल हैं। चर्चा के तहत विषय पर तीन (कम से कम) "व्यंजनों" सहित।

सार कारखाना

अपनी पुस्तक में केरिव्स्की ने दो मामले दिए हैं जहां इस टेम्पलेट का उपयोग उपयोगी होगा।

पहला एक सामान्य इंटरफ़ेस द्वारा जुड़े विशिष्ट वर्गों के बारे में ज्ञान का अंतराल है । इस मामले में, केवल उस प्रकार का कारखाना है जिसके पास यह ज्ञान होगा। फैक्ट्री की सार्वजनिक एपीआई में तरीकों का एक सेट (स्थिर या नहीं) शामिल होगा जो एक सामान्य इंटरफ़ेस प्रकार के उदाहरण लौटाते हैं और कुछ "बात कर रहे" नाम हैं (यह समझने के लिए कि किस विधि को किसी विशेष उद्देश्य के लिए कॉल करने की आवश्यकता है)।

दूसरा उदाहरण पहले के समान है (और, सामान्य तौर पर, पैटर्न का उपयोग करने के लिए सभी परिदृश्य एक-दूसरे के समान कमोबेश हैं)। यह वह स्थिति है जब कार्यक्रम में विभिन्न स्थानों में एक या अधिक प्रकार के एक ही समूह के उदाहरण बनते हैं। इस मामले में, कारखाना फिर से कोड के बारे में ज्ञान का विस्तार करता है जो उदाहरणों को बनाता है, लेकिन थोड़ी अलग प्रेरणा के साथ। उदाहरण के लिए, यह विशेष रूप से सच है अगर इन प्रकार के उदाहरणों को बनाने की प्रक्रिया जटिल है और निर्माणकर्ता को कॉल करने तक सीमित नहीं है।

"IOS" के तहत विकास के विषय के करीब होने के लिए, UIViewController उपवर्गों का अभ्यास करना सुविधाजनक है। वास्तव में, यह निश्चित रूप से "आईओएस" विकास में सबसे आम प्रकारों में से एक है, यह उपयोग से पहले लगभग हमेशा "विरासत में मिला" है, और एक विशेष उपवर्ग अक्सर ग्राहक कोड के लिए भी महत्वपूर्ण नहीं है।

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

विस्तृत उदाहरण

मान लीजिए कि हम एक आवेदन में वाहनों का व्यापार कर रहे हैं, और मानचित्रण विशिष्ट वाहन के प्रकार पर निर्भर करता है: हम विभिन्न वाहनों के लिए UIViewController विभिन्न उपवर्गों का उपयोग करेंगे। इसके अलावा, सभी वाहन राज्य में भिन्न होते हैं (नए और प्रयुक्त):

 enum VehicleCondition{ case new case used } final class BicycleViewController: UIViewController { private let condition: VehicleCondition init(condition: VehicleCondition) { self.condition = condition super.init(nibName: nil, bundle: nil) } required init?(coder aDecoder: NSCoder) { fatalError("BicycleViewController: init(coder:) has not been implemented.") } } final class ScooterViewController: UIViewController { private let condition: VehicleCondition init(condition: VehicleCondition) { self.condition = condition super.init(nibName: nil, bundle: nil) } required init?(coder aDecoder: NSCoder) { fatalError("ScooterViewController: init(coder:) has not been implemented.") } }

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

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

तो, आइए एक इंटरफ़ेस घोषित करें जो "अमूर्त कारखाने" की भूमिका निभाएगा:

 protocol VehicleViewControllerFactory { func makeBicycleViewController() -> UIViewController func makeScooterViewController() -> UIViewController }

( स्विफ्ट में एपीआई के लिए एक काफी छोटा "डिज़ाइन गाइडलाइन" शब्द बनाने से शुरू होने वाले कारखाने के तरीकों को कॉल करने की सिफारिश करता है।)

(चार के गिरोह की पुस्तक में उदाहरण "C ++" में दिया गया है और यह वंशानुक्रम और "आभासी" कार्यों पर आधारित है। "स्विफ्ट" का उपयोग करते हुए, निश्चित रूप से, प्रोटोकॉल-उन्मुख प्रोग्रामिंग प्रतिमान हमारे करीब है।)

एब्सट्रैक्ट फ़ैक्टरी इंटरफ़ेस में केवल दो विधियाँ शामिल हैं: साइकिल और स्कूटर बेचने के लिए नियंत्रक बनाने के लिए। विधियाँ विशिष्ट उपवर्गों की नहीं, बल्कि एक सामान्य आधार वर्ग की वापसी करती हैं। इस प्रकार, विशिष्ट प्रकारों के बारे में ज्ञान का दायरा उस क्षेत्र तक सीमित है जिसमें यह वास्तव में आवश्यक है।

"कंक्रीट कारखानों" के रूप में हम अमूर्त कारखाने इंटरफ़ेस के दो कार्यान्वयन का उपयोग करेंगे:

 struct NewVehicleViewControllerFactory: VehicleViewControllerFactory { func makeBicycleViewController() -> UIViewController { return BicycleViewController(condition: .new) } func makeScooterViewController() -> UIViewController { return ScooterViewController(condition: .new) } } struct UsedVehicleViewControllerFactory: VehicleViewControllerFactory { func makeBicycleViewController() -> UIViewController { return BicycleViewController(condition: .used) } func makeScooterViewController() -> UIViewController { return ScooterViewController(condition: .used) } }

इस मामले में, जैसा कि कोड से देखा जा सकता है, विशिष्ट कारखाने विभिन्न स्थितियों (नए और उपयोग) के वाहनों के लिए जिम्मेदार हैं।

सही नियंत्रक बनाना अब कुछ इस तरह दिखाई देगा:

 let factory: VehicleViewControllerFactory = NewVehicleViewControllerFactory() let vc = factory.makeBicycleViewController()

फैक्ट्री इनकैप्सुलेटिंग क्लासेस

अब संक्षेप में उन मामलों पर जाएं जो किरीवस्की ने अपनी पुस्तक में प्रस्तुत किए हैं।

पहला मामला विशिष्ट वर्गों के एनकैप्सुलेशन से संबंधित है। उदाहरण के लिए, वाहनों के बारे में डेटा प्रदर्शित करने के लिए समान नियंत्रक लें:

 final class BicycleViewController: UIViewController { } final class ScooterViewController: UIViewController { }

मान लीजिए कि हम एक अलग मॉड्यूल के साथ काम कर रहे हैं, उदाहरण के लिए, एक प्लग-इन लाइब्रेरी। इस स्थिति में, ऊपर घोषित कक्षाएं internal (डिफ़ॉल्ट रूप से) रहती हैं, और कारखाने पुस्तकालय के सार्वजनिक "एपीआई" के रूप में internal करते हैं, जो अपने तरीकों में नियंत्रकों के आधार वर्गों को वापस करता है, इस प्रकार पुस्तकालय के अंदर विशिष्ट उपवर्गों के बारे में ज्ञान छोड़ देता है:

 public struct VehicleViewControllerFactory { func makeBicycleViewController() -> UIViewController { return BicycleViewController() } func makeScooterViewController() -> UIViewController { return ScooterViewController() } }

किसी फैक्ट्री के अंदर एक वस्तु बनाने के बारे में ज्ञान बढ़ाना

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

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

 enum Condition { case new case used } enum EngineType { case diesel case gas } struct Engine { let type: EngineType } enum TransmissionType { case automatic case manual } final class CarViewController: UIViewController { private let condition: Condition private let engine: Engine private let transmission: TransmissionType private let wheelDiameter: Int init(engine: Engine, transmission: TransmissionType, wheelDiameter: Int = 16, condition: Condition = .new) { self.engine = engine self.transmission = transmission self.wheelDiameter = wheelDiameter self.condition = condition super.init(nibName: nil, bundle: nil) } required init?(coder aDecoder: NSCoder) { fatalError("CarViewController: init(coder:) has not been implemented.") } }

संबंधित नियंत्रक के प्रारंभ का एक उदाहरण:

 let engineType = EngineType.diesel let engine = Engine(type: engineType) let transmission = TransmissionType.automatic let wheelDiameter = 18 let vc = CarViewController(engine: engine, transmission: transmission, wheelDiameter: wheelDiameter)

हम एक विशेष कारखाने के "कंधे" पर इन सभी "छोटी चीजों" की जिम्मेदारी डाल सकते हैं:

 struct UsedCarViewControllerFactory { let engineType: EngineType let transmissionType: TransmissionType let wheelDiameter: Int func makeCarViewController() -> UIViewController { let engine = Engine(type: engineType) return CarViewController(engine: engine, transmission: transmissionType, wheelDiameter: wheelDiameter, condition: .used) } }

और इस तरह से कंट्रोलर बनाएं:

 let factory = UsedCarViewControllerFactory(engineType: .gas, transmissionType: .manual, wheelDiameter: 17) let vc = factory.makeCarViewController()

फैक्टरी विधि

दूसरा "सिंगल-रूट" टेम्प्लेट भी विशिष्ट उत्पन्न प्रकारों के बारे में ज्ञान को घेरता है, लेकिन इस ज्ञान को एक विशेष वर्ग के भीतर छिपाकर नहीं, बल्कि बहुरूपता द्वारा। केरिव्स्की अपनी पुस्तक में जावा में उदाहरण देते हैं और अमूर्त कक्षाओं का उपयोग करने का सुझाव देते हैं , लेकिन स्विफ्ट ब्रह्मांड के निवासी इस अवधारणा से परिचित नहीं हैं। यहां हमारा अपना माहौल है ... और प्रोटोकॉल।

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

बहुरूपी वस्तु निर्माण

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

उदाहरण के लिए, वाहनों को प्रदर्शित करने के लिए अपने नियंत्रकों पर लौटते हैं:

 final class BicycleViewController: UIViewController { } final class ScooterViewController: UIViewController { }

और मान लीजिए कि उन्हें प्रदर्शित करने के लिए एक निश्चित इकाई का उपयोग किया जाता है, उदाहरण के लिए, एक समन्वयक , जो इन नियंत्रक को दूसरे नियंत्रक से सामान्य रूप से दर्शाता है:

 protocol Coordinator { var presentingViewController: UIViewController? { get set } func start() }

start() पद्धति का उपयोग हमेशा एक ही तरीके से किया जाता है, सिवाय इसके कि यह विभिन्न नियंत्रक बनाता है:

 final class BicycleCoordinator: Coordinator { weak var presentingViewController: UIViewController? func start() { let vc = BicycleViewController() presentingViewController?.present(vc, animated: true) } } final class ScooterCoordinator: Coordinator { weak var presentingViewController: UIViewController? func start() { let vc = ScooterViewController() presentingViewController?.present(vc, animated: true) } }

प्रस्तावित उपाय यह है कि उपयोग की गई वस्तु का निर्माण एक अलग विधि से किया जाए:

 protocol Coordinator { var presentingViewController: UIViewController? { get set } func start() func makeViewController() -> UIViewController }

और मूल विधि मूल कार्यान्वयन प्रदान करना है:

 extension Coordinator { func start() { let vc = makeViewController() presentingViewController?.present(vc, animated: true) } }

इस मामले में विशिष्ट प्रकार के रूप में ले जाएगा:

 final class BicycleCoordinator: Coordinator { weak var presentingViewController: UIViewController? func makeViewController() -> UIViewController { return BicycleViewController() } } final class ScooterCoordinator: Coordinator { weak var presentingViewController: UIViewController? func makeViewController() -> UIViewController { return ScooterViewController() } }

निष्कर्ष

मैंने तीन दृष्टिकोणों को मिलाकर इस सरल विषय को कवर करने की कोशिश की:

"गैंग्स ऑफ फोर" पुस्तक से प्रेरित रिसेप्शन के अस्तित्व की क्लासिक घोषणा;
उपयोग के लिए प्रेरणा, खुले तौर पर केरिवस्की की पुस्तक से प्रेरित;
मेरे पास एक प्रोग्रामिंग उद्योग के उदाहरण के रूप में आवेदन किया।

उसी समय, मैंने iOS सिस्टम के विकास के लिए आधुनिक दृष्टिकोण के सिद्धांतों को नष्ट किए बिना और स्विफ्ट भाषा की क्षमताओं का उपयोग करके (अधिक सामान्य C ++ और जावा के बजाय) का उपयोग किए बिना, जहां तक संभव हो, टेम्प्लेट की संरचना की पाठ्यपुस्तक संरचना के करीब होने की कोशिश की।

जैसा कि यह निकला, विषय लागू उदाहरणों पर विस्तृत सामग्री ढूंढना मुश्किल है। मौजूदा लेखों और पुस्तिकाओं में से अधिकांश में केवल सतही समीक्षा और संक्षिप्त उदाहरण हैं, जो पहले से ही कार्यान्वयन के पाठ्यपुस्तक संस्करणों की तुलना में काफी कम हैं।

मुझे उम्मीद है कि कम से कम आंशिक रूप से मैं अपने लक्ष्यों को प्राप्त करने में सक्षम था, और पाठक - कम से कम आंशिक रूप से इस विषय पर मेरे ज्ञान को जानने या ताज़ा करने के लिए कम से कम दिलचस्पी या उत्सुक था।

डिजाइन पैटर्न पर मेरी अन्य सामग्री:

और यह मेरे "ट्विटर" की एक कड़ी है, जहां मैं अपने निबंधों के लिंक प्रकाशित करता हूं और उससे थोड़ा अधिक।

स्विफ्ट और आईओएस यूनिवर्स में फैक्ट्री मेथड और एब्सट्रैक्ट फैक्ट्री