कोडिंग नियम: सिस्टम तयार करण्यापासून ते ऑब्जेक्ट्ससह कार्य करण्यापर्यंत

शुभ दिवस, प्रत्येकजण! आज आम्ही तुमच्याशी चांगली संहिता लिहिण्याबद्दल बोलू इच्छितो. अर्थात, क्लीन कोड सारखी पुस्तके लगेचच चघळायची आहेत असे प्रत्येकाला वाटत नाही, कारण त्यात भरपूर माहिती असते पण सुरुवातीला फारशी स्पष्ट नसते. आणि जोपर्यंत तुम्ही वाचन पूर्ण कराल, तोपर्यंत तुम्ही कोड करण्याची तुमची सर्व इच्छा नष्ट करू शकता. या सर्व गोष्टींचा विचार करून, आज मी तुम्हाला एक छोटासा मार्गदर्शक (शिफारशींचा एक छोटा संच) उत्तम कोड लिहिण्यासाठी देऊ इच्छितो. या लेखात, सिस्टम तयार करण्याशी संबंधित मूलभूत नियम आणि संकल्पना आणि इंटरफेस, वर्ग आणि ऑब्जेक्ट्ससह कार्य करूया. हा लेख वाचण्यात जास्त वेळ लागणार नाही आणि मला आशा आहे की तुम्हाला कंटाळा येणार नाही. मी माझ्या पद्धतीने वरपासून खालपर्यंत काम करेन, म्हणजे एखाद्या ऍप्लिकेशनच्या सामान्य संरचनेपासून त्याच्या अरुंद तपशीलापर्यंत.

प्रणाली

खालील सामान्यतः सिस्टमची वांछनीय वैशिष्ट्ये आहेत:

• किमान जटिलता. जास्त क्लिष्ट प्रकल्प टाळले पाहिजेत. सर्वात महत्वाची गोष्ट म्हणजे साधेपणा आणि स्पष्टता (साधे = चांगले).
• देखभाल सुलभ. अनुप्रयोग तयार करताना, आपण हे लक्षात ठेवले पाहिजे की त्याची देखभाल करणे आवश्यक आहे (जरी आपण वैयक्तिकरित्या त्याची देखरेख करण्यासाठी जबाबदार नसाल तरीही). याचा अर्थ कोड स्पष्ट आणि स्पष्ट असणे आवश्यक आहे.
• सैल कपलिंग. याचा अर्थ असा की आम्ही प्रोग्रामच्या वेगवेगळ्या भागांमधील अवलंबित्वांची संख्या कमी करतो (OOP तत्त्वांचे आमचे पालन जास्तीत जास्त करणे).
• पुन्हा वापरण्यायोग्यता. आम्‍ही आमच्‍या सिस्‍टमची रचना इतर ॲप्लिकेशनमध्‍ये घटक पुनर्वापर करण्‍याच्‍या क्षमतेसह करतो.
• पोर्टेबिलिटी. एखाद्या प्रणालीला दुसऱ्या वातावरणाशी जुळवून घेणे सोपे असावे.
• एकसमान शैली. आम्ही आमची प्रणाली त्याच्या विविध घटकांमध्ये एकसमान शैली वापरून डिझाइन करतो.
• विस्तारक्षमता (स्केलेबिलिटी). आम्ही प्रणालीच्या मूलभूत संरचनेचे उल्लंघन न करता (एक घटक जोडणे किंवा बदलणे इतर सर्वांवर परिणाम करू नये) वाढवू शकतो.

बदल किंवा नवीन कार्यक्षमतेची आवश्यकता नसलेला अनुप्रयोग तयार करणे व्यावहारिकदृष्ट्या अशक्य आहे. आमच्या ब्रेनचाइल्डला वेळेनुसार राहण्यास मदत करण्यासाठी आम्हाला सतत नवीन भाग जोडण्याची आवश्यकता असेल. येथेच स्केलेबिलिटी कार्यात येते. स्केलेबिलिटी म्हणजे अनुप्रयोगाचा विस्तार करणे, नवीन कार्यक्षमता जोडणे आणि अधिक संसाधनांसह कार्य करणे (किंवा, दुसर्‍या शब्दात, अधिक लोडसह). दुसऱ्या शब्दांत, नवीन तर्क जोडणे सोपे करण्यासाठी, आम्ही काही नियमांचे पालन करतो, जसे की मॉड्यूलरिटी वाढवून सिस्टमचे कपलिंग कमी करणे.

