मार्कस ब्रेड और YAGNI

हाल ही में, दो हीरोज हमारे न्यूज़फ़ीड में दिखाई दिए, प्रोग्रामर-बेकर्स - बोरिस और मार्कस। बोरिस एक अच्छा व्यक्ति और एक पूर्णतावादी है, और मार्कस एक बहुत ही विनम्र और ग्रे प्रोग्रामर है जो बाहर खड़ा नहीं होना चाहता है। दोनों सर्वश्रेष्ठ के लिए प्रयास करते हैं और सेवा में रहना चाहते हैं। लेकिन ऐसा लगता है कि मार्कस ने बहुत कोशिश नहीं की।
यह एक नई शाखा है - जारी है। आज, कहानी केवल मार्कस को छूती है। वह मुख्य किरदार है।
तो, कहानी कट के नीचे है।

मूल पोस्ट: कैसे दो प्रोग्रामर रोटी सेंकते हैं

प्रविष्टि

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

आज मैं माक्र्स की स्थिति का पुनर्वास करने की कोशिश करूंगा। पोस्ट YAGNI के सिद्धांत के लिए समर्पित होगी। यह केवल YAGNI का उपयोग करने का एक उदाहरण है और व्यक्तिगत अनुभव पर आधारित है। दुर्भाग्य से, कई किताबें नहीं हैं जो उदाहरणों से दिखाती हैं कि इस सिद्धांत को कैसे लागू किया जाए। और अधिकांश प्रोग्रामर, किताबें पढ़ने के अलावा, अनुभव और काम के माध्यम से इन कौशल को जन्म देते हैं। मेरा मानना ​​है कि ये कोड कौशल हैं, न कि केवल सिद्धांत। और इस तरह के अनुभव को साझा करना अच्छा होगा। मुझे खुशी होगी अगर मैं भी आपसे कुछ नया सीखूं। यह पद केवल अभ्यास के लिए समर्पित है और कार्य C # में माना जाएगा। जो, दुर्भाग्य से, संभावित दर्शकों को कम कर सकता है। लेकिन मुझे कोई और रास्ता नहीं दिख रहा है, क्योंकि सिद्धांत खुद विरोधियों द्वारा स्वीकार नहीं किया जा सकता है जब तक कि वे वास्तविक संभावनाएं नहीं देखते हैं। यूएमएल श्रेणी के चित्र मुझे पसंद नहीं हैं। और मार्कस के लिए, जाहिरा तौर पर, उन्हें ज़रूरत नहीं थी।

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

और हां, मैं तुच्छ बातें लिखूंगा। बहुतों के साथ, टिप्पणियों को देखते हुए, मैं जैसा सोच रहा हूं और वे इस तरह की पोस्ट को और भी बुरा कहेंगे। और कुछ बहुत बेहतर हैं (एक कार्यात्मक दृष्टिकोण का उपयोग करके)।

चलिए शुरू करते हैं। आवश्यकताओं की पूरी श्रृंखला से गुजरते हैं। मैं माक्र्स हूं। सच है, मैं थोड़ा अलग माक्र्स हूं और पिछले वाले की तरह व्यवहार नहीं करता।

आवश्यकता १
- दोस्तों, हमें रोटी बनाने की जरूरत है

के विश्लेषण

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

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

class Bread { } class BreadMaker { public static Bread MakeBread() { return new Bread(); } } 

आवश्यकता २
- हमें ज़रूरत है कि रोटी न केवल बनाई जाए, बल्कि ओवन में पकाया जाए

के विश्लेषण

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

मैं अभी तक कुछ नहीं कर रहा हूँ लेकिन सिर्फ मामले में, मुझे स्टोव याद है। ग्राहक ने ओवन को इंगित नहीं किया, न ही उनके मतभेद, न ही रोटी पर उनके अलग-अलग प्रभाव। उत्तरार्द्ध भी महत्वपूर्ण है। यहां तक ​​कि अगर ग्राहक ने कई प्रकार के ओवन का संकेत दिया, तो वैसे भी जल्दी करने के लिए कोई जगह नहीं है - रोटी समान है।

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

 class BreadMaker { public static Bread BakeBread() { return new Bread(); } } 

आवश्यकता ३
- हमें गैस चूल्हा चाहिए जो बिना गैस के बेक नहीं हो सकता

के विश्लेषण

