कृपया नीचे दिए गए उदाहरण पर विचार करें:
एक वेब एप्लिकेशन हर लॉग इन यूजर के लिए एक यूजर ऑब्जेक्ट बनाता है। इस ऑब्जेक्ट में firstName
, lastName
... के लिए सरल String
गुण हैं ...
प्रत्येक उपयोगकर्ता का car
भी हो सकता है। गौर करें कि उपयोगकर्ता car
प्राप्त करना बहुत महंगा है, इसलिए हम उपयोगकर्ता लॉग इन करते समय उपयोगकर्ता कार को सेट नहीं करना पसंद करते हैं। इसके बजाय हम उपयोग की स्थिति में कार की आवश्यकता होने पर उसे प्राप्त करना चाहते हैं।
इसे लागू करने के लिए हमने एक यूजर पूजो बनाया है:
public class User() {
private String FirstName;
private String LastName;
private Car car;
//Here we have the service object, this could be injected with spring or JEE
private CarServices carServices;
public Car getCar() {
//If the car is not fetched yet, go on and get it from your service
if (car == null) {
car = carServices.getCarFromDB(...)
}
return car;
}
}
लॉगिन के बाद प्रारंभिक उपयोगकर्ता के लिए:
User newUser = new User();
newUser.setFirstName("foo");
newUser.setLastName("bar");
//We just let user have service, so he can use this service latter
newUser.setCarServices( new CarServices() );
और हर उपयोग के मामले में उपयोगकर्ता की कार की जरूरत है, इसे आसानी से प्राप्त कर सकते हैं:
newUser.getCar()
हालाँकि, मुझे तर्क दिया गया है कि इस तरह से मेरी उपयोगकर्ता वस्तु किसी भी तरह से एक साधारण पूजो नहीं है और यह एक अच्छा दृष्टिकोण नहीं है।
मैं इस आवश्यकता को बेहतर तरीके से कैसे प्राप्त कर सकता हूं।
2 जवाब
मुझे तर्क दिया गया है कि इस तरह से मेरी उपयोगकर्ता वस्तु एक साधारण पूजो नहीं है
आपके प्रश्न का उत्तर देने के लिए मैं सबसे पहले इतिहास में थोड़ा पीछे जाना चाहूंगा।
पूजो एक सादा पुराना जावा वस्तु है और इसका मतलब है कि आप केवल "मानक" जावा का उपयोग करते हैं। यह शब्द ऐसे समय में बनाया गया था जब J2EE का प्रचार हुआ था। इस समय डेवलपर्स ने एंटरप्राइज़ बीन्स में व्यावसायिक तर्क को कूटबद्ध किया और इस EJBs को बहुत सारे इन्फ्रास्ट्रक्चर कोड की आवश्यकता थी। इस तथ्य ने एक कार्यान्वयन प्रौद्योगिकी के लिए buisness तर्क को युग्मित किया। तो रेबेका पार्सन्स, जोश मैकेंजी और मार्टिन फाउलर इस निष्कर्ष पर पहुंचे कि यदि आप सिर्फ मानक जावा का उपयोग करते हैं तो व्यापार तर्क अधिक पुन: प्रयोज्य और परीक्षण में आसान होगा। इस प्रकार उन्होंने पूजो, क्योंकि डेवलपर्स को फैंसी नाम पसंद हैं।
आपका User
वर्ग सिर्फ मानक जावा पर निर्भर करता है और इसलिए यह एक पोजो है।
कुछ डेवलपर्स का तर्क है कि एक पूजो में कोई तर्क नहीं होना चाहिए। ये डेवलपर एनीमिक मॉडल पसंद करते हैं। दूसरों का कहना है कि एक समृद्ध मॉडल बेहतर दृष्टिकोण है। मैं उन डेवलपर्स से संबंधित हूं जो एनीमिक मॉडल से अधिक समृद्ध मॉडल पसंद करते हैं।
यदि आप CarServices
निर्भरता को User
वर्ग से हटाना चाहते हैं, तो आप हाइबरनेट या एक jpa कार्यान्वयन की तरह Car
आलसी लोडिंग प्रॉक्सी को लागू कर सकते हैं।
कम से कम यहाँ मेरे कुछ विचार सेम, पीओजोस, एनीमिक और रिच डोमेन मॉडल हैं।
जब आप अन्य डेवलपर्स के साथ चर्चा करते हैं तो उम्मीद है कि यह आपकी मदद करता है।
एक कार के संदर्भ के बजाय, आप एक कार आपूर्तिकर्ता वस्तु के संदर्भ का उपयोग कर सकते हैं जिसका कार्यान्वयन प्राप्त किए गए पहले परिणाम को कैश कर सकता है (गुवा के Supplier
} और MemoizingSupplier
कक्षाएं देखें)। ऐसा करने से, आप User
से इस तथ्य को छिपाते हैं कि इसकी कार तात्कालिक समय पर मौजूद नहीं हो सकती है या नहीं, और इसलिए इसके कार्यान्वयन को सरल बनाता है (गेट्टर विधि में कोई और तर्क नहीं)।
इस समाधान का एक और फायदा User
और CarServices
वर्गों (अब carServices
संपत्ति की कोई आवश्यकता नहीं) के बीच युग्मन को तोड़ने के लिए होगा। एक आपूर्तिकर्ता को इंजेक्ट कर सकता है जिसका कार्यान्वयन पहले से उपलब्ध Car
ऑब्जेक्ट के लिए एक संदर्भ लौटाएगा, जबकि दूसरा एक कार्यान्वयन को पारित कर सकता है जो कॉल को CarServices
सेवा के लिए अग्रेषित कर सकता है।
यह एक POJO के User
वर्ग को अधिक नहीं बनायेगा (जैसा कि ऊपर दिए गए पहले उत्तर में बताया गया है), लेकिन जो लोग आपके समाधान के बारे में तर्क देते हैं, वे इसे बेहतर और कम कसकर युग्मित होने के कारण इसे बेहतर पसंद कर सकते हैं।
संबंधित सवाल
नए सवाल
java
जावा एक उच्च स्तरीय प्रोग्रामिंग भाषा है। इस टैग का उपयोग तब करें जब आपको भाषा का उपयोग करने या समझने में समस्या हो। इस टैग का उपयोग शायद ही कभी किया जाता है और इसका उपयोग अक्सर [वसंत], [वसंत-बूट], [जकार्ता-ई], [Android], [javafx], [हडूप], [श्रेणी] और [मावेन] के साथ किया जाता है।