फैक्टरी विधि पैटर्न

इस बिंदु पर, आप शायद पहले से ही डिज़ाइन पैटर्न का सामना कर चुके हैं। उदाहरण के लिए, सिंगलटन ।

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

सॉफ्टवेयर विकास में, एक डिज़ाइन पैटर्न एक दोहराए जाने योग्य वास्तु निर्माण है जो कुछ आवर्ती संदर्भ में एक डिज़ाइन समस्या के समाधान का प्रतिनिधित्व करता है।

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

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

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

पैटर्न किस समस्या का समाधान करता है?

कल्पना कीजिए कि आप एक वितरण कार्यक्रम बनाने का निर्णय लेते हैं। प्रारंभ में, आप कारों के साथ कूरियर किराए पर लेंगे और एक का उपयोग करेंगेकारकार्यक्रम में एक वितरण वाहन का प्रतिनिधित्व करने के लिए आपत्ति। कोरियर बिंदु A से बिंदु B तक पैकेज वितरित करते हैं और इसी तरह। बहुत आसान।

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

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

परिणाम भयावह कोड है जो सशर्त बयानों से भरा है जो परिवहन के प्रकार के आधार पर विभिन्न क्रियाएं करते हैं।

समाधान

फ़ैक्टरी विधि पैटर्न सीधे नए ऑपरेटर का उपयोग करने के बजाय विशेष फ़ैक्टरी विधि को कॉल करके ऑब्जेक्ट बनाने का सुझाव देता है। फैक्ट्री पद्धति वाले वर्ग के उपवर्ग विशिष्ट वाहनों की बनाई गई वस्तुओं को संशोधित कर सकते हैं। पहली नज़र में, यह व्यर्थ लग सकता है: हमने प्रोग्राम में कंस्ट्रक्टर कॉल को एक स्थान से दूसरे स्थान पर स्थानांतरित कर दिया है। लेकिन अब आप बनाए जा रहे परिवहन के प्रकार को बदलने के लिए एक उपवर्ग में फ़ैक्टरी विधि को ओवरराइड कर सकते हैं।

आइए इस दृष्टिकोण के लिए वर्ग आरेख देखें:

इस प्रणाली के काम करने के लिए, सभी लौटी हुई वस्तुओं का एक सामान्य इंटरफ़ेस होना चाहिए। उपवर्ग इस इंटरफ़ेस को लागू करने वाले विभिन्न वर्गों की वस्तुओं का उत्पादन करने में सक्षम होंगे।

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

फ़ैक्टरी पद्धति के क्लाइंट के लिए, इन वस्तुओं के बीच कोई अंतर नहीं है, क्योंकि यह उन्हें किसी प्रकार के अमूर्त CourierTransport के रूप में मानेगा । क्लाइंट इस बात की गहराई से देखभाल करेगा कि वस्तु को वितरित करने का एक तरीका है, लेकिन वास्तव में वह तरीका कैसे काम करता है यह महत्वपूर्ण नहीं है।

जावा में कार्यान्वयन:

public interface CourierTransport {
	void deliver();
}
public class Car implements CourierTransport {
	@Override
	public void deliver() {
    		System.out.println("The package is being delivered by car");
	}
}
public class Truck implements CourierTransport {
	@Override
	public void deliver() {
    		System.out.println("The freight is being delivered by truck");
	}
}
public abstract class CourierTransportCreator {
	public abstract CourierTransport createTransport();
}
public class CarCreator extends CourierTransportCreator {
	@Override
	public CourierTransport createTransport() {
    		return new Car();
	}
}
public class TruckCreator extends CourierTransportCreator {
	@Override
	public CourierTransport createTransport() {
    		return new Truck();
	}
}
 
public class Delivery {
	private String address;
	private CourierTransport courierTransport;
 
	public void Delivery() {
	}
 
	public Delivery(String address, CourierTransport courierTransport) {
    	this.address = address;
    	this.courierTransport = courierTransport;
	}
 
	public CourierTransport getCourierTransport() {
    		return courierTransport;
	}
 
	public void setCourierTransport(CourierTransport courierTransport) {
    		this.courierTransport = courierTransport;
	}
 
	public String getAddress() {
    		return address;
	}
 
