कोड जीवित और मृत है। भाग दो क्रिया और गुण

पिछली बार, मैंने लिखा था कि वस्तुओं के नाम बहुत महत्व के हैं, और उन्हें ध्यान से और विवरणों पर ध्यान देने की आवश्यकता है। बुरा नाम डराता है और जो हो रहा है उसके सार को समझने की अनुमति नहीं देता है। लेकिन इसका सार क्या है?

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

इसके बारे में - लेख में।

सामग्री की चक्र तालिका

1. वस्तुएं
2. क्रिया और गुण
3. पाठ के रूप में कोड

कार्रवाई

चरित्र हमला करता है, बचाव करता है, चकमा देता है, एक धनुष से गोली मारता है, मंत्र का उपयोग करता है, एक ब्लेड तरंगों का उपयोग करता है। नाम वस्तु को दर्शाता है, लेकिन वस्तु स्वयं गति में है, प्रतिक्रिया में, क्रिया में है। अन्यथा, हम एक्सेल में तालिकाओं के बारे में बात करेंगे।

C # में, क्रियाएँ विधियाँ और कार्य हैं। और हमारे लिए: क्रिया, मौखिक आंदोलन के परमाणु। क्रियाओं का समय चलता है, क्योंकि उनमें वस्तुएं मौजूद होती हैं और आपस में संपर्क करती हैं। जहां एक बदलाव है - एक क्रिया होनी चाहिए।

setters

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

उदाहरण के लिए, Status प्रॉपर्टी के साथ IPullRequest है, जिसे Approved , Declined या Merged किया जा सकता है। आप pullRequest.Status = Status.Declined को लिख सकते हैं, लेकिन यह कहने के लिए समान है कि "रद्द किए गए स्थिति के लिए पूल अनुरोध सेट करें" आवश्यक है। बहुत अधिक मजबूत है pullRequest.Decline() और, तदनुसार, pullRequest.Approve() , pullRequest.Merge() ।

एक सक्रिय क्रिया एक सेटर के लिए बेहतर है, लेकिन सभी क्रियाएं नहीं हैं।

निष्क्रिय आवाज

PerformPurchase , DoDelete , MakeCall ।

HeroManager एक महत्वपूर्ण संज्ञा एक अर्थहीन Manager द्वारा अस्पष्ट है, इसलिए PerformMigration - Perform । सब के बाद, अधिक जीवित - बस Migrate !

सक्रिय क्रियाएं पाठ को ताज़ा करती हैं: "हिट" नहीं , बल्कि "हिट" ; "झूला नहीं बनाया" , लेकिन "लहराया" ; "निर्णय नहीं लिया" , लेकिन "निर्णय लिया" । तो कोड में: PerformApplication → Apply ; DoDelete → Delete ; PerformPurchase → Purchase , Buy । (लेकिन DealDamage बस गया है, हालांकि दुर्लभ मामलों में Attack का मतलब हो सकता है ।)

निष्क्रिय आवाज से बचते हुए, हम कहानी को विकसित करते हैं, पात्रों को आगे बढ़ाते हैं, लेकिन हमें यह भी सुनिश्चित करने की आवश्यकता है कि फिल्म ब्लैक एंड व्हाइट में न निकले।

मजबूत क्रिया

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

तो खिलाड़ी के स्वास्थ्य में परिवर्तन खिलाड़ी के माध्यम से व्यक्त किया जा सकता है। player.Health = X player.SetHealth या player.SetHealth , लेकिन अधिक सुरम्य player.SetHealth है। player.RestoreHealth ।

या, उदाहरण के लिए, हम Stack को Add/Remove , बल्कि Push/Pop जानते हैं।

मजबूत और सक्रिय क्रियाएं व्यवहार के साथ वस्तु को संतृप्त करती हैं, अगर वे बहुत विशिष्ट नहीं हैं।

निरर्थक भाग

