डेवलपर खुलासे

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



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



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



किसी वेब प्रोजेक्ट के ऑब्जेक्ट मॉडल का निर्माण करते समय मैं क्या उपयोग करने की सलाह नहीं देता: एकाधिक विरासत से बचें - यह शांत से दूर है और सभी लचीले नहीं है।

एकाधिक उत्तराधिकार के नुकसान:

• विभिन्न प्रकारों (वर्गों) के डेटा संरचनाओं के तत्वों (गुणों, विधियों) को पार करते समय सही परिणाम प्राप्त करने की कोई 100% गारंटी नहीं है, डेवलपर को हमेशा इन वर्गों को याद रखना पड़ता है;
• सामान्य रूप से वंशानुक्रम का दुरुपयोग करना (न केवल कई), हमें एक भारी वर्ग मिलता है जो अपने पूर्वजों के कई तरीकों और गुणों को जोड़ता है, कुछ तरीके और गुण जिनमें से शायद वंशज वर्ग में भी आवश्यक नहीं हैं; ऐसी कक्षाओं की वस्तुएँ बहुत ही बेमानी हो सकती हैं;
• वर्ग को बनाए रखने का लचीलापन खो जाता है, जब आपको पूर्वजों की कक्षाओं में से एक को बदलने की आवश्यकता होती है, तो आपको सभी या कुछ वंशजों को बदलने की आवश्यकता होती है;
• यदि कार्यक्षमता में समान वस्तुओं का एक सेट बनाना आवश्यक हो जाता है, लेकिन एक ही समय में सभी पूर्वजों की कक्षाओं के एक अलग सेट की आवश्यकता होती है, या ऐसी वस्तुओं के पूर्वज वर्गों के वंशानुक्रम का क्रम अलग होगा, तो इस मामले में प्रत्येक ऐसी वस्तु के लिए एक वर्ग बनाना आवश्यक होगा जो अलग होगा दूसरों से, केवल पूर्वजों या उनकी रचना की विरासत के अनुक्रम से।

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