या टप्प्यावर, तुम्हाला कदाचित आधीच डिझाइन पॅटर्नचा सामना करावा लागला असेल. उदाहरणार्थ, सिंगलटन .
कोणते नमुने आहेत, ते का आवश्यक आहेत आणि कोणते सृजनात्मक नमुने आहेत ते आठवूया (सिंगलटन एक उदाहरण आहे). आम्ही नवीन नमुना देखील अभ्यासू: कारखाना पद्धत.
सॉफ्टवेअर डेव्हलपमेंटमध्ये, डिझाईन पॅटर्न ही पुनरावृत्ती करण्यायोग्य आर्किटेक्चरल रचना आहे जी काही आवर्ती संदर्भात डिझाइन समस्येचे निराकरण करते.
सामान्यतः, नमुना हा अंतिम उपाय नाही जो थेट कोडमध्ये रूपांतरित केला जाऊ शकतो. विविध परिस्थितींमध्ये वापरल्या जाऊ शकणार्या समस्येचे हे फक्त एक मॉडेल सोल्यूशन आहे.
क्रिएशनल पॅटर्न हे डिझाइन पॅटर्न आहेत जे ऑब्जेक्ट्स तयार करण्याच्या प्रक्रियेशी संबंधित असतात. ते एक प्रणाली तयार करणे शक्य करतात जी वस्तू तयार करण्यासाठी, तयार करण्यासाठी आणि सादर करण्यासाठी वापरल्या जाणार्या पद्धतीपासून स्वतंत्र असेल.
फॅक्टरी पद्धत ही एक सृजनात्मक डिझाइन पॅटर्न आहे जी पॅरेंट क्लासमध्ये ऑब्जेक्ट्स तयार करण्यासाठी एक सामान्य इंटरफेस परिभाषित करते, त्याच्या वंशजांना या ऑब्जेक्ट्स तयार करण्याची क्षमता देते. निर्मितीच्या वेळी, कोणता वर्ग तयार करायचा हे वंशज ठरवू शकतात.
नमुना कोणती समस्या सोडवते?
कल्पना करा की तुम्ही डिलिव्हरी प्रोग्राम तयार करण्याचा निर्णय घेतला आहे. सुरुवातीला, तुम्ही कारसह कुरिअर भाड्याने घ्याल आणि एगाडीकार्यक्रमात वितरण वाहनाचे प्रतिनिधित्व करण्यासाठी ऑब्जेक्ट. कुरिअर बिंदू A पासून बिंदू B पर्यंत पॅकेज वितरीत करतात आणि असेच. सोपे peasy.
कार्यक्रम लोकप्रिय होत आहे. तुमचा व्यवसाय वाढत आहे आणि तुम्हाला नवीन बाजारपेठांमध्ये विस्तार करायचा आहे. उदाहरणार्थ, तुम्ही अन्न वितरण आणि मालवाहतूक देखील सुरू करू शकता. या प्रकरणात, कुरिअरद्वारे पायी, स्कूटर आणि सायकलवर अन्न वितरित केले जाऊ शकते, परंतु मालवाहतुकीसाठी ट्रकची आवश्यकता आहे.
आता तुम्हाला अनेक गोष्टींचा मागोवा ठेवणे आवश्यक आहे (केव्हा, कोणाला, काय आणि किती वितरित केले जाईल), यासह प्रत्येक कुरिअर किती वाहून नेऊ शकतो. वाहतुकीच्या नवीन पद्धतींमध्ये वेग आणि क्षमता भिन्न आहेत. मग तुमच्या लक्षात येईल की तुमच्या प्रोग्राममधील बहुतेक संस्थांशी जोरदारपणे जोडलेले आहेतगाडीवर्ग तुमच्या लक्षात आले आहे की तुमचा प्रोग्राम इतर वितरण पद्धतींसह कार्य करण्यासाठी, तुम्हाला विद्यमान कोड बेस पुन्हा लिहावा लागेल आणि प्रत्येक वेळी तुम्ही नवीन वाहन जोडता तेव्हा ते पुन्हा करावे लागेल.
परिणाम म्हणजे सशर्त विधानांनी भरलेला भयानक कोड जो वाहतुकीच्या प्रकारावर अवलंबून भिन्न क्रिया करतो.
उपाय
फॅक्टरी मेथड पॅटर्न थेट नवीन ऑपरेटर वापरण्याऐवजी विशेष फॅक्टरी मेथड कॉल करून ऑब्जेक्ट्स तयार करण्यास सुचवते . फॅक्टरी पद्धत असलेल्या वर्गाचे उपवर्ग विशिष्ट वाहनांच्या तयार केलेल्या वस्तूंमध्ये बदल करू शकतात. पहिल्या दृष्टीक्षेपात, हे निरर्थक वाटू शकते: आम्ही प्रोग्राममधील कन्स्ट्रक्टर कॉल एका ठिकाणाहून दुसऱ्या ठिकाणी हलवला आहे. परंतु आता तुम्ही तयार होत असलेल्या वाहतुकीचा प्रकार बदलण्यासाठी उपवर्गात फॅक्टरी पद्धत ओव्हरराइड करू शकता.
या दृष्टिकोनासाठी वर्ग आकृती पाहू:
ही प्रणाली कार्य करण्यासाठी, सर्व परत केलेल्या वस्तूंचा एक सामान्य इंटरफेस असणे आवश्यक आहे. उपवर्ग या इंटरफेसची अंमलबजावणी करणार्या विविध वर्गांच्या वस्तू तयार करण्यास सक्षम असतील.
उदाहरणार्थ, ट्रक आणि कार वर्ग कुरिअर ट्रान्सपोर्ट इंटरफेस डिलिव्हरी पद्धतीसह लागू करतात. यातील प्रत्येक वर्ग ही पद्धत वेगळ्या पद्धतीने लागू करतो: ट्रक मालवाहतूक करतात, तर कार अन्न, पॅकेजेस इत्यादी वितरीत करतात. TruckCreator क्लासमधील फॅक्टरी पद्धत ट्रक ऑब्जेक्ट परत करते आणि CarCreator क्लास कार ऑब्जेक्ट परत करते.
फॅक्टरी पद्धतीच्या क्लायंटसाठी, या ऑब्जेक्ट्समध्ये कोणताही फरक नाही, कारण ते त्यांना काही प्रकारचे अमूर्त कुरियर ट्रान्सपोर्ट मानतील . क्लायंट लक्षपूर्वक काळजी घेईल की ऑब्जेक्टला वितरित करण्याची पद्धत आहे, परंतु ती पद्धत नेमकी कशी कार्य करते हे महत्त्वाचे नाही.
Java मध्ये अंमलबजावणी:
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. जेव्हा आपण नवीन तयार करण्याऐवजी विद्यमान ऑब्जेक्ट्सचा पुनर्वापर करून सिस्टम संसाधने जतन करू इच्छिता.
ही समस्या सामान्यतः संसाधन-केंद्रित वस्तूंसह कार्य करताना उद्भवते, जसे की डेटाबेस कनेक्शन, फाइल सिस्टम इ.
अस्तित्वात असलेल्या वस्तूंचा पुनर्वापर करण्यासाठी तुम्हाला कोणत्या चरणांची आवश्यकता आहे याचा विचार करा:
-
प्रथम, आपण तयार केलेल्या सर्व वस्तू संचयित करण्यासाठी सामायिक भांडार तयार करणे आवश्यक आहे.
-
नवीन ऑब्जेक्टची विनंती करताना, आपल्याला रेपॉजिटरीमध्ये पहावे लागेल आणि त्यात उपलब्ध ऑब्जेक्ट आहे का ते तपासावे लागेल.
-
क्लायंट कोडवर ऑब्जेक्ट परत करा.
-
परंतु उपलब्ध वस्तू नसल्यास, एक नवीन तयार करा आणि रिपॉजिटरीमध्ये जोडा.
हा सर्व कोड कुठेतरी ठेवला जाणे आवश्यक आहे जे क्लायंट कोडमध्ये गोंधळ होणार नाही. सर्वात सोयीस्कर जागा कन्स्ट्रक्टर असेल, कारण ऑब्जेक्ट्स तयार करताना आम्हाला फक्त या सर्व तपासण्या आवश्यक आहेत. अरेरे, कन्स्ट्रक्टर नेहमी नवीन ऑब्जेक्ट तयार करतो - तो विद्यमान ऑब्जेक्ट परत करू शकत नाही.
याचा अर्थ असा की दुसरी पद्धत आवश्यक आहे जी विद्यमान आणि नवीन दोन्ही वस्तू परत करू शकते. ही फॅक्टरी पद्धत असेल.
3. जेव्हा तुम्ही वापरकर्त्यांना तुमच्या फ्रेमवर्क किंवा लायब्ररीचे काही भाग वाढवण्याची परवानगी देऊ इच्छित असाल.
वापरकर्ते वारसाद्वारे तुमचे फ्रेमवर्क वर्ग वाढवू शकतात. पण तुम्ही या नवीन वर्गांच्या वस्तू मानकांच्या ऐवजी फ्रेमवर्क कसे तयार कराल?
उपाय म्हणजे वापरकर्त्यांना केवळ घटकच नव्हे तर ते घटक तयार करणारे वर्ग देखील विस्तारित करू देणे. आणि यासाठी, निर्माण वर्गांमध्ये विशिष्ट निर्मिती पद्धती असणे आवश्यक आहे ज्या परिभाषित केल्या जाऊ शकतात.
फायदे
- विशिष्ट वाहतूक वर्गांमधून वर्ग डीकपल करतो.
- वाहतुकीचे प्रकार तयार करण्यासाठी कोड एकाच ठिकाणी ठेवते, कोड राखणे सोपे करते.
- प्रोग्राममध्ये वाहतुकीच्या नवीन पद्धती जोडणे सोपे करते.
- खुल्या-बंद तत्त्वाची अंमलबजावणी करते.
तोटे
मोठ्या समांतर वर्ग पदानुक्रमांना कारणीभूत ठरू शकते, कारण प्रत्येक उत्पादन वर्गाचा स्वतःचा निर्माता उपवर्ग असणे आवश्यक आहे.
चला सारांश द्या
तुम्ही फॅक्टरी पद्धतीच्या पद्धतीबद्दल शिकलात आणि एक संभाव्य अंमलबजावणी पाहिली. हा पॅटर्न बर्याचदा विविध लायब्ररींमध्ये वापरला जातो जे इतर ऑब्जेक्ट्स तयार करण्यासाठी वस्तू प्रदान करतात.
तुमच्या मुख्य व्यवसाय तर्काशी संवाद साधण्यासाठी आणि भिन्न संदर्भांमुळे तुमचा कोड फुगवू नये म्हणून तुम्हाला विद्यमान वर्गांच्या उपवर्गांच्या नवीन वस्तू सहज जोडायच्या असतील तेव्हा फॅक्टरी पद्धतीचा नमुना वापरा.
GO TO FULL VERSION