जैसा कि ManualResetEvent साथ, हम .NET के टेक्निकल ManualResetEvent के करीब ManualResetEvent हैं, जो कि जटिल हैं और यह केवल उन्हें व्यक्त करने के लिए अच्छा होगा, जितना अधिक विवरण और API की अधिकता।

ऐसा होता है कि आपको दूसरे धागे पर कुछ काम करने की ज़रूरत है, लेकिन ताकि इसे बनाने और रोकने के बारे में परेशान न हों। C # में इसके लिए ThreadPool है। केवल यहाँ एक सरल "काम कर रहा है" यहाँ - QueueUserWorkItem ! उपयोगकर्ता ( User ) नहीं है, तो यह किस तरह का कार्य आइटम ( WorkItem ) है और यह क्या हो सकता है, यह स्पष्ट नहीं है। बहुत आसान होगा - ThreadPool.Run या ThreadPool.Execute । ThreadPool.Execute ।

एक और उदाहरण। यह याद रखना और जानना कि परमाणु तुलना-और-अदला-बदली (CAS) निर्देश अच्छा है, लेकिन इसे साफ करने के लिए कोड को पोर्ट करना सबसे अच्छा समाधान नहीं है। Interlocked.CompareExchange(ref x, newX, oldX) Atomically.Change(ref x, from: oldX, to: newX) (नामित मापदंडों का उपयोग करके Atomically.Change(ref x, from: oldX, to: newX) ।

कोड क्वांटम कंप्यूटर के साथ काम करने में डॉक्टरेट नहीं है, गणितीय गणनाओं के लिए एक आवेदन नहीं है, लेकिन पाठक कभी-कभी पूरी तरह से उदासीन होता है कि निम्न-स्तरीय निर्देश क्या कहते हैं। हर दिन का उपयोग महत्वपूर्ण है।

दुहराव

UsersRepository.AddUser , Benchmark.ExecuteBenchmark , AppInitializer.Initialize , UniversalMarshaller.Marshal , Logger.LogError ।

जैसा कि मैंने पिछले भाग में कहा था कि पुनरावृत्ति अर्थ को मिटा देती है, स्थान को संकुचित कर देती है।

UsersRepository.AddUser नहीं, लेकिन UsersRepository.Add ; Directory.CreateDirectory नहीं। HttpWebResponse.GetResponseStream नहीं, लेकिन HttpWebResponse.Stream ; Log.Error । Log.Error , लेकिन Log.Error ।

महीन पाला

Check एक कई-पक्षीय शब्द है। अगर उपयोगकर्ता के पास बहुत लंबा नाम है, तो CheckHasLongName या तो एक bool वापस कर सकता है या एक अपवाद फेंक सकता है। बेहतर है bool HasLongName या void EnsureHasShortName । मैं भी CheckRebootCounter , जो ... कहीं अंदर, IIS को पुनरारंभ किया गया!

Enumerate - उसी श्रृंखला से। .NET में एक Directory.EnumerateDirectories(path) विधि है: किसी कारण से, यह निर्दिष्ट किया जाता है कि फ़ोल्डर्स सूचीबद्ध होंगे, हालांकि Directories.Of(path) path.Directories() Directories.Of(path) या path.Directories() ।

Calc - Calculate इतनी बार कम हो जाती है, हालांकि यह कैल्शियम जमा की तरह अधिक दिखता है।

Process लिए Proc एक और फैंसी संक्षिप्त नाम है।

Base , Impl , Internal , Raw - परजीवी शब्द जो वस्तुओं की जटिलता को दर्शाता है।

कुल मिलाकर

फिर, एक चौकस पाठक ध्यान देगा, यह सब सरलीकरण के लिए आता है, प्राकृतिक भाषण की तुलना करने के लिए, और युक्तियां खुद को मोटे तौर पर न केवल कोड के बारे में बताती हैं, बल्कि सामान्य रूप से लिखती हैं। उनका उपयोग करते हुए, डेवलपर कोड को पाठ और पाठ दोनों के रूप में पॉलिश करता है, सरलता के लिए पारदर्शी, चिकनी प्रस्तुति के लिए प्रयास करता है।

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

गुण

चरित्र में स्वास्थ्य और मन है; आइटम खरीदारी की टोकरी में हैं; सौर मंडल में ग्रह होते हैं। ऑब्जेक्ट न केवल निस्वार्थ रूप से कार्य करते हैं, बल्कि संबंधित भी हैं: पदानुक्रम (पूर्वज-वारिस), संरचनात्मक रूप से (पूर्णांक-भाग), स्थानिक रूप से (भंडारण-तत्व), आदि।

C # में, गुण और संबंध ऐसी विधियाँ हैं (आमतौर पर Get शुरू होती हैं), गेटर्स (विशिष्ट बॉडी वाले गुण), और फ़ील्ड। लेकिन हमारे लिए यह है: शब्द-परिवर्धन एक वस्तु का दूसरे से संबंधित व्यक्त करना। उदाहरण के लिए, एक खिलाड़ी का स्वास्थ्य होता है - Player.Health , जो लगभग अंग्रेजी "खिलाड़ी के स्वास्थ्य" से मेल खाता है।

आज जो सबसे ज्यादा उलझन में है वह है एक्शन के तरीके और संपत्ति के तरीके।

संज्ञा के बजाय क्रिया

GetDiscount , CalculateDamage , FetchResult , ComputeFov , CreateMap ।

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

मान लीजिए, IUsersRepository कुछ GetUser(int id) आसानी से अपेक्षित है। क्यों, उपयोगकर्ता का प्रतिनिधित्व करने के लिए, किसी तरह की रसीद के बारे में सोचें ( Get )? यह अधिक सटीक होगा - User(int id) !

और वास्तव में: नहीं FetchResult() , लेकिन Result() ; GetResponse() , बल्कि Response() ; CalculateDamage() , बल्कि Damage() ।

एक DDD टॉक एक "अच्छा" कोड का एक उदाहरण देता है: CalculateDiscountBy(int customerId) विधि के साथ DiscountCalculator । न केवल चेहरे पर एक सममित दोहराव है - DiscountCalculator.CalculateDiscount , उन्होंने यह भी निर्दिष्ट किया कि छूट की गणना की जाती है । और क्या, कोई पूछता है, उसके साथ क्या करना है?

यह स्वयं इकाई से जाने के लिए अधिक मजबूत होगा - Discount static decimal Of(Customer customer, Order order) को कॉल करने के लिए static decimal Of(Customer customer, Order order) विधि के साथ Discount.Of(customer, order) - _discountCalculator.CalculateDiscountBy(customerId) तुलना में सरल है, और एक ही भाषा से मेल खाती है।

कभी-कभी, क्रिया को छोड़ने से, हम कुछ खो देते हैं, जैसा कि, CreateMap() में कहते हैं: Map() साथ एक सीधा प्रतिस्थापन Map() पर्याप्त नहीं हो सकता है। फिर सबसे अच्छा समाधान NewMap() : फिर से, ऑब्जेक्ट सिर पर है, न कि कार्रवाई।

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

अन्य

वस्तुओं के बीच संबंधों को व्यक्त करने वाले गुण और तरीके भी वस्तुएं हैं, इसलिए, कई मामलों में पूर्वोक्त उन पर लागू होता है।

उदाहरण के लिए, गुणों में पुनरावृत्ति: Thread.CurrentThread नहीं। Thread.CurrentThread , लेकिन Thread.Current । Thread.Current ; Inventory.InventoryItems नहीं, बल्कि Inventory.Items , आदि

कुल मिलाकर

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

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

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

इसके साथ ही अच्छे नाम सिर्फ नोट्स हैं। खेलने के लिए , उन्हें संगीत में लिखा और सन्निहित होना चाहिए। मैं आपको अगले, अंतिम लेख में अधिक बताऊंगा।