कैसे दो प्रोग्रामर ने रोटी सेंकी

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

तो, कल्पना कीजिए कि दो प्रोग्रामर हैं। उनमें से एक स्मार्ट है, हैबे पर लेखों का एक गुच्छा पढ़ें, दिल से गोफ कैटलॉग जानता है , और फाउलर - व्यक्ति में। दूसरा सब कुछ सरल करता है। पहले को बुलाया जाएगा, उदाहरण के लिए, बोरिस एन।, और दूसरा - मार्कस पी। बेशक, नाम काल्पनिक हैं, और वास्तविक लोगों और प्रोग्रामर के साथ सभी संयोग यादृच्छिक हैं।

इसलिए, प्रोजेक्ट मैनेजर उन दोनों के पास आता है (यदि आपके ब्रह्मांड में पीएम स्वयं प्रोग्रामर्स के पास नहीं जाते हैं, तो इसे कुछ और कहें, उदाहरण के लिए बीए या लीड , यह सार नहीं बदलेगा) और कहते हैं:
- दोस्तों, हमें रोटी बनाने की जरूरत है।

बिल्कुल ऐसा, यह उत्पादन की विधि को निर्दिष्ट किए बिना "किया गया" था।

हमारे प्रोग्रामर क्या करेंगे?



बोरिस अपना पहला अमूर्त बनाता है - उत्पाद वर्ग, वह ब्रेड वर्ग से विरासत में मिला है, और इस वर्ग के उदाहरणों को प्रस्तुत करता है, ProductFactory वर्ग का कारखाना तरीका - createProduct ()।

मार्कस उसी के बारे में करता है। यह ब्रेड क्लास और मैनेजर क्लास को फैक्ट्री क्रिएटब्रेड () विधि से बनाता है।

जबकि अंतर न्यूनतम है। परियोजना प्रबंधक, ग्राहक की जरूरतों को समझने में थोड़ी गहरी समझ रखता है (ऐसा केवल उसे, हाँ) लगता है, एक दूसरी बार आता है और कहता है:
- हमें ज़रूरत है कि रोटी न केवल बनाई जाए, बल्कि ओवन में पकाया जाए।

और तुरंत यह कहना असंभव था कि रोटी वैक्यूम में बेक नहीं की जाती है, लेकिन ओवन में? अच्छा, प्रोग्रामर क्या करते हैं?



बोरिस ProductFactory वर्ग को ओवन में बदल देता है, और अमूर्त को उजागर करता है - AbstractOven। पूरी तरह से सुंदर होने के लिए, वह createProduct () विधि को bakeProduct () में बदल देता है। इस प्रकार, बोरिस ने पहली बार "एब्सट्रैक्शन के निष्कर्षण" का उपयोग करते हुए रिफैक्टरिंग का प्रदर्शन किया और साथ ही साथ "एब्सट्रैक्ट फैक्ट्री" के टेम्पलेट को भी लागू किया जैसा कि साहित्य में वर्णित है। अच्छा किया, बोरिस।

लेकिन मार्कस कुछ नहीं करता। उनके दृष्टिकोण से, सब कुछ इतना अच्छा है। ठीक है, हो सकता है कि यह createBread () कार्यान्वयन को थोड़ा बदल दे।

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

ठीक है, ठीक है।



बोरिस, खुशी से अपने हाथों को रगड़ता है, एब्सट्रैक्ट के तीन वारिस बनाता है - इलेक्ट्रोवेन, माइक्रोवेववेन और गैसऑवन। और वह ओवेन वर्ग को अनावश्यक रूप से हटा देता है।

मार्कस भी कार्यक्रम में बदलाव कर रहे हैं। यह पूर्णांक पैरामीटर ओवनटाइप बनाता है createBread विधि के लिए।

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



बोरिस बिल्कुल अनुचित रूप से मानते हैं कि गैस का केवल एक स्रोत हो सकता है। और ऐसे मामलों के लिए, हमेशा हमारा पसंदीदा टेम्पलेट होता है । वह अकेले GasSourceSingleton बनाता है, और कनेक्टिविटी को कम करने के लिए, वह GasOven में GasSource इंटरफ़ेस के माध्यम से इसे लागू करता है। हुर्रे, उन्होंने सेटर के माध्यम से निर्भरता इंजेक्शन लगाया!

स्वभाव से मामूली, मार्कस प्रबंधक वर्ग में एक वास्तविक निजी गैसलेवल क्षेत्र बनाता है। स्वाभाविक रूप से, आपको createBread पद्धति के तर्क को थोड़ा बदलना होगा, लेकिन आप क्या कर सकते हैं!

