🈚️ 🚸 🎚️ कोड जीवित और मृत है। भाग एक वस्तुएं 👉 🌫️ 🔉

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

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

मैं इस तरह से लड़ने का प्रस्ताव करता हूं: आपको एक प्राकृतिक भाषा में पाठ के रूप में कार्यक्रमों को प्रस्तुत करने और तदनुसार उनका मूल्यांकन करने की आवश्यकता है। यह कैसे और क्या होता है - लेख में।

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

प्रस्तावना

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

आखिरकार, यह पाठ है।

पाठ के रूप में कोड का सौंदर्यशास्त्र चक्र में एक महत्वपूर्ण विषय है। यहाँ सौंदर्यशास्त्र एक गिलास है जिसके माध्यम से हम चीजों को देखते हैं और कहते हैं, हाँ, यह अच्छा है, हाँ, यह सुंदर है।

सुंदरता और समझ के मामलों में, शब्दों का बहुत महत्व है। कहने के लिए: "फिलहाल, मेरी धारणाएं रक्त में इथेनॉल के उच्च स्तर के कारण सुस्त स्थिति में हैं" यह बिल्कुल भी नहीं है: "मैं नशे में था । "

हम भाग्यशाली कार्यक्रम हैं जो लगभग पूरी तरह से शब्दों से बने हैं।

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

लेकिन मैं संरचनाओं, गुणों से फ़ील्ड्स, और फ़ंक्शन से विधियों को अलग नहीं करूंगा: एक कथा के भाग के रूप में एक चरित्र तकनीकी विवरणों पर निर्भर नहीं करता है (कि इसे या तो एक संदर्भ या एक महत्वपूर्ण प्रकार के रूप में दर्शाया जा सकता है)। एक अनिवार्य रूप से अलग बात: कि यह एक चरित्र है और उन्होंने उसे Hero (या Character ) कहा है, न कि HeroData या HeroUtils ।

अब मैं बहुत ही सौंदर्यबोध का गिलास उठाऊंगा और दिखाऊंगा कि कैसे आज कुछ कोड लिखे गए हैं और यह बिल्कुल सही क्यों है।

वस्तुएं

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

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

किसी वस्तु के बजाय प्रबंधक

UserService , AccountManager , DamageUtils , MathHelper , GraphicsManager , GameManager , VectorUtil ।

यह सटीकता और मूर्तता नहीं है जो यहां हावी है, लेकिन कुछ अस्पष्ट है, जो कोहरे में कहीं छोड़ रहा है। ऐसे नामों के लिए, बहुत कुछ स्वीकार्य है।

उदाहरण के लिए, किसी भी GameManager आप कुछ भी जोड़ सकते हैं जो खेल और खेल तर्क से संबंधित है। छह महीने बाद, एक तकनीकी विलक्षणता आएगी।

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

न केवल पर्याप्त शब्द हैं: हम अभी भी उनका उपयोग करते हैं। केवल साधारण भाषण में, कार्यक्रमों के बीच नहीं।

और यह GitUtils नहीं है, लेकिन IRepository , ICommit , IBranch ; ExcelHelper नहीं, लेकिन ExcelDocument , ExcelSheet ; GoogleDocsService नहीं, लेकिन GoogleDocs ।

हर विषय क्षेत्र वस्तुओं से भरा होता है। "वस्तुओं को विशाल voids द्वारा चिह्नित किया गया था " , "दिल गुस्से से धड़क रहा था" , "घर खड़ा था" - वस्तुएं कार्य करती हैं, उन्हें लगता है, वे कल्पना करना आसान है; वे यहां कहीं भी हैं, मूर्त और घने हैं।

उसी समय, आप कभी-कभी इसे देखते हैं: Microsoft/calculator रिपॉजिटरी में - SetPrimaryDisplay विधियों के साथ: SetPrimaryDisplay , MaxDigitsReached , SetParentDisplayText , OnHistoryItemAdded ...

(फिर भी, मुझे याद है एक बार UtilsManager देखा UtilsManager ...)

यह इस तरह से होता है: मैं नए व्यवहार के साथ List<> प्रकार का विस्तार करना चाहता हूं, और ListUtils या ListHelper पैदा होते हैं। इस मामले में, केवल विस्तार विधियों का उपयोग करना बेहतर और अधिक सटीक है - ListExtensions : वे अवधारणा का हिस्सा हैं, और प्रक्रियाओं से डंप नहीं।

कुछ अपवादों में से एक Post के रूप में OfficeManager ।

बाकी के लिए ... प्रोग्राम्स को संकलित नहीं किया जाना चाहिए अगर उनमें ऐसे शब्द हैं।

वस्तु के बदले क्रिया

IProcessor , ILoader , ISelector , IFilter , IProvider , ISetter , ICreator , IOpener , IHandler ; IEnableable , IInitializable , IUpdatable , ICloneable , IDrawable , ILoadable , IOpenable , ISettable , IConvertible ।

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