ओह! नई जानकारी आ गई है। यह पता चला है कि एक गैस भट्ठी है और इसका व्यवहार अन्य भट्टियों से अलग है। सच है, अन्य भट्टियों के विषय का फिर से खुलासा नहीं किया गया है। अच्छा, ठीक है। उन्हें अलग होने दें।

आइए कई कार्यान्वयनों की तुलना करने का प्रयास करें।

कार्यान्वयन 1।

 enum Oven { GasOven, OtherOven } class BreadMaker { public static double GasLevel { get; set; } public static Bread BakeBread(Oven oven) { return oven == Oven.GasOven && GasLevel == 0 ? null : new Bread(); } } 

दुष्प्रभाव तुरंत स्पष्ट है। कॉल से BakeBread () तक गैस स्तर अलग से सेट किया गया है। एक बार अंतराल होने के बाद, बग की उपस्थिति के लिए संभावनाओं का एक विस्तृत क्षेत्र खुलता है। इन कीड़े (कीड़े) की उपस्थिति हमारे खेत को नुकसान पहुंचा सकती है, फिर गेहूं और इसलिए, रोटी नहीं होगी।

मापदंडों की इस तरह की एक अलग स्थापना के साथ, हमारे कोड का उपयोगकर्ता (और हम इस पीड़ित उपयोगकर्ता हो सकते हैं) गैस भट्ठी शुरू करने से पहले गैस स्तर सेट करना अच्छी तरह से भूल सकते हैं। और तब गैस का स्तर ओवन की पिछली सेटिंग से बना रह सकता है, जब हमने पहले से ब्रेड को बेक किया था। अगर हम वास्तव में भूल जाते हैं तो अप्रत्याशित व्यवहार को बढ़ावा मिलेगा।

हम यह भी देखते हैं कि संपत्ति स्थिर है। जो बहुत खराब है - हमारे पास केवल एक गैस स्तर है। लेकिन स्थिर तरीकों और गुणों से छुटकारा पाने से ऊपर वर्णित समस्या का समाधान नहीं होगा, इसलिए हम इस विकल्प पर विचार नहीं करते हैं।

क्रियान्वयन २।

 enum Oven { GasOven, OtherOven } class BreadMaker { public static Bread BakeBread(Oven oven, double gasLevel) { return oven == Oven.GasOven && gasLevel == 0 ? null : new Bread(); } } 

बहुत ही सरल। और पिछले कार्यान्वयन की तुलना में थोड़ा बेहतर है। लेकिन संगत पैरामीटर हमेशा BakeBread () विधि से पारित नहीं होते हैं। गैर-गैस भट्टियों के लिए GasLevel का कोई मतलब नहीं है। और यद्यपि यह विधि काम करेगी, गैर-गैस भट्टियों के लिए गैसलेवेल का कार्य हमारे कोड के उपयोगकर्ताओं को भ्रमित करेगा। और संकलन चरण में मापदंडों की शुद्धता की जांच नहीं की जाती है।

कार्यान्वयन 3. मापदंडों पर सहमत होने के लिए, कक्षाओं की तरह प्रतीत होने के लिए भट्ठी बनाई जाएगी।
इसके अलावा, हमेशा की तरह रोटी हमेशा चलती है, और गैस हमेशा नहीं होती है। यानी दो कक्षाएं, आभासी तरीके, अधिभार। लेकिन आपको यह सोचने की ज़रूरत है कि उनके लिए एक्सेस मॉडिफ़ायर कैसे करें ताकि ओवन अपने दम पर न बनाएं, लेकिन मेरे BakeBread () विधि का उपयोग करें, अन्यथा, साइड इफेक्ट दिखाई देंगे।

और फिर यह मुझ पर (मार्कस)! इस स्तर पर, बस यह करें:

 class BreadMaker { public static Bread BakeBreadByGasOven(double gasLevel) { return gasLevel == 0 ? null : new Bread(); } public static Bread BakeBreadByOtherOven() { return new Bread(); } } 

वास्तव में, ग्राहक ने अभी तक एक शब्द भी नहीं कहा है कि हम स्टोव का उपयोग कैसे करेंगे। इस स्तर पर ऐसा कोड काफी संतोषजनक है।

आवश्यकता ४
- हमें इसकी आवश्यकता है ताकि ओवन भी पेक को अलग-अलग (मांस के साथ, अलग से - गोभी के साथ), और केक बेक कर सकें।

के विश्लेषण