	public void setAddress(String address) {
    		this.address = address;
	}
}
public static void main(String[] args) {
    	// Accept a new type of order from the database (pseudocode)
    	String type = database.getTypeOfDeliver();
 
    	Delivery delivery = new Delivery();
    	
    	// Set the transport for delivery
        delivery.setCourierTransport(getCourierTransportByType(type));
    	
    	// Make the delivery
        delivery.getCourierTransport().deliver();
 
	}
 
	public static CourierTransport getCourierTransportByType(String type) {
    	switch (type) {
        	case "CarDelivery":
            	return new CarCreator().createTransport();
        	case "TruckDelivery":
            	return new TruckCreator().createTransport();
        	default:
            	throw new RuntimeException();
	    }
	}
    

यदि हम एक नया डिलीवरी ऑब्जेक्ट बनाना चाहते हैं, तो प्रोग्राम स्वचालित रूप से उपयुक्त ट्रांसपोर्ट ऑब्जेक्ट बनाता है।

हमें यह पैटर्न कब लागू करना चाहिए?

1. जब आप पहले से उन वस्तुओं के प्रकारों और निर्भरताओं को नहीं जानते हैं जिनके साथ आपके कोड को काम करने की आवश्यकता है।

फ़ैक्टरी विधि परिवहन का उपयोग करने वाले कोड से परिवहन के रूपों के निर्माण के लिए कोड को अलग करती है। नतीजतन, ऑब्जेक्ट बनाने के लिए कोड को बाकी कोड को छुए बिना बढ़ाया जा सकता है।

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

2. जब आप नए बनाने के बजाय मौजूदा वस्तुओं का पुन: उपयोग करके सिस्टम संसाधनों को बचाना चाहते हैं।

यह समस्या आमतौर पर संसाधन-गहन वस्तुओं, जैसे डेटाबेस कनेक्शन, फाइल सिस्टम इत्यादि के साथ काम करते समय होती है।

मौजूदा वस्तुओं का पुन: उपयोग करने के लिए आवश्यक कदमों के बारे में सोचें:

1. सबसे पहले, आपको अपने द्वारा बनाई गई सभी वस्तुओं को संग्रहीत करने के लिए एक साझा रिपॉजिटरी बनाने की आवश्यकता है।

2. किसी नई वस्तु का अनुरोध करते समय, आपको रिपॉजिटरी में देखना होगा और यह जांचना होगा कि इसमें उपलब्ध वस्तु है या नहीं।

3. ऑब्जेक्ट को क्लाइंट कोड पर वापस करें।

4. लेकिन अगर कोई वस्तु उपलब्ध नहीं है, तो एक नया बनाएं और इसे रिपॉजिटरी में जोड़ें।

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

इसका मतलब है कि एक और विधि की आवश्यकता है जो मौजूदा और नई दोनों वस्तुओं को वापस कर सके। यह फैक्ट्री तरीका होगा।

3. जब आप उपयोगकर्ताओं को अपने ढांचे या पुस्तकालय के कुछ हिस्सों को विस्तारित करने की अनुमति देना चाहते हैं।

उपयोगकर्ता इनहेरिटेंस के माध्यम से आपकी रूपरेखा कक्षाओं का विस्तार कर सकते हैं। लेकिन आप मानक के बजाय इन नए वर्गों की वस्तुओं को कैसे बनाते हैं?

समाधान यह है कि उपयोगकर्ताओं को न केवल घटकों का विस्तार करने दिया जाए, बल्कि उन घटकों को बनाने वाली कक्षाओं को भी। और इसके लिए, बनाने वाली कक्षाओं में विशिष्ट निर्माण विधियां होनी चाहिए जिन्हें परिभाषित किया जा सके।

लाभ

• विशिष्ट परिवहन वर्गों से एक वर्ग को अलग करता है।
• परिवहन के प्रकार बनाने के लिए कोड को एक ही स्थान पर रखता है, जिससे कोड को बनाए रखना आसान हो जाता है।
• कार्यक्रम में परिवहन के नए साधनों को जोड़ना सरल करता है।
• खुले-बंद सिद्धांत को लागू करता है।

नुकसान

बड़े समानांतर वर्ग पदानुक्रम को जन्म दे सकता है, क्योंकि प्रत्येक उत्पाद वर्ग का अपना निर्माता उपवर्ग होना चाहिए।

आइए संक्षेप करते हैं

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

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