मैं स्विंग का उपयोग करके जावा में एक स्कूल समूह परियोजना शुरू कर रहा हूं। यह डेटाबेस डेस्कटॉप ऐप पर एक सीधा GUI है।
प्रोफेसर ने हमें पिछले साल के प्रोजेक्ट से कोड दिया ताकि हम देख सकें कि वह कैसे काम करता है। मेरी शुरुआती धारणा यह है कि यह कोड जितना जटिल है, उससे कहीं अधिक जटिल है, लेकिन मुझे लगता है कि प्रोग्रामर अक्सर सोचते हैं कि कोड को देखते समय वे सिर्फ लिखते नहीं थे।
मैं उन कारणों को खोजने की उम्मीद कर रहा हूं जिनकी प्रणाली अच्छी या बुरी है। (मैंने प्रोफेसर से पूछा और उन्होंने कहा कि मैं बाद में देखूंगा कि यह बेहतर क्यों है, जो मुझे संतुष्ट नहीं करता है।)
मूल रूप से, उसकी लगातार वस्तुओं, मॉडल (व्यापार तर्क) और विचारों के बीच किसी भी युग्मन से बचने के लिए, सब कुछ तार के साथ किया जाता है। डेटाबेस में संग्रहित होने वाली स्थायी वस्तुएं स्ट्रिंग के हैशटेबल्स हैं, और मॉडल और दृश्य एक-दूसरे को "सब्सक्राइब" करते हैं, जिससे वे "ईवेंट" की सदस्यता लेते हैं।
जब कोई घटना शुरू होती है, तो दृश्य या मॉडल अपने सभी ग्राहकों को एक स्ट्रिंग भेजता है जो यह तय करते हैं कि उस घटना के लिए क्या करना है। उदाहरण के लिए, व्यू एक्शन श्रोता के तरीकों में से एक में (मेरा मानना है कि यह सिर्फ साइकिल सेट करता है। लगातार चलने वाली वस्तु पर):
else if(evt.getSource() == bicycleMakeField)
{
myRegistry.updateSubscribers("BicycleMake", bicycleMakeField.getText());
}
वह कॉल अंततः वाहन मॉडल में इस विधि के लिए हो जाती है:
public void stateChangeRequest(String key, Object value) {
... bunch of else ifs ...
else
if (key.equals("BicycleMake") == true)
{
... do stuff ...
प्रोफेसर का कहना है कि सामान रखने का यह तरीका अधिक व्यापक और बनाए रखने वाला है, क्योंकि देखने का तरीका केवल एक व्यापार तर्क वस्तु पर एक विधि कहता है। वह कहते हैं कि विचारों और मॉडलों के बीच कोई युग्मन नहीं है क्योंकि वे एक दूसरे के अस्तित्व के बारे में नहीं जानते हैं।
मुझे लगता है कि यह एक बदतर प्रकार का युग्मन है, क्योंकि दृश्य और मॉडल को काम करने के लिए समान तारों का उपयोग करना पड़ता है। यदि आप कोई दृश्य या मॉडल निकालते हैं, या एक स्ट्रिंग में टाइपो बनाते हैं, तो आपको कोई संकलन त्रुटियां नहीं मिलती हैं। यह भी कोड एक पूरी बहुत लंबे समय से मुझे लगता है कि यह होने की जरूरत है बनाता है।
मैं उसके साथ इस पर चर्चा करना चाहता हूं, लेकिन वह अपने उद्योग के अनुभव का उपयोग किसी भी तर्क का मुकाबला करने के लिए करता है जिसे मैं अनुभवहीन छात्र बना सकता हूं। क्या उसके दृष्टिकोण का कुछ लाभ है जो मुझे याद आ रहा है?
स्पष्ट करने के लिए, मैं उपर्युक्त दृष्टिकोण की तुलना करना चाहता हूं, क्योंकि दृश्य स्पष्ट रूप से मॉडल के साथ जुड़ा हुआ है। उदाहरण के लिए, आप वाहन मॉडल ऑब्जेक्ट को देखने के लिए पास कर सकते हैं, और फिर वाहन के "मेक" को बदलने के लिए, यह करें:
vehicle.make = bicycleMakeField.getText();यह कोड की 15 पंक्तियों को कम कर देगा जो वर्तमान में केवल एक जगह पर वाहन को बनाने के लिए उपयोग किया जाता है, कोड की एक एकल पठनीय लाइन के लिए। (और चूंकि इस तरह का ऑपरेशन पूरे ऐप में सैकड़ों बार किया जाता है, मुझे लगता है कि यह पठनीयता के साथ-साथ सुरक्षा के लिए भी एक बड़ी जीत होगी।)
अपडेट करें
मेरी टीम के नेता और मैंने उस ढांचे को पुनर्गठित किया जिस तरह से हम इसे स्थिर टाइपिंग का उपयोग करके करना चाहते थे, प्रोफेसर को सूचित किया, और उसे एक डेमो देकर समाप्त किया। वह काफी उदार है कि जब तक हम उससे मदद नहीं मांगते, तब तक हम अपने ढांचे का उपयोग करते हैं, और अगर हम अपनी बाकी टीम को गति देने के लिए रख सकते हैं - जो हमें उचित लगता है।