लेकिन कुछ दिनों बाद, प्रबंधक पांचवीं बार आता है, और, अपने होंठों को पूरा चाटता है, कहते हैं:
- हमें इसकी आवश्यकता है ताकि ओवन भी पेक को अलग-अलग (मांस के साथ, अलग से - गोभी के साथ), और केक बेक कर सकें।

प्रोग्रामर भी खाना चाहते हैं, इसलिए वे काम पर लग जाते हैं।



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

यह अभी भी सामान्य लगता है, लेकिन मार्कस की तुलना में बहुत अधिक समय लगता है, जिसने बस एक और पूर्णांक पैरामीटर क्रिएटब्रेड विधि - ब्रेड टाइप के साथ जोड़ा।

छठी बार, एक प्रबंधक आता है। वैसे, अब वह जो पूछ रहा है, वह ग्राहक की आवश्यकता नहीं है, यह उसकी अपनी पहल है। लेकिन किसी को इसके बारे में पता नहीं चलेगा, है ना?
- हमें अलग-अलग व्यंजनों के अनुसार रोटी, पाई और केक को सेंकना चाहिए।



"एचएम," बोरिस कहते हैं और "बिल्डर" टेम्पलेट ( "मुक्त इंटरफ़ेस," पाठ्यक्रम के साथ) याद करते हैं। वह पकाने की विधि वर्ग बनाता है, और उसे बिल्डर पकाने की विधि। वह नुस्खा (SUDDENLY!) को स्ट्रेच में सेटरीकेप सेटर (नुस्खा: नुस्खा) का उपयोग करके इंजेक्ट करता है।

और मार्कस (आप इस पर विश्वास नहीं करते हैं) क्रिएट करने के लिए एक और पूर्णांक पैरामीटर जोड़ता है - नुस्खा।

सबसे दिलचस्प, हमेशा की तरह, कंप्यूटर से दूर है। अर्थात्: विकास शुरू होने के बाद पहली बार प्रबंधक ग्राहक के साथ मिलता है और अंत में समझता है कि उसे स्टोव की आवश्यकता क्यों थी। वह (प्रबंधक) सातवीं बार प्रोग्रामर के पास आता है और कहता है:
"हमें ईंटों को ओवन में जलाने की आवश्यकता है।"



बोरिस के लिए, यह प्रबंधक के साथ अंतिम बैठक है, लेकिन फिर भी वह अपने सभी ताकत के साथ वास्तुकला में बदलाव कर रहा है। यह अमूर्त वर्ग पर प्रकाश डालता है AbstractHeatingSmth - एक अमूर्त हीटिंग कुछ। उसके लिए, वह एक ताप कारखाने का निर्माण करता है। AbstractHeatingSmth से, यह ProductOven और Furance को विरासत में मिला है। उत्तरार्द्ध में एक फैक्ट्री मेकब्रिक विधि है जो ब्रिक ऑब्जेक्ट को तत्काल बनाती है। लेकिन कुछ भी काम नहीं करता है। पाठक को स्वतंत्र रूप से वास्तुकला में गलती खोजने के लिए आमंत्रित किया जाता है।

माक्र्स भी इतने चिकने नहीं होते। उसे एक पंक्ति वर्ग में तीसरा (!) बनाना है। वह इसे ब्रिक कहते हैं, और मेकब्रिक विधि को अपने प्रबंधक में जोड़ते हैं।

बेशक, कोई यह तर्क दे सकता है कि मार्कस विज्ञापन और इजरायल को क्रिएटब्रेड विधि के अंदर बना रहा है, और यह वास्तव में ऐसा है। लेकिन टेम्पलेट विधि टेम्पलेट का उपयोग करके , गड़बड़ संरचित किया जा सकता है। और कारखानों और सार की प्रचुरता को समझने के लिए, अच्छी तरह से, थोड़ा और अधिक जटिल।

मैं जो निष्कर्ष निकालना चाहता हूं, वह शायद थोड़ा अनुमानित है।

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

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

और सब कुछ नए सिरे से लिखने के लिए, यदि वह, - यह हमेशा समय में होगा।

^{मैंने यहाँ से तस्वीर ली}

युपीडी। यह बहुत सुखद है कि लेख को इतनी प्रतिक्रियाएँ मिलीं। यहां , उदाहरण के लिए, हास्केल पर इस समस्या का समाधान, लेकिन सूची पर।

UPD.2 और यहाँ C # संस्करण है। और कौन?

UPD.3 मार्कस और YAGNI की रोटी