प्रतिमा स्त्रोत

सिस्टम डिझाइन करण्याचे टप्पे

1. सॉफ्टवेअर प्रणाली. एकूणच अनुप्रयोगाची रचना करा.
2. उपप्रणाली/पॅकेजमध्ये विभागणी. तार्किकदृष्ट्या वेगळे भाग परिभाषित करा आणि त्यांच्यातील परस्परसंवादाचे नियम परिभाषित करा.
3. वर्गांमध्ये उपप्रणालींचे विभाजन. प्रणालीचे भाग विशिष्ट वर्ग आणि इंटरफेसमध्ये विभाजित करा आणि त्यांच्यातील परस्परसंवाद परिभाषित करा.
4. पद्धतींमध्ये वर्गांची विभागणी. वर्गासाठी नियुक्त केलेल्या जबाबदारीच्या आधारे आवश्यक पद्धतींची संपूर्ण व्याख्या तयार करा.
5. पद्धत डिझाइन. वैयक्तिक पद्धतींच्या कार्यक्षमतेची तपशीलवार व्याख्या तयार करा.

सहसा सामान्य विकासक हे डिझाइन हाताळतात, तर अनुप्रयोगाचे आर्किटेक्ट वर वर्णन केलेले मुद्दे हाताळतात.

सिस्टम डिझाइनची सामान्य तत्त्वे आणि संकल्पना

आळशी आरंभ. या प्रोग्रॅमिंग इडिओममध्ये, अॅप्लिकेशन ऑब्जेक्ट तयार करण्यात वेळ वाया घालवत नाही जोपर्यंत तो प्रत्यक्षात वापरला जात नाही. हे सुरुवातीच्या प्रक्रियेस गती देते आणि कचरा संग्राहकावरील भार कमी करते. ते म्हणाले, तुम्ही हे फार दूर नेऊ नये, कारण ते मॉड्यूलरिटीच्या तत्त्वाचे उल्लंघन करू शकते. कदाचित बांधकामाची सर्व उदाहरणे काही विशिष्ट भागात हलविणे योग्य आहे, उदाहरणार्थ, मुख्य पद्धत किंवा फॅक्टरी वर्गात. चांगल्या कोडचे एक वैशिष्ट्य म्हणजे पुनरावृत्ती, बॉयलरप्लेट कोडची अनुपस्थिती. नियमानुसार, असा कोड वेगळ्या वर्गात ठेवला जातो जेणेकरून आवश्यकतेनुसार कॉल करता येईल.

AOP

मी पैलू-देणारं प्रोग्रामिंग देखील लक्षात घेऊ इच्छितो. हा प्रोग्रामिंग नमुना पारदर्शक तर्कशास्त्र सादर करण्याबद्दल आहे. म्हणजेच, पुनरावृत्ती कोड वर्गांमध्ये (पैलू) ठेवला जातो आणि जेव्हा काही अटी पूर्ण होतात तेव्हा कॉल केला जातो. उदाहरणार्थ, विशिष्ट नावाने पद्धत कॉल करताना किंवा विशिष्ट प्रकारच्या व्हेरिएबलमध्ये प्रवेश करताना. काहीवेळा पैलू गोंधळात टाकणारे असू शकतात, कारण कोड कोठून कॉल केला जात आहे हे त्वरित स्पष्ट होत नाही, परंतु तरीही ही अतिशय उपयुक्त कार्यक्षमता आहे. विशेषतः कॅशिंग किंवा लॉगिंग करताना. आम्ही सामान्य वर्गांमध्ये अतिरिक्त तर्क न जोडता ही कार्यक्षमता जोडतो. साध्या आर्किटेक्चरसाठी केंट बेकचे चार नियम:

1. अभिव्यक्ती - वर्गाचा हेतू स्पष्टपणे व्यक्त केला पाहिजे. हे योग्य नामकरण, लहान आकार आणि एकल-जबाबदारी तत्त्वाचे पालन करून साध्य केले जाते (ज्याचा आम्ही खाली अधिक तपशीलवार विचार करू).
2. वर्ग आणि पद्धतींची किमान संख्या — वर्ग शक्य तितक्या लहान आणि कमी प्रमाणात केंद्रित करण्याच्या तुमच्या इच्छेनुसार, तुम्ही खूप पुढे जाऊ शकता (परिणामी शॉटगन शस्त्रक्रिया विरोधी नमुना). हे तत्त्व प्रणाली कॉम्पॅक्ट ठेवण्यासाठी आणि खूप दूर न जाता प्रत्येक संभाव्य कृतीसाठी स्वतंत्र वर्ग तयार करण्याचे आवाहन करते.
3. डुप्लिकेट नाही — डुप्लिकेट कोड, जो गोंधळ निर्माण करतो आणि सबऑप्टिमल सिस्टम डिझाइनचा संकेत आहे, काढला जातो आणि वेगळ्या ठिकाणी हलविला जातो.
4. सर्व चाचण्या चालवते — सर्व चाचण्या उत्तीर्ण करणारी प्रणाली व्यवस्थापित करण्यायोग्य आहे. कोणताही बदल चाचणी अयशस्वी होण्यास कारणीभूत ठरू शकतो, हे आम्हाला प्रकट करते की आमच्या पद्धतीच्या अंतर्गत तर्कशास्त्रातील बदलामुळे प्रणालीचे वर्तन देखील अनपेक्षित प्रकारे बदलले आहे.

घन

सिस्टम डिझाइन करताना, सुप्रसिद्ध सॉलिड तत्त्वे विचारात घेण्यासारखे आहेत:

S (एकल जबाबदारी), O (खुले-बंद), L (लिस्कोव्ह प्रतिस्थापन), I (इंटरफेस विलगीकरण), D (अवलंबन उलट).

आम्ही प्रत्येक वैयक्तिक तत्त्वावर राहणार नाही. हे या लेखाच्या व्याप्तीच्या पलीकडे थोडेसे असेल, परंतु आपण येथे अधिक वाचू शकता .

इंटरफेस

चांगल्या प्रकारे डिझाइन केलेला वर्ग तयार करण्याच्या सर्वात महत्त्वाच्या पायऱ्यांपैकी एक म्हणजे एक चांगला डिझाईन केलेला इंटरफेस तयार करणे, जो चांगल्या अमूर्ततेचे प्रतिनिधित्व करतो, वर्गाच्या अंमलबजावणीचे तपशील लपवून ठेवतो आणि त्याच वेळी एकमेकांशी स्पष्टपणे सुसंगत असलेल्या पद्धतींचा समूह सादर करतो. चला सॉलिड तत्त्वांपैकी एक जवळून पाहू - इंटरफेस विलगीकरण: क्लायंटने (वर्ग) अनावश्यक पद्धती लागू करू नये ज्या ते वापरणार नाहीत. दुसऱ्या शब्दांत, जर आपण इंटरफेसचे एकमेव कार्य पूर्ण करण्याच्या उद्देशाने कमीतकमी पद्धतींसह इंटरफेस तयार करण्याबद्दल बोलत आहोत (जे मला वाटते की एकल जबाबदारीच्या तत्त्वासारखे आहे), तर त्याऐवजी दोन लहान तयार करणे चांगले आहे. एका फुगलेल्या इंटरफेसचा. सुदैवाने, एक वर्ग एकापेक्षा जास्त इंटरफेस लागू करू शकतो. तुमच्या इंटरफेसला योग्यरित्या नाव देण्याचे लक्षात ठेवा: नावाने नियुक्त केलेले कार्य शक्य तितक्या अचूकपणे प्रतिबिंबित केले पाहिजे. आणि, अर्थातच, ते जितके लहान असेल तितके कमी गोंधळ होईल. दस्तऐवजीकरण टिप्पण्या सहसा इंटरफेस स्तरावर लिहिल्या जातात. या टिप्पण्या प्रत्येक पद्धतीने काय करावे, त्यासाठी कोणते युक्तिवाद करावे लागतात आणि ते काय परत येईल याबद्दल तपशील देतात.

वर्ग

प्रतिमा स्त्रोत

वर्गांची अंतर्गत व्यवस्था कशी केली जाते ते पाहू या. किंवा त्याऐवजी, काही दृष्टीकोन आणि नियम जे वर्ग लिहिताना पाळले पाहिजेत. नियमानुसार, वर्गाची सुरुवात विशिष्ट क्रमाने व्हेरिएबल्सच्या सूचीसह झाली पाहिजे:

1. सार्वजनिक स्थिर स्थिरांक;
2. खाजगी स्थिर स्थिरांक;
3. खाजगी उदाहरण चल.

यानंतर, सर्वात कमी युक्तिवाद असलेल्यांपासून ते सर्वात जास्त असलेल्यांपर्यंत विविध रचनाकार येतात. ते सर्वात सार्वजनिक ते सर्वात खाजगी पद्धतींद्वारे अनुसरण केले जातात. सर्वसाधारणपणे, खाजगी पद्धती ज्या काही कार्यक्षमतेची अंमलबजावणी लपवतात ज्या आम्ही प्रतिबंधित करू इच्छितो त्या अगदी तळाशी आहेत.