हाँ, कोई सवाल नहीं! और अगर आप ओवन में तापमान का स्तर निर्धारित करते हैं, तो हम इसमें आइसक्रीम सेंक सकते हैं। एक चुटकुला। मैं, मार्कस, गंभीर होने की कोशिश करता हूं - तापमान के बारे में एक शब्द नहीं। आपको कौन जानता है, ग्राहक))

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

समानांतर में, हम नामों को बदलते हैं, अब हम रोटी नहीं बल्कि बेकरी उत्पादों को पका रहे हैं।

 public enum BakeryProductType { Bread, MeatPasty, CabbagePasty, Cake } public class BakeryProduct { public BakeryProduct(BakeryProductType bakeryProductType) { this.BakeryProductType = bakeryProductType; } public BakeryProductType BakeryProductType { get; private set; } } class BakeryProductMaker { public static BakeryProduct BakeByGasOven(BakeryProductType bakeryProductType, double gasLevel) { return gasLevel == 0 ? null : new BakeryProduct(bakeryProductType); } public static BakeryProduct BakeByOtherOven(BakeryProductType breadType) { return new BakeryProduct(breadType); } } 

आवश्यकता ५
- हमें अलग-अलग व्यंजनों के अनुसार रोटी, पाई और केक को सेंकना चाहिए

के विश्लेषण

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

 public enum Recipe { Bread, MeatPasty, CabbagePasty, Cake } public class BakeryProduct { public BakeryProduct(Recipe recipe) { this.BakeryProductType = recipe; } public Recipe BakeryProductType { get; private set; } } class BakeryProductMaker { public static BakeryProduct BakeByGasOven(Recipe recipe, double gasLevel) { return gasLevel == 0 ? null : new BakeryProduct(recipe); } public static BakeryProduct BakeByOtherOven(Recipe recipe) { return new BakeryProduct(recipe); } } 

आवश्यकता ६
"हमें ईंटों को ओवन में जलाने की आवश्यकता है।"

के विश्लेषण

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

क्या आप में से किसी ने कोड में हॉरर देखा था? शायद इस कोड का परीक्षण करना मुश्किल है? हाँ, ऐसा लगता है, बोरिस का कोड परीक्षण करना अधिक कठिन है। वॉल्यूम अधिक है, अधिक परीक्षण। आवश्यकता से अधिक कार्यक्षमता? अधिक परीक्षण।
बेशक, स्पष्ट रूप से, मूल पद का अर्थ है कि आवश्यकताएं अधिक विस्तृत थीं और प्रत्येक वाक्यांश को विस्तृत स्पष्टीकरण के साथ स्पष्ट किया गया था। लेकिन YAGNI शैली को सोचने की आवश्यकता नहीं है।

आगे आवश्यकताओं को निभाते हैं।

आवश्यकता 7
"तुमने कैसे नहीं देखा?" हर चूल्हा ईंट नहीं जला सकता। ऐसा करने के लिए, आपको एक विशेष ओवन की आवश्यकता है।

के विश्लेषण

अच्छा, ठीक है। हम गणना (व्यंजनों?) से ईंट हटाते हैं और नाम वापस करते हैं। एक अलग खाली ईंट वर्ग बनाएं। और एक नई विधि:

 public static Brick MakeBrickByFurnace() { return new Brick(); } 

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

इसके अलावा, ग्राहक ने मार्कस के खिलाफ खेलने का फैसला किया।

आवश्यकता 8
- प्रत्येक नुस्खा में उत्पादों और उनकी मात्रा (वजन) शामिल होना चाहिए। मांग में व्यंजन जुड़े हुए हैं।

के विश्लेषण

पहला खून जो बोरिस का इंतजार कर रहा था।

आइए भयानक स्पेगेटी कोड के साथ सामना करने की कोशिश करें, जिसे लंबे समय तक यहां बनना चाहिए था और हमें रिफ्लेक्टर का कोई मौका नहीं देना चाहिए। क्या ऐसा है?

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

यानी ग्राहक ने यह नहीं कहा कि नुस्खा में उत्पाद और वजन भिन्न हो सकते हैं। बेशक, उन्होंने यह नहीं कहा कि उन्हें ठीक किया जाना चाहिए। लेकिन तय मामला अधिक सीमित और सख्त है। और हम हमेशा अधिक सीमित मामलों का चयन करते हैं। हमारे लिए, यह अधिक लचीला नहीं होना बेहतर है, लेकिन सरल और कठोर होना है।

