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

मैं यूनिक्स के लिए " एरिक रेमंड के अनुसार" के लिए कुछ सरल विकास नियमों के लिए समर्पित लेखों की श्रृंखला जारी रखता हूं, जो कि, मेरी सबसे गहरी सजा में, किसी भी अन्य ऑपरेटिंग सिस्टम के लिए विस्तारित की जा सकती है। मैंने पहले से ही पहले तीन हिस्सों में मॉड्यूलरिटी , स्पष्टता और रचना के नियमों के बारे में बात की। आज यह चौथे नियम पर आता है -



पृथक्करण नियम: तंत्र से नियमों को अलग करते हैं, और इंजन से इंटरफेस ( "व्यापार तर्क" ) (पृथक्करण का नियम: तंत्र से अलग नीति; इंजन से अलग इंटरफेस)



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



इस विषय के संबंध में, हमें मॉडल-व्यू-कंट्रोलर या, संक्षेप में, एमवीसी की अवधारणा को याद करना चाहिए। यह डेटा (मॉडल), प्रतिनिधित्व (दृश्य) और व्यावसायिक तर्क (नियंत्रक) को अलग करने के लिए माना जाता है। सीधे शब्दों में कहें, सभी तर्क, सभी इंटरफेस और सभी डेटा को अलग-अलग घटकों द्वारा एक दूसरे से अलग किया जाना चाहिए और मानक इंटरफेस द्वारा जुड़ा होना चाहिए। यह डिज़ाइन पैटर्न लगभग सभी आधुनिक प्रोग्रामिंग भाषाओं के लिए लागू किया गया है। लोकप्रिय "क्लासिक्स" से हम Apache Struts (JAVA), सिम्फनी ( PHP ), ASP.NET MVC को याद कर सकते हैं। इस उद्देश्य के लिए अच्छी तरह से प्रलेखित, व्यापक रूप से उपयोग की जाने वाली रूपरेखाओं का उपयोग उन्हें स्वयं खरोंच से लिखने की तुलना में अधिक बेहतर है, क्योंकि आपको समस्या को हल करने के लिए कोई विवरण नहीं देना है, और सबसे अधिक संभावना है कि यह साइकिल के आविष्कार और समय के एक अति प्रयोग से ज्यादा कुछ नहीं होगा। और संसाधन।



इंटरफ़ेस और लॉजिक के पृथक्करण का एक बहुत ही दिलचस्प उदाहरण यूनिक्स के लिए शतरंज का कार्यान्वयन है, जिसे जीएनयू लाइसेंस के तहत वितरित किया गया है। टेक्स्ट इंटरफ़ेस के साथ एक अलग शतरंज इंजन है। इसके अंदर, इंटरफ़ेस को "तर्क" से भी अलग किया जाता है, लेकिन - महत्वपूर्ण रूप से - यह जानबूझकर उद्देश्य पर "बोझ" नहीं था। आंकड़ों के साथ ब्लैकबोर्ड अलग अनुप्रयोग है, जैसे XChess, Pychess, Winboard।



इस अवधारणा का उपयोग करने का एक उत्कृष्ट उदाहरण एक्स विंडो सिस्टम का कार्यान्वयन है, एक खिड़की प्रणाली जिसमें अपना स्वयं का ग्राफिकल वातावरण नहीं है। "विंडोज़" और "आइकन" का प्रतिपादन तीसरे पक्ष के खिड़की प्रबंधकों द्वारा किया जाता है, जो बदले में, "गणित" से रहित होते हैं और I / O उपकरणों का समर्थन करने से गुरेज नहीं करते हैं।



इस सिद्धांत का एक हिस्सा तंत्र से नियमों का अलग होना है। यह लचीला, अनुकूलन योग्य डेटा-आधारित तर्क के निर्माण के बारे में है। यहां, दुर्भाग्य से या सौभाग्य से, लचीलेपन और पर्याप्तता के बीच रेखा खींचने के लिए कोई सार्वभौमिक सलाह नहीं है। उदाहरण के लिए, आप iPhone के लिए एप्लिकेशन डिज़ाइन करते समय विभिन्न स्क्रीन रिज़ॉल्यूशन पर भरोसा कर सकते हैं, और यह निश्चित रूप से मदद करेगा यदि प्रश्न iPad पर पोर्ट करने के लिए उठता है। इसके लिए निश्चित रूप से अतिरिक्त प्रयास और समय की आवश्यकता होगी। इसलिए, उत्पाद प्रबंधक या उसकी जगह लेने वाले व्यक्ति को यहां शामिल होना चाहिए, और प्रोग्रामर का काम सही और समय पर इन मुद्दों को स्पष्ट और समझने योग्य रूप में उठाना है।



इस सिद्धांत का अवलोकन करते समय कठिन परिस्थितियों में से एक सर्वर तर्क के साथ एक साथ जावास्क्रिप्ट का उपयोग है। AJAX का सक्रिय रूप से उपयोग करने वाले सिस्टम का निर्माण करते समय, आपको डिज़ाइन चरण में इसे सावधानीपूर्वक मॉनिटर करने की आवश्यकता होती है। एक बहुत ही सामान्य गलती Javascripts के साथ साइट टेम्पलेट्स की अत्यधिक जटिलता है, जिसके परिणामस्वरूप वे एक जटिल प्रणाली में बदल जाते हैं। इसलिए, हर बार जब आप जावास्क्रिप्ट का सक्रिय रूप से उपयोग करने की योजना बनाते हैं, तो विकास टीम में एक समन्वित दृष्टिकोण लें, जैसा कि इस मामले में, अलग-अलग व्यावसायिक तर्क और इंटरफेस हैं।

“ इससे पहले कि रचना नियम

निरंतरता: सादगी का नियम "