वर्ग आकार

आता मी वर्गांच्या आकाराबद्दल बोलू इच्छितो. सॉलिड तत्त्वांपैकी एक - एकल जबाबदारीचे तत्त्व आठवूया. त्यात असे नमूद केले आहे की प्रत्येक वस्तूचा एकच उद्देश (जबाबदारी) असतो आणि त्याच्या सर्व पद्धतींचे तर्क ते पूर्ण करण्याचे उद्दिष्ट ठेवतात. हे आपल्याला मोठे, फुगलेले वर्ग टाळण्यास सांगते (जे खरं तर देवाच्या वस्तु-विरोधी नमुना आहेत) आणि जर आपल्याकडे वर्गामध्ये सर्व प्रकारच्या विविध तर्कशास्त्र असलेल्या अनेक पद्धती असतील, तर आपण त्यास विभाजित करण्याचा विचार केला पाहिजे. दोन तार्किक भाग (वर्ग). यामुळे, कोडची वाचनीयता वाढेल, कारण आम्हाला कोणत्याही वर्गाचा अंदाजे उद्देश माहित असल्यास प्रत्येक पद्धतीचा उद्देश समजण्यास वेळ लागणार नाही. तसेच, वर्गाच्या नावावर लक्ष ठेवा, जे त्यात असलेले तर्क प्रतिबिंबित केले पाहिजे. उदाहरणार्थ, आपल्याकडे 20+ शब्द असलेला वर्ग असेल तर, आपण रिफॅक्टरिंगबद्दल विचार करणे आवश्यक आहे. कोणत्याही स्वाभिमानी वर्गात इतके आंतरिक चल नसावेत. किंबहुना, प्रत्येक पद्धत त्यांच्यापैकी एक किंवा काही बरोबर कार्य करते, ज्यामुळे वर्गामध्ये खूप एकसंधता निर्माण होते (जे अगदी तसे असले पाहिजे, कारण वर्ग एकसंध असावा). परिणामी, वर्गाची एकसंधता वाढल्याने वर्गाचा आकार कमी होतो आणि अर्थातच वर्गांची संख्या वाढते. काही लोकांसाठी हे त्रासदायक आहे, कारण एखादे मोठे कार्य कसे कार्य करते हे पाहण्यासाठी तुम्हाला क्लास फाइल्सचा अधिक अभ्यास करणे आवश्यक आहे. सर्वात वर, प्रत्येक वर्ग एक लहान मॉड्यूल आहे जो कमीतकमी इतरांशी संबंधित असावा. हे पृथक्करण वर्गात अतिरिक्त तर्क जोडताना आम्हाला आवश्यक असलेल्या बदलांची संख्या कमी करते. प्रत्येक पद्धत त्यांपैकी एक किंवा काहींसोबत कार्य करते, ज्यामुळे वर्गामध्ये खूप एकसंधता निर्माण होते (जे अगदी तसे असले पाहिजे, कारण वर्ग एकसंध असावा). परिणामी, वर्गाची एकसंधता वाढल्याने वर्गाचा आकार कमी होतो आणि अर्थातच वर्गांची संख्या वाढते. काही लोकांसाठी हे त्रासदायक आहे, कारण एखादे मोठे कार्य कसे कार्य करते हे पाहण्यासाठी तुम्हाला क्लास फाइल्सचा अधिक अभ्यास करणे आवश्यक आहे. सर्वात वर, प्रत्येक वर्ग एक लहान मॉड्यूल आहे जो कमीतकमी इतरांशी संबंधित असावा. हे पृथक्करण वर्गात अतिरिक्त तर्क जोडताना आम्हाला आवश्यक असलेल्या बदलांची संख्या कमी करते. प्रत्येक पद्धत त्यांपैकी एक किंवा काहींसोबत कार्य करते, ज्यामुळे वर्गामध्ये खूप एकसंधता निर्माण होते (जे अगदी तसे असले पाहिजे, कारण वर्ग एकसंध असावा). परिणामी, वर्गाची एकसंधता वाढल्याने वर्गाचा आकार कमी होतो आणि अर्थातच वर्गांची संख्या वाढते. काही लोकांसाठी हे त्रासदायक आहे, कारण एखादे मोठे कार्य कसे कार्य करते हे पाहण्यासाठी तुम्हाला क्लास फाइल्सचा अधिक अभ्यास करणे आवश्यक आहे. सर्वात वर, प्रत्येक वर्ग एक लहान मॉड्यूल आहे जो कमीतकमी इतरांशी संबंधित असावा. हे पृथक्करण वर्गात अतिरिक्त तर्क जोडताना आम्हाला आवश्यक असलेल्या बदलांची संख्या कमी करते. s एकसंधतेमुळे वर्गाचा आकार कमी होतो आणि अर्थातच वर्गांची संख्या वाढते. काही लोकांसाठी हे त्रासदायक आहे, कारण एखादे मोठे कार्य कसे कार्य करते हे पाहण्यासाठी तुम्हाला क्लास फाइल्सचा अधिक अभ्यास करणे आवश्यक आहे. सर्वात वर, प्रत्येक वर्ग एक लहान मॉड्यूल आहे जो कमीतकमी इतरांशी संबंधित असावा. हे पृथक्करण वर्गात अतिरिक्त तर्क जोडताना आम्हाला आवश्यक असलेल्या बदलांची संख्या कमी करते. s एकसंधतेमुळे वर्गाचा आकार कमी होतो आणि अर्थातच वर्गांची संख्या वाढते. काही लोकांसाठी हे त्रासदायक आहे, कारण एखादे मोठे कार्य कसे कार्य करते हे पाहण्यासाठी तुम्हाला क्लास फाइल्सचा अधिक अभ्यास करणे आवश्यक आहे. सर्वात वर, प्रत्येक वर्ग एक लहान मॉड्यूल आहे जो कमीतकमी इतरांशी संबंधित असावा. हे पृथक्करण वर्गात अतिरिक्त तर्क जोडताना आम्हाला आवश्यक असलेल्या बदलांची संख्या कमी करते.

