यूनिक्स के तहत प्रोग्रामिंग की कला (और न केवल)। भाग तीन, "रचना नियम"

मैं एरिक रेमंड द्वारा यूनिक्स प्रोग्रामिंग की कला पर लेखों की श्रृंखला जारी रखता हूं। इससे पहले, मैंने पहले दो नियमों का उल्लेख किया है - प्रतिरूपकता और स्पष्टता ।

आज हम तीसरे नियम के बारे में बात करेंगे -



रचना नियम: प्रोग्राम बनाएं ताकि उन्हें दूसरों के साथ जोड़ा जा सके।



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



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



यह दृष्टिकोण विकसित करने के लिए अधिक जटिल और महंगा है, लेकिन लचीलापन और मापनीयता इन कमियों में से कई को संतुलित करती है। बहुत प्रारंभिक चरण में एक प्रलेखित एपीआई बनाना आपके आवेदन के लिए दुनिया के लिए द्वार खोलता है: इसके डेवलपर्स अन्य कार्यक्रमों के साथ एकीकृत कर सकते हैं, और आपका नहीं, यही वजह है कि हर कोई अंत में जीतता है।



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



ऐसी स्थितियों में, उनमें से उनके "कुलीबिन्स" हैं, जो समस्याएं ला सकते हैं। उदाहरण के लिए, आप Gdrive को याद कर सकते हैं - एक आभासी इंटरनेट डिस्क जिसमें GMail ईमेल सेवा के आधार पर भंडारण का आयोजन किया जाता है । जाहिर है, मेल सेवा का इस तरह का उपयोग उसके लिए हानिकारक है। या एक और बात - जीमेल में IMAP इंटरफ़ेस मुझे स्थानीय मेलबॉक्सेज़ को Google मेलबॉक्सों में आरक्षित करने में मदद करता था, उसी समय स्वचालित रूप से उन्हें अनुक्रमणित किया जाता था। मैंने यह आउटलुक का उपयोग करके किया, बस मेल को खाते से कॉपी करना, और फिर अग्रेषण स्थापित करना। अब बड़े पैमाने पर अपलोड के साथ "छेद" को बंद कर दिया गया है।



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



बड़ी गलती "केवल" आधार पर एक एपीआई विकसित करना है। प्रलेखन के बिना, आवेदन में एकरूपता के बिना, एक एकल तर्क के बिना, इसके उपयोग के लिए विभिन्न विकल्पों के संयोजन के बिना, समग्र वास्तुकला के बिना, सेवा का लाभ बहुत सशर्त होगा। नकारात्मक उदाहरणों में omgash CORBA और Microsoft COM शामिल हैं, जो विषम प्रणालियों को जोड़ने के लिए खराब विकसित प्रौद्योगिकियां हैं। एक दर्जन प्रथम श्रेणी की कंपनियां कॉर्बा विनिर्देश को विकसित करने में शामिल थीं, लेकिन यह पता चला कि क्या हुआ: मेरी राय में, अपने स्वयं के स्वतंत्र एक भी प्रोग्रामर नहीं आज इस अवधारणा का चयन करेंगे। और COM के पास एमएस विंडोज वातावरण में संचार कार्यक्रमों के लिए एक संकीर्ण आवेदन है, हालांकि किसी ने शुरुआत से ही इसे और अधिक सार्वभौमिक विकसित करने की जहमत नहीं उठाई।



यूनिक्स दुनिया में, कंसोल कार्यक्रमों की बातचीत के लिए पाइप तकनीक है, जिसके बारे में मैंने पहले ही लिखा था। एक प्रोग्राम का आउटपुट दूसरे के इनपुट को निर्देशित किया जाता है, और इस तरह के बंडलों के "वास्तुकार" के विवेक से उन्हें एक दूसरे के साथ सही ढंग से डॉक करना है। यह एक डिजाइनर की तरह कुछ बाहर निकलता है, जिसमें से इकट्ठा करने के लिए एक विशेषज्ञ के हाथों पर कुछ उपयोगी होता है, यहां तक ​​कि यह समझने के बिना कि "ईंटों" में से प्रत्येक कैसे काम करता है। पाइप की अवधारणा बल्कि आदिम है, लेकिन एक संकीर्ण विषय क्षेत्र में कार्यों की एक विस्तृत श्रृंखला के लिए आदर्श है। जब वे इसे हर चीज में स्थानांतरित करने की कोशिश करते हैं, तो समस्याएं पैदा होती हैं क्योंकि गलत "टूल" चुना गया है। उदाहरण के लिए, Microsoft ने पाइपों के अपने कार्यान्वयन में शक्तियों को जोड़कर वस्तुनिष्ठता को जोड़ा, जो संभावित रूप से उन्हें सुपर लचीला बना देना चाहिए था। लेकिन सरल निर्णय, जैसा कि वे कहते हैं, "नियम।" और अब यह अधिकार कहाँ है ...



अंत में, मैं शुरुआत में लौटना चाहता हूं: खुले इंटरफेस वाले कार्यक्रम बनाएं, उनके विकास की शुरुआत से ही इसके बारे में सोचें। एक ऐसा प्रोग्राम बनाना जो अपने ही स्वरूपों में काम करता है और यह नहीं जानता कि अपनी तरह का संवाद कैसे किया जाए, यह पिछली सदी है।

“ इससे पहले स्पष्टता का नियम

जारी: जुदाई का नियम "