एक सी ++ एप्लिकेशन के लिए जावा जीयूआई - क्या यह एक अच्छा डिजाइन है?

Question

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

एफवाईआई, उत्पाद डेटा-बैकअप आधारित एप्लिकेशन (संभवतः लिनक्स/यूनिक्स प्लेटफॉर्म पर) है। धन्यवाद।

सीवी

Answer 1

यह अगर इस आवेदन की आवश्यकताओं के बारे में अधिक जानकारी के बिना एक अच्छा डिजाइन है बताने के लिए कठिन है।

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

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

Answer 2

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

मैसेजिंग ऐसा करने का एक आम तरीका है। मैं "मैसेजिंग" की छतरी के नीचे HTTP पर विचार करता हूं, और लगभग हर भाषा में एक HTTP लाइब्रेरी है - जो इसे एक सामान्य संदेश "भाषा" के रूप में अच्छी पसंद बनाती है। एक बहुत ही विषम प्रणाली को एकीकृत करते समय न केवल घटकों को एकीकृत करने के लिए समर्पित उपकरण/ढांचे होते हैं, बल्कि मैसेजिंग सिस्टम को एकीकृत करने के लिए भी (उदाहरण के लिए ESBs)।

Answer 3

इस बात की बाधाएं हो सकती हैं कि उन्हें सी ++ कार्यों को पहली जगह क्यों कॉल करना है और फिर शीर्ष पर वे ग्राहक आवश्यकताओं को वितरित कर सकते थे। आप समाधान कैसे विकसित करेंगे, इसलिए आप एक संदेश प्रणाली बनाते हैं और सर्वर पक्ष पर C++ के साथ इंटरफेस करते हैं। यह दिन के अंत में एक कामकाजी समाधान है। मैं उम्मीद नहीं करता कि यूई को सी ++ में बनाया जाना चाहिए क्योंकि सर्वर की तरफ सी ++ में लिखा गया है, कभी-कभी आपको अपने समाधान को प्राप्त करने के लिए अलग-अलग तकनीकों को इकट्ठा करने की आवश्यकता होती है।

Answer 4

यह एक व्यावहारिक/ठीक दृष्टिकोण है, मैंने देखा कि यह एक बहुत बड़ी (फॉर्च्यून 20 अगर ऐसी चीज है) कंपनी का इस्तेमाल होता है जब मैंने ठेकेदार 2005-2006 के रूप में वहां काम किया था।

जब मैंने पूछा क्यों, मुझे बताया गया था:

1. आवश्यकता लिनक्स जीयूआई, जावा/स्विंग एक सम्मानजनक स्थान है। मुझे यह भी लगता है कि उनके पास कुछ जावा डेवलपर्स थे जिन्हें काम की ज़रूरत थी।
2. उनके पास सी ++/सी में बड़े, प्रदर्शन महत्वपूर्ण कोड बेस थे।
3. वे पहले से ही मैसेजिंग का व्यापक रूप से उपयोग करते थे और इसके लिए पुस्तकालय थे।
4. मैसेजिंग इंटरफ़ेस, जबकि विकसित होने के लिए महंगा है, टीम परीक्षण परीक्षा कार्यक्रम लिखती है (जैसे उत्पादन जीयूआई को एक पायथन स्क्रिप्ट के साथ प्रतिस्थापित करें)।

सभी ने कहा, क्यूटी और जीटीके/जीटीकेएम बहुत अच्छे जीयूआई ढांचे हैं, उन का उपयोग क्यों नहीं करें?