वस्तू

एन्कॅप्सुलेशन

येथे आपण प्रथम OOP तत्त्वाबद्दल बोलू: encapsulation. अंमलबजावणी लपविणे म्हणजे व्हेरिएबल्सचे इन्सुलेशन करण्याची पद्धत तयार करणे (विचार न करता वैयक्तिक पद्धती, गेटर्स आणि सेटर्सद्वारे प्रवेश प्रतिबंधित करणे, जे चांगले नाही, कारण एन्कॅप्सुलेशनचा संपूर्ण बिंदू गमावला आहे). अ‍ॅक्सेस लपविण्याचे उद्दिष्ट अ‍ॅब्स्ट्रॅक्शन तयार करणे आहे, म्हणजेच वर्ग सामायिक केलेल्या ठोस पद्धती प्रदान करतो ज्या आम्ही आमच्या डेटासह कार्य करण्यासाठी वापरतो. आणि वापरकर्त्याला हे माहित असणे आवश्यक नाही की आम्ही या डेटासह कसे कार्य करतो - ते कार्य करते आणि ते पुरेसे आहे.

डीमीटरचा कायदा

आम्ही डीमीटरचा कायदा देखील विचारात घेऊ शकतो: हा नियमांचा एक छोटा संच आहे जो वर्ग आणि पद्धती स्तरावर जटिलता व्यवस्थापित करण्यात मदत करतो. समजा आपल्याकडे एक कार ऑब्जेक्ट आहे आणि त्यात मूव्ह (ऑब्जेक्ट आर्ग१, ऑब्जेक्ट आर्ग२) पद्धत आहे. डीमीटरच्या कायद्यानुसार, ही पद्धत कॉल करण्यापुरती मर्यादित आहे:

• स्वतः कार ऑब्जेक्टच्या पद्धती (दुसऱ्या शब्दात, "ही" ऑब्जेक्ट);
• हलवण्याच्या पद्धतीमध्ये तयार केलेल्या वस्तूंच्या पद्धती ;
• वितर्क म्हणून पास केलेल्या वस्तूंच्या पद्धती ( arg1 , arg2 );
• अंतर्गत कार वस्तूंच्या पद्धती (पुन्हा, "हे").

दुस-या शब्दात सांगायचे तर, डिमेटरचा कायदा असा आहे की पालक मुलास काय म्हणू शकतात: "तुम्ही तुमच्या मित्रांशी बोलू शकता, परंतु अनोळखी लोकांशी नाही".

डेटा संरचना