बहुत आजीविका ISequence , IEnumerable नहीं; IBlueprint , IBlueprint नहीं; IButtonPainter , IButtonPainter नहीं; IPredicate , IFilter नहीं; IGate , IGate नहीं; IToggle , IToggle नहीं।

एक अच्छी कहानी पात्रों और उनके विकास के बारे में बताती है, न कि इस बारे में कि कैसे निर्माता बनाता है, बिल्डर बनाता है और चित्रकार आकर्षित करता है। एक क्रिया पूरी तरह से एक वस्तु का प्रतिनिधित्व नहीं कर सकती है। ListSorter एक SortedList नहीं है।

DirectoryCleaner लें, उदाहरण के लिए, फ़ाइल सिस्टम पर फ़ोल्डर्स को साफ करने वाली वस्तु। क्या यह सुरुचिपूर्ण है? लेकिन हम कभी नहीं कहते हैं: "फ़ोल्डर क्लीनर को डी: / टेस्ट को साफ करने के लिए कहें" , हमेशा: "क्लीन डी: / टेस्ट" , इसलिए Clean विधि के साथ Directory अधिक प्राकृतिक और करीब लगती है।

एक अधिक जीवंत मामला अधिक दिलचस्प है: .NET से FileSystemWatcher एक फ़ाइल सिस्टम पर्यवेक्षक रिपोर्टिंग परिवर्तन है। लेकिन क्यों पूरे पर्यवेक्षक, यदि परिवर्तन स्वयं रिपोर्ट कर सकते हैं कि वे हुए? इसके अलावा, उन्हें फ़ाइल या फ़ोल्डर के साथ अनिवार्य रूप से जोड़ा जाना चाहिए, इसलिए उन्हें Directory या File ( File को कॉल करने की क्षमता के साथ Changes गुण का उपयोग करके) में भी रखा जाना चाहिए।

ऐसे मौखिक नाम Strategy डिज़ाइन पैटर्न को सही ठहराने के लिए प्रतीत होते हैं, जो "एल्गोरिदम के परिवार को एनकैप्सुलेट" करने के लिए निर्देश देते हैं। लेकिन अगर "एल्गोरिदम के परिवार" के बजाय हम एक प्रामाणिक वस्तु पाते हैं जो कहानी में मौजूद है, तो हम देखेंगे कि रणनीति केवल एक सामान्यीकरण है।

इन और कई अन्य त्रुटियों की व्याख्या करने के लिए, हम दर्शन की ओर मुड़ते हैं।

अस्तित्व पूर्व सार है

MethodInfo , ItemData , AttackOutput , CreationStrategy , StringBuilder , LogBehaviour , LogBehaviour ।

ऐसे नाम एक बात से एकजुट होते हैं: उनका होना विशेष पर आधारित है।

ऐसा होता है कि कुछ कार्य के साथ जल्दी से हस्तक्षेप करता है: कुछ गायब है या कुछ नहीं है। फिर आप सोचते हैं: "एक चीज जो अब एक्स कर सकती है वह मेरी मदद करेगी" - यह इसी तरह अस्तित्व की कल्पना है। फिर, "डू" X करने के लिए, XImpl लिखा जाता है - यह इकाई कैसे दिखाई देती है।

इसलिए, IArrayItem बजाय, IIndexedItem या IItemWithIndex अधिक आम है, या, कहिए, प्रतिबिंब API में, विधि ( Method ) के बजाय, हम इसके बारे में केवल जानकारी देखते हैं ( MethodInfo )।

एक और अधिक सही तरीका: अस्तित्व की आवश्यकता के साथ सामना किया, एक ऐसी इकाई की तलाश करें जो इसे लागू करती है, और, क्योंकि यह इसकी प्रकृति है, अन्य।

उदाहरण के लिए, वे मध्यवर्ती उदाहरणों को MutableString बिना टाइप string के मूल्य को बदलना चाहते थे - यह string के रूप में एक सीधा समाधान निकला, जबकि, मेरी राय में, यह अधिक उपयुक्त है - MutableString ।

फ़ाइल सिस्टम को याद करें: DirectoryRenamer फ़ोल्डर का नाम बदलने की आवश्यकता नहीं है, क्योंकि जैसे ही आप Directory ऑब्जेक्ट की उपस्थिति से सहमत होते हैं, कार्रवाई पहले से ही होती है, आपको कोड में संबंधित विधि नहीं मिली है ।