और उत्पादों के एक सख्त सेट के साथ नुस्खा - बेहतर व्यक्तिगत अनुभव से मेल खाती है। यह इस प्रकार है कि इस मामले में वंशानुक्रम का उपयोग करना और प्रत्येक नुस्खा के लिए एक वर्ग लिखना व्यावहारिक नहीं है। फिर प्रत्येक वर्ग सिर्फ स्थिरांक रखेगा।

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

उपरोक्त शर्तों को पूरा करने के लिए, बस इस तरह:

 public enum RecipeName { Bread, MeatPasty, CabbagePasty, Cake } public enum RecipeProduct { Salt, Sugar, Egg, Flour } public class Recipe { private Recipe() { } public RecipeName Name { get; private set; } public IEnumerable<KeyValuePair<RecipeProduct, double>> Products { get; private set; } private static Dictionary<RecipeName, Dictionary<RecipeProduct, double>> predefinedRecipes; static Recipe() { predefinedRecipes = new Dictionary<RecipeName, Dictionary<RecipeProduct, double>> { { RecipeName.Bread, new Dictionary<RecipeProduct, double> { {RecipeProduct.Salt, 0.2}, {RecipeProduct.Sugar, 0.4}, {RecipeProduct.Egg, 2.0}, {RecipeProduct.Flour, 50.0} } } .................. }; } public static Recipe GetRecipe(RecipeName recipeName) { Recipe recipe = new Recipe(); recipe.Name = recipeName; recipe.Products = predefinedRecipes[recipeName]; return recipe; } } 

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

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

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

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

के विश्लेषण

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

अब हमारे पास दो कंस्ट्रक्टर हैं:

 private Recipe() { } public Recipe(IEnumerable<KeyValuePair<RecipeProduct, double>> products) { Dictionary<RecipeProduct, double> copiedProducts = new Dictionary<RecipeProduct, double>(); foreach (KeyValuePair<RecipeProduct, double> pair in products) { copiedProducts.Add(pair.Key, pair.Value); } this.Products = copiedProducts; } 

एक दूसरा निर्माणकर्ता एक प्रति बनाता है। इसका कारण है C # प्रॉपर्टीज - ​​डिफॉल्ट लिंक्स को पास करना। कक्षा के उपयोगकर्ता के पास एक लिंक होगा, और यदि आप प्रतिलिपि नहीं बनाते हैं, तो वह बाद में नुस्खा के अवयवों को बदलने में सक्षम होगा। हमारी योजनाओं में क्या शामिल नहीं है।

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

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

हमें किसी प्रकार की निकटता विधि लिखने की आवश्यकता है। ग्राहक ने निर्दिष्ट नहीं किया, इसलिए हम सबसे कम से कम वर्ग विधि के साथ सबसे सरल लिखेंगे। यह देखते हुए कि प्रत्येक घटक का एक अलग "वजन" है। अभी के लिए, हम कुछ वज़न लिखेंगे जिन्हें आप बाद में समायोजित कर सकते हैं।

कोड इस प्रकार है:

 private double GetDistance(Recipe recipe) { Dictionary<RecipeProduct, double> weights = new Dictionary<RecipeProduct, double>(); weights[RecipeProduct.Salt] = 50; weights[RecipeProduct.Sugar] = 20; weights[RecipeProduct.Egg] = 5; weights[RecipeProduct.Flour] = 0.1; double sum = 0.0; foreach(KeyValuePair<RecipeProduct, double> otherProductAmount in recipe.Products) { var productAmounts = this.Products.Where(p => p.Key == otherProductAmount.Key); if (productAmounts.Count() == 1) { sum += Math.Pow(productAmounts.First().Value - otherProductAmount.Value, 2) * weights[otherProductAmount.Key]; } else { return double.MaxValue; } } return sum; } private RecipeName GetRecipeName() { IEnumerable<Recipe> etalons = ((RecipeName[])Enum.GetValues(typeof(RecipeName))) .Select(recipeName => Recipe.GetReceipt(recipeName)); IEnumerable<KeyValuePair<RecipeName, double>> recipeNamesWithDistances = etalons .Select(e => new KeyValuePair<RecipeName, double>(e.Name, GetDistance(e))); double minDistance = recipeNamesWithDistances.Min(rd => rd.Value); if (minDistance == double.MaxValue) { throw new Exception("   "); } return recipeNamesWithDistances.First(rd => rd.Value == minDistance).Key; } 