डेटा स्ट्रक्चर म्हणजे संबंधित घटकांचा संग्रह. डेटा संरचना म्हणून ऑब्जेक्टचा विचार करताना, डेटा घटकांचा एक संच असतो ज्यावर पद्धती कार्य करतात. या पद्धतींचे अस्तित्व अस्पष्टपणे गृहीत धरले जाते. म्हणजेच, डेटा स्ट्रक्चर म्हणजे एक ऑब्जेक्ट ज्याचा उद्देश संग्रहित डेटा संग्रहित करणे आणि त्यावर कार्य करणे (प्रक्रिया) करणे आहे. नियमित ऑब्जेक्टपासून त्याचा महत्त्वाचा फरक असा आहे की सामान्य ऑब्जेक्ट म्हणजे अशा पद्धतींचा संग्रह आहे जो डेटा घटकांवर कार्य करतो जे अस्पष्टपणे अस्तित्वात असल्याचे गृहित धरले जाते. समजलं का? सामान्य वस्तूचा मुख्य पैलू म्हणजे पद्धती. अंतर्गत व्हेरिएबल्स त्यांचे योग्य ऑपरेशन सुलभ करतात. परंतु डेटा स्ट्रक्चरमध्ये, संग्रहित डेटा घटकांसह आपल्या कार्यास समर्थन देण्यासाठी पद्धती आहेत, जे येथे सर्वोपरि आहेत. डेटा स्ट्रक्चरचा एक प्रकार म्हणजे डेटा ट्रान्सफर ऑब्जेक्ट (DTO). हा पब्लिक व्हेरिएबल्स असलेला वर्ग आहे आणि कोणत्याही पद्धती (किंवा केवळ वाचन/लेखनासाठी पद्धती) नाही ज्याचा वापर डेटाबेससह कार्य करताना, सॉकेट्समधून संदेश पार्स करणे इ. डेटा हस्तांतरित करण्यासाठी केला जातो. डेटा सहसा अशा वस्तूंमध्ये दीर्घ कालावधीसाठी संग्रहित केला जात नाही. आमचा ऍप्लिकेशन ज्या प्रकारात काम करतो त्या प्रकारात ते जवळजवळ लगेच रूपांतरित होते. एक घटक, यामधून, एक डेटा संरचना देखील आहे, परंतु त्याचा उद्देश अनुप्रयोगाच्या विविध स्तरांवर व्यवसाय तर्कामध्ये भाग घेणे आहे. डीटीओचा उद्देश अनुप्रयोगात/वरून डेटा वाहतूक करणे आहे. डीटीओचे उदाहरण: डेटा स्ट्रक्चर देखील आहे, परंतु त्याचा उद्देश अनुप्रयोगाच्या विविध स्तरांवर व्यवसाय तर्कामध्ये भाग घेणे आहे. डीटीओचा उद्देश अनुप्रयोगात/वरून डेटा वाहतूक करणे आहे. डीटीओचे उदाहरण: डेटा स्ट्रक्चर देखील आहे, परंतु त्याचा उद्देश अनुप्रयोगाच्या विविध स्तरांवर व्यवसाय तर्कामध्ये भाग घेणे आहे. डीटीओचा उद्देश अनुप्रयोगात/वरून डेटा वाहतूक करणे आहे. डीटीओचे उदाहरण:

@Setter
@Getter
@NoArgsConstructor
public class UserDto {
    private long id;
    private String firstName;
    private String lastName;
    private String email;
    private String password;
}

सर्व काही पुरेसे स्पष्ट दिसते, परंतु येथे आपण संकरांच्या अस्तित्वाबद्दल शिकतो. हायब्रीड्स अशा वस्तू आहेत ज्यात महत्त्वाचे तर्क हाताळण्यासाठी पद्धती आहेत, अंतर्गत घटक संग्रहित करतात आणि ऍक्सेसर (गेट/सेट) पद्धती देखील समाविष्ट आहेत. अशा वस्तू गोंधळलेल्या असतात आणि नवीन पद्धती जोडणे कठीण करतात. तुम्ही ते टाळले पाहिजे, कारण ते कशासाठी आहेत हे स्पष्ट नाही — घटक साठवायचे की तर्क चालवायचे?

व्हेरिएबल्स तयार करण्याचे सिद्धांत

चल बद्दल थोडे विचार करूया. अधिक विशिष्टपणे, ते तयार करताना कोणती तत्त्वे लागू होतात याचा विचार करूया:

1. तद्वतच, तुम्ही व्हेरिएबल वापरण्यापूर्वी ते घोषित आणि आरंभ केले पाहिजे (एक तयार करू नका आणि त्याबद्दल विसरू नका).
2. जेव्हा शक्य असेल तेव्हा, व्हेरिएबल्सचे मूल्य इनिशिएलायझेशननंतर बदलण्यापासून रोखण्यासाठी अंतिम म्हणून घोषित करा.
3. काउंटर व्हेरिएबल्स बद्दल विसरू नका, जे आपण सहसा काही प्रकारच्या फॉर लूपमध्ये वापरतो. म्हणजेच, त्यांना शून्य करणे विसरू नका. अन्यथा, आपले सर्व तर्क खंडित होऊ शकतात.
4. तुम्ही कन्स्ट्रक्टरमध्ये व्हेरिएबल्स सुरू करण्याचा प्रयत्न केला पाहिजे.
5. संदर्भासह किंवा ( नवीन SomeObject() शिवाय ऑब्जेक्ट वापरणे यामधील पर्याय असल्यास, त्याशिवाय पर्याय निवडा, कारण ऑब्जेक्ट वापरल्यानंतर तो पुढील कचरा संकलन चक्रात हटविला जाईल आणि त्याची संसाधने वाया जाणार नाहीत.
6. व्हेरिएबलचे आयुष्यमान (व्हेरिएबलची निर्मिती आणि शेवटच्या वेळी संदर्भ दिलेले अंतर) शक्य तितके लहान ठेवा.
7. लूपमध्ये वापरलेले व्हेरिएबल्स लूपच्या आधी सुरू करा, लूप असलेल्या पद्धतीच्या सुरुवातीला नाही.
8. नेहमी सर्वात मर्यादित व्याप्तीसह प्रारंभ करा आणि आवश्यक असेल तेव्हाच विस्तार करा (आपण शक्य तितके स्थानिक व्हेरिएबल बनवण्याचा प्रयत्न केला पाहिजे).
9. प्रत्येक व्हेरिएबल फक्त एका उद्देशासाठी वापरा.
10. छुप्या उद्देशाने व्हेरिएबल्स टाळा, उदा. दोन टास्कमध्ये व्हेरिएबल स्प्लिट — याचा अर्थ त्याचा प्रकार त्यापैकी एक सोडवण्यासाठी योग्य नाही.

पद्धती

"स्टार वॉर्स: एपिसोड III - रिव्हेंज ऑफ द सिथ" (2005) या चित्रपटातील

चला थेट आपल्या तर्कशास्त्राच्या अंमलबजावणीकडे जाऊया, म्हणजे पद्धतींकडे.

1. नियम # 1 - कॉम्पॅक्टनेस. आदर्शपणे, एक पद्धत 20 ओळींपेक्षा जास्त नसावी. याचा अर्थ असा की जर एखादी सार्वजनिक पद्धत लक्षणीयरीत्या "फुगली" तर, तुम्हाला तर्कशास्त्र तोडून वेगळ्या खाजगी पद्धतींमध्ये हलवण्याचा विचार करणे आवश्यक आहे.

2. नियम #2 — if , else , while आणि इतर स्टेटमेंट्समध्ये जोरदारपणे नेस्टेड ब्लॉक्स नसावेत: बरेच नेस्टिंग कोडची वाचनीयता लक्षणीयरीत्या कमी करते. आदर्शपणे, तुमच्याकडे दोन नेस्टेड {} ब्लॉक्सपेक्षा जास्त नसावेत .

   आणि या ब्लॉक्समधील कोड कॉम्पॅक्ट आणि साधे ठेवणे देखील इष्ट आहे.

3. नियम #3 - पद्धतीने फक्त एकच ऑपरेशन केले पाहिजे. म्हणजेच, जर एखादी पद्धत सर्व प्रकारचे जटिल तर्कशास्त्र करते, तर आम्ही ती उपपद्धतींमध्ये मोडतो. परिणामी, पद्धत स्वतःच एक दर्शनी भाग असेल ज्याचा उद्देश इतर सर्व ऑपरेशन्स योग्य क्रमाने कॉल करणे आहे.

   पण ऑपरेशन वेगळ्या पद्धतीत टाकणे खूप सोपे वाटत असेल तर? खरे आहे, कधीकधी चिमण्यांवर तोफ डागल्यासारखे वाटू शकते, परंतु लहान पद्धती अनेक फायदे देतात:

   • चांगले कोड आकलन;
   • विकास जसजसा वाढत जातो तसतसे पद्धती अधिक जटिल होत जातात. जर एखादी पद्धत सुरुवातीस सोपी असेल, तर तिची कार्यक्षमता क्लिष्ट करणे थोडे सोपे होईल;
   • अंमलबजावणी तपशील लपलेले आहेत;
   • सोपे कोड पुन्हा वापर;
   • अधिक विश्वासार्ह कोड.

4. स्टेपडाउन नियम — कोड वरपासून खालपर्यंत वाचला पाहिजे: तुम्ही जितके कमी वाचाल तितके तुम्ही तर्कशास्त्रात खोलवर जाल. आणि त्याउलट, तुम्ही जितके वर जाल तितक्या अधिक अमूर्त पद्धती. उदाहरणार्थ, स्विच स्टेटमेंट्स नॉन-कॉम्पॅक्ट आणि अवांछनीय आहेत, परंतु जर तुम्ही स्विच वापरणे टाळू शकत नसाल, तर तुम्ही ते शक्य तितक्या खालच्या स्तरावर हलवण्याचा प्रयत्न केला पाहिजे.

5. पद्धत युक्तिवाद - आदर्श संख्या काय आहे? तद्वतच, अजिबात नाही :) पण खरंच असं घडतं का? ते म्हणाले, तुम्ही शक्य तितक्या कमी युक्तिवाद करण्याचा प्रयत्न केला पाहिजे, कारण तेथे जितके कमी असतील तितकी पद्धत वापरणे सोपे आहे आणि त्याची चाचणी घेणे तितके सोपे आहे. शंका असल्यास, मोठ्या संख्येने इनपुट पॅरामीटर्ससह पद्धत वापरण्यासाठी सर्व परिस्थितींचा अंदाज घेण्याचा प्रयत्न करा.