यदि आप यह वर्णन करना चाहते हैं कि ताला कैसे लेना है, तो यह स्पष्ट करना आवश्यक नहीं है कि यह ILockBehaviour या ILockStrategy , जो कि बहुत आसान है - ILock ( Acquire पद्धति के साथ जो IDisposable या ICriticalSection ( Enter साथ)।

इसमें सभी प्रकार के Data , Info , Output , Input , Args , Args (कम अक्सर State ) शामिल हैं - ऐसी वस्तुएं जो व्यवहार से पूरी तरह से रहित हैं, क्योंकि उन्हें एकतरफा माना जाता था।

जहां अस्तित्व प्राथमिक है, भागफल सामान्य के साथ मिलाया जाता है, और वस्तुओं के नाम भ्रामक हैं - आपको प्रत्येक पंक्ति के माध्यम से पढ़ना होगा और यह पता लगाना होगा कि चरित्र कहां गया और केवल उसका Data क्यों है।

विचित्र वर्गीकरण

CalculatorImpl , AbstractHero , ConcreteThing , CharacterBase ।

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

आखिरकार, क्या वास्तव में एक व्यक्ति ( Human ) है - आधार व्यक्ति ( HumanBase ) का उत्तराधिकारी? लेकिन यह कैसे होता है जब Item AbstractItem विरासत में मिला है?

कभी-कभी वे यह दिखाना चाहते हैं कि Character नहीं है, लेकिन कुछ प्रकार की "कच्ची" समानता है - CharacterRaw ।

Impl , Abstract , Custom , Base , Concrete , Internal , Raw - अस्थिरता का संकेत, वास्तुकला की अस्पष्टता, जो पहले दृश्य से बंदूक की तरह, निश्चित रूप से बाद में शूट करेगी।

दुहराव

नेस्टेड प्रकारों के साथ, यह होता है: RepositoryItem WindowState Repository , WindowState इन Window , HeroBuilder में Hero ।

अर्थ के माध्यम से पुनरावृत्ति में कटौती, दोषों को बढ़ाती है, और केवल पाठ की जटिलता में योगदान करती है।

निरर्थक भाग

थ्रेड्स को सिंक्रनाइज़ करने के लिए, ManualResetEvent का उपयोग अक्सर निम्नलिखित API के साथ किया जाता है:

 public class ManualResetEvent { //   —  `EventWaitHandle`. void Set(); void Reset(); bool WaitOne(); }

हर बार, व्यक्तिगत रूप से, मुझे याद रखना होगा कि Set Reset (असुविधाजनक व्याकरण) से कैसे भिन्न होता है और धाराओं के साथ काम करने के संदर्भ में एक "मैन्युअल रूप से रीसेट घटना" सामान्य रूप से क्या है।

ऐसे मामलों में, प्रोग्रामिंग से दूर रूपकों का उपयोग करना आसान है (लेकिन रोजमर्रा की जिंदगी के करीब):

 public class ThreadGate { void Open(); void Close(); bool WaitForOpen(); }

निश्चित रूप से भ्रमित होने की कोई बात नहीं है!

कभी-कभी यह हास्यास्पद हो जाता है: निर्दिष्ट करें कि आइटम केवल Items नहीं हैं, लेकिन आवश्यक रूप से ItemsList या ItemsDictionary !

हालाँकि, यदि ItemsList मज़ेदार नहीं है, तो स्प्रिंग से AbstractInterceptorDrivenBeanDefinitionDecorator ItemsList । इस नाम के शब्द एक लत्ता हैं जिसमें से एक विशालकाय राक्षस सिलना है। हालांकि ... यदि यह एक राक्षस है, तो फिर क्या है आशा की विरासत ।

वर्ग और इंटरफ़ेस नामों के अलावा, एक अक्सर चर या क्षेत्रों में अतिरेक का सामना करता है।

उदाहरण के लिए, प्रकार IOrdersRepository एक क्षेत्र को IOrdersRepository कहा जाता है। लेकिन यह रिपोर्ट करना कितना महत्वपूर्ण है कि भंडार द्वारा आदेश प्रस्तुत किए जाते हैं? सब के बाद, बहुत आसान - _orders ।

ऐसा भी होता है कि LINQ प्रश्नों में, वे lambda अभिव्यक्तियों के पूर्ण तर्क नाम लिखते हैं, उदाहरण के लिए, Player.Items.Where(item => item.IsWeapon) , हालाँकि हम पहले से ही इस आइटम को Player.Items को Player.Items समझ Player.Items । ऐसे मामलों में, मैं हमेशा एक ही चरित्र का उपयोग करना पसंद करता हूं - x : Player.Items.Where(x => x.IsWeapon) ( y लिए निरंतरता के साथ, z अगर ये फ़ंक्शन के अंदर कार्य हैं)।

कुल मिलाकर

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

लेकिन आप डिस्पोजेबल कप से पी सकते हैं!

मुझे यकीन है कि सामग्री का मार्ग फॉर्म के माध्यम से निहित है, और यदि कोई विचार नहीं देखता है, तो यह प्रतीत होता है। कार्यक्रम के पाठ में, सब कुछ उसी तरह से काम करता है: शैली, वातावरण और ताल खुद को भ्रमित नहीं करने में मदद करते हैं, लेकिन समझ और क्षमता से।

वस्तु का नाम न केवल उसका चेहरा है, बल्कि स्वयं भी है। यह निर्धारित करता है कि क्या यह ईथर या संतृप्त, सार या वास्तविक, सूखा या एनिमेटेड होगा। नाम बदल रहा है - सामग्री बदल रही है।

अगले लेख में हम इसी सामग्री के बारे में बात करेंगे और यह क्या होता है।

कोड जीवित और मृत है। भाग एक वस्तुएं