पैटर्न न सीखें, कॉन्सेप्ट सीखें

शुभ दोपहर (या शाम या सुबह, जब यह पोस्ट बाहर आता है) पर निर्भर करता है।

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

इतना

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

ये, निश्चित रूप से, सच्चे प्रश्न जल्दी या बाद में उसे अस्पष्ट नाम "एब्सट्रैक्ट फैक्ट्री", "सिंगलटन", "मध्यस्थ" और समान रूप से समझने योग्य संक्षिप्तीकरण SOLID, GRASP की ओर ले जाएंगे।

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

ओओपी कहता है: "यार, मुझे कार्यक्रमों को पेश करने का एक स्पष्ट और समझने योग्य तरीका मिला।"
एमवीसी कहता है: "यार, यह बेहतर होगा यदि आप कोड को विभाजित करते हैं, और अलग-अलग नियम कट के अधीन हैं।"
ओआरएम कहता है: "पीएस, यार, मैंने सिर्फ दो अलग-अलग विचारधाराओं - ओओपी और डीबी को मिलाने का एक तरीका खोजा।"
यहाँ सब कुछ स्पष्ट है।

मैं उन चीजों के बारे में बात कर रहा हूं जिनमें अधिकतम स्तर का अमूर्तता शामिल है। एक उदाहरण:
"मध्यस्थ":

लोग, यदि आपके पास बहुत सी अलग-अलग वस्तुएं हैं, तो एक केंद्रीय बनाएं, बाकी सभी चीजों को इससे जोड़ दें।

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

वही अन्य पैटर्न के लिए जाता है:
"फैक्टरी":

क्या आप जानते हैं कि आप किसी अन्य वर्ग का उपयोग करके वस्तुओं का निर्माण कर सकते हैं?

"डेटा मैपर":

आप डेटा को बचाने के लिए अमूर्तता की एक अतिरिक्त परत का उपयोग क्यों नहीं करते?

"ऑब्जर्वर":

आदमी, लेकिन चलो कुछ इंटरफेस मिलता है?

"रणनीति":

क्या आप जानते हैं कि बहुरूपता क्या है?

और विशेष रूप से ठोस:
एस (एकल जिम्मेदारी):

एक मॉड्यूल को केवल एक कार्य करना चाहिए, इसके बारे में मत भूलना!

I (इंटरफ़ेस पृथक्करण):

अलग-अलग ऑपरेशन के लिए अलग-अलग इंटरफेस का उपयोग करें!

अच्छी तरह से और इतने पर।

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

एक प्रोग्रामर जो किसी प्रकार की अवधारणा में (उदाहरण के लिए, ऊपर से) धाराप्रवाह है, खुद को सर्वोत्तम प्रथाओं का उपयोग करके कोड लिखेगा, भले ही उसने उनके बारे में एक शब्द भी नहीं सुना हो। और उनकी टीम के संबंध को औपचारिक रूप देने के लिए उन्हीं सर्वोत्तम प्रथाओं की आवश्यकता होती है - जो कि उनके कोड तक पहुंचती हैं और निश्चित रूप से, GRASP।

मैं नौसिखिए प्रोग्रामर से क्या कहना चाहूंगा:

1. अवधारणाओं को जानें, पैटर्न को नहीं। अवधारणाएं वास्तव में महत्वपूर्ण हैं।
2. अगर आपको अचानक होश आता है कि आप पैटर्न नहीं जानते हैं, तो घबराएं नहीं। यह केवल रिक्रूटर के लिए ही मायने रखेगा, लेकिन आपके कोड और अच्छी शैली के लिए नहीं।

मैं हब्र के गुरु से क्या कहना चाहूंगा:

1. मैं गलत हो सकता हूं। गंभीरता से।
2. मैं समझता हूं कि यह विचार आम है। लेकिन, फिर भी, किसी कारण से मैं अक्सर शुरुआती लोगों के लिए समान दृष्टिकोण के साथ आता हूं।
3. पैराग्राफ 2 के आधार पर, एक समान लेख मेरे सामने पहले से ही लिखा जा सकता है। मुझे नहीं पता

और अंत में: लेख, ज़ाहिर है, व्यक्तिपरक है, मैं किसी से (कारखानों से लड़ने के लिए) किसी से भी आग्रह नहीं करता हूं। यह सिर्फ मेरी राय है :)

इसके अलावा, मैं केवल एक जूनियर हूं, लेकिन इस दृष्टिकोण - विशेष पर बहुत अधिक ध्यान देने के लिए - हमेशा मुझे गलतफहमी में ले गया है।

आपका दिन शुभ हो!