6. याव्यतिरिक्त, इनपुट पॅरामीटर म्हणून बुलियन ध्वज असलेल्या पद्धतींना वेगळे करणे चांगले होईल, कारण हे सर्व स्वतःच सूचित करते की पद्धत एकापेक्षा जास्त ऑपरेशन करते (जर खरे असेल, तर एक गोष्ट करा; खोटे असल्यास दुसरी करा). मी वर लिहिल्याप्रमाणे, हे चांगले नाही आणि शक्य असल्यास टाळले पाहिजे.

7. जर एखाद्या पद्धतीमध्ये मोठ्या संख्येने इनपुट पॅरामीटर्स असतील (एक टोक 7 आहे, परंतु तुम्ही 2-3 नंतर विचार करायला सुरुवात केली पाहिजे), काही युक्तिवाद वेगळ्या ऑब्जेक्टमध्ये गटबद्ध केले पाहिजेत.

8. जर अनेक समान (ओव्हरलोड) पद्धती असतील, तर समान पॅरामीटर्स त्याच क्रमाने पास करणे आवश्यक आहे: यामुळे वाचनीयता आणि उपयोगिता सुधारते.

9. जेव्हा तुम्ही एखाद्या पद्धतीमध्ये पॅरामीटर्स पास करता तेव्हा तुम्हाला खात्री असणे आवश्यक आहे की ते सर्व वापरले आहेत, अन्यथा तुम्हाला त्यांची आवश्यकता का आहे? इंटरफेसमधून कोणतेही न वापरलेले पॅरामीटर्स कापून टाका आणि ते पूर्ण करा.

10. ट्राय/कॅच निसर्गात फार छान दिसत नाही, त्यामुळे वेगळ्या इंटरमीडिएट पद्धतीमध्ये (अपवाद हाताळण्याची पद्धत) हलवणे चांगली कल्पना असेल:

    
    public void exceptionHandling(SomeObject obj) {
        try {  
            someMethod(obj);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    

मी वरील डुप्लिकेट कोडबद्दल बोललो, परंतु मी पुन्हा एकदा पुनरावृत्ती करू: आमच्याकडे पुनरावृत्ती कोड असलेल्या काही पद्धती असल्यास, आम्हाला ते वेगळ्या पद्धतीमध्ये हलवावे लागेल. हे पद्धत आणि वर्ग दोन्ही अधिक संक्षिप्त करेल. नावे नियंत्रित करणार्‍या नियमांबद्दल विसरू नका: वर्ग, इंटरफेस, पद्धती आणि व्हेरिएबल्स यांना योग्यरित्या नाव कसे द्यावे यावरील तपशील लेखाच्या पुढील भागात चर्चा केली जाईल. पण आज माझ्याकडे तुझ्यासाठी एवढेच आहे.