और कंस्ट्रक्टर कॉल में, क्रमशः नामकरण जोड़ा जाता है:

 public Recipe(IEnumerable<KeyValuePair<RecipeProduct, double>> products) { Dictionary<RecipeProduct, double> copiedProducts = new Dictionary<RecipeProduct, double>(); foreach (KeyValuePair<RecipeProduct, double> pair in products) { copiedProducts.Add(pair.Key, pair.Value); } this.Products = copiedProducts; this.Name = GetRecipeName(); } 

यह हमेशा मक्खी पर गणना करने के लिए अधिक विश्वसनीय होगा। लेकिन फिर किसी को संदर्भ के लिए और गैर-निश्चित व्यंजनों के लिए नामकरण के अलगाव के साथ आना होगा। यह अभी के लिए पर्याप्त है।

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

कोड सही नहीं है, मैं मदद नहीं कर सकता, लेकिन ज़ेनेरिकी और लैम्ब्डा में भाग सकता हूं। तो कोड छोटा और क्लीनर हो जाता है। मुझे उम्मीद है कि इससे अपरिचित पाठकों की C # और लंबोदर की समझ को चोट नहीं पहुंचेगी। बेशक, इसे और कम किया जा सकता है। लेकिन मैं अधिक लोगों द्वारा समझने की कोशिश कर रहा हूं।

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

स्पष्ट व्यवसाय, अब निर्माण विधियों में नुस्खा का नाम नहीं, बल्कि व्यंजनों को स्वयं स्थानांतरित करना आवश्यक है। यानी इस तरह:

 public class BakeryProduct { public BakeryProduct(Recipe recipe) { this.BakeryProductType = recipe.Name; } public RecipeName BakeryProductType { get; private set; } } 

और:

 public static BakeryProduct BakeByGasOven(Recipe recipe, double gasLevel) { return gasLevel == 0 ? null : new BakeryProduct(recipe); } public static BakeryProduct BakeByOtherOven(Recipe recipe) { return new BakeryProduct(recipe); } 

यहां पर रिफलेक्टिंग अधिक तनाव से दूर है।

आवश्यकता १०
कपटी ग्राहक ने किसी तरह हमारे कोड का अध्ययन किया और सबसे दर्दनाक जगह की तलाश में है, जिसके लिए हमारा कोड पूरी तरह से अप्रस्तुत है।आखिरकार, हमें पहले से ही 9 बार अपठनीय स्पेगेटी प्राप्त करना चाहिए। हमने बिना किसी योजना के लिखा है और हमारा कोड बहुत लचीला नहीं है। जाहिरा तौर पर बोरिस उसके साथ एक साजिश में प्रवेश किया और वे कमजोरियों की तलाश कर रहे हैं।

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

के विश्लेषण

इससे पहले, कभी-कभी हमारे ओवन में असंबंधित चीजें बनाई जाती थीं। उदाहरण के लिए ईंट। रोल के साथ उनका कोई सामान्य पूर्वज नहीं है। और ठीक ही तो, हम कैसे जान सकते हैं कि उनमें क्या समानता है? नहीं, बेशक, जीवन में हम ईंटों के बारे में और रोटी के बारे में जानते हैं। लेकिन हमें विश्वास नहीं हो रहा था कि ग्राहक उन्हें बाद में एक उत्पाद के रूप में मानना ​​चाहेंगे। फिर, हमारे पास तीन अलग-अलग तरीके हैं जो ओवरलैप नहीं करते हैं। कोई एक विधि नहीं है जो किसी भी चीज का उत्पादन करेगी। लेकिन क्या यह होना चाहिए? कोई पूर्वज नहीं था। नहीं करना चाहिए।

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

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

यानीसमयपूर्व लचीलापन न केवल फायदेमंद है, बल्कि हानिकारक है।

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

है। बन्स और ईंटों में एक सामान्य पूर्वज दिखाई दिया - माल।

 public abstract class Article { public double Price { get; private set; } public Article(double price) { this.Price = price; } } 

इनहेरिट क्लासेस:

 public class BakeryProduct : Article { public BakeryProduct(Recipe recipe, double price): base(price) { this.BakeryProductType = recipe.Name; } public RecipeName BakeryProductType { get; private set; } } public class Brick: Article { public Brick(double price) : base(price) { } } 

और हम रिफ्लेक्टर निर्माण विधियों को कॉल करते हैं, जो मूल्य डिजाइनरों को सेट करता है।

कुछ इस तरह:

 public static BakeryProduct BakeByOtherOven(Recipe recipe, double price) { return new BakeryProduct(recipe, price); } 

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

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

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

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