Android पर स्वच्छ कोड को समझना

एक परिचय के रूप में, मैं अंकल बॉब के उद्धरण को याद करना चाहूंगा

आप इस लेख को दो कारणों से पढ़ रहे हैं। पहला - आप एक प्रोग्रामर हैं, दूसरा - आप सबसे अच्छा प्रोग्रामर बनना चाहते हैं।

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

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

क्लीन कोड क्या है?

जैसा कि आप देख सकते हैं, यह तेजी से विकास को पूरा करने के लिए पर्याप्त नहीं है। यदि भविष्य में वे इस कोड का पता नहीं लगा सकते हैं, तो यह एक तकनीकी ऋण भी बन जाएगा।

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

क्या मुझे इसका ध्यान रखना चाहिए?

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

स्वच्छ संहिता के संकेत

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

एक अच्छे प्रोग्रामर और पेशेवर के बीच का अंतर यह है कि एक पेशेवर प्रोग्रामर समझता है कि कोड की समझ सर्वोपरि है। एक पेशेवर इस शक्ति का उपयोग कोड लिखने के लिए करता है जिसे हर कोई समझता है - रॉबर्ट सी। मार्टिन

चेतन नाम लिखिए

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

सरल उदाहरण है

// Bad variables naming var a = 0 // user ages var w = 0 // user weight var h = 0 // user height // Bad functions naming fun age() fun weight() fun height() // Bad classes naming to get user data class UserInfo() // Best practices varibales naming var userAge = 0 var userWeight = 0 var userHeight = 0 // Best practices functions naming fun setUserAge() fun setUserWeight() fun setUserHeight() // Best practices classes naming to get user data class Users() 

वर्ग के नाम

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

विधि नाम

विधि के नाम क्रिया होने चाहिए, उदाहरण के लिए पोस्टपेमेंट, डिलीटपेज या सेव। एक्सेस मॉडिफ़ायर, विधेय का नाम उनके मूल्य से और उपसर्ग मिल के साथ, सेट और JavaBean मानक के अनुसार होना चाहिए।

इससे पहले कि हम जारी रखें, एक छोटा ब्रेक लें, कॉफी और कुकीज़ पर स्टॉक करें।



ठीक है, अब हम SOLID सिद्धांतों पर चलते हैं।

SOLID सिद्धांतों का पालन करने वाला कोड लिखें

ये सिद्धांत अंकल बॉब द्वारा विकसित किए गए थे, एसओएलआईडी एक संक्षिप्त नाम है जो अच्छे कोड लिखने के लिए डिज़ाइन किए गए सिद्धांतों के एक सेट का वर्णन करता है।

एकल जिम्मेदारी सिद्धांत (एस)

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

एक उदाहरण:

हमारे पास RecyclerView.Adcape है जिसमें ऑनर बिजनेस लॉजिक ऑन बिंड व्यू व्यूबोर्ड है

 class MyAdapter(val friendList: List<FriendListData.Friend>) : RecyclerView.Adapter<CountryAdapter.MyViewHolder>() { inner class MyViewHolder(view: View) : RecyclerView.ViewHolder(view) { var name: TextView = view.findViewById(R.id.text1) var popText: TextView = view.findViewById(R.id.text2) } override fun onBindViewHolder(holder: MyViewHolder, position: Int) { val friend = friendList[position] val status = if(friend.maritalStatus == "Married") { "Sold out" } else { "Available" } holder.name.text = friend.name holder.popText.text = friend.email holder.status.text = status } override fun getItemCount(): Int { return friendList.size } override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): MyViewHolder { val view = LayoutInflater.from(parent.context).inflate(R.layout.item_friendlist, parent, false) return MyViewHolder(view) } } 

यह RecyclerView.Adcape को पूरी तरह से ज़िम्मेदार नहीं बनाता है क्योंकि इसमें onBindViewHolder के अंदर व्यावसायिक तर्क होते हैं। यह विधि केवल दृश्य में डेटा सम्मिलित करने के लिए ज़िम्मेदार है।

खुलेपन / बंद करने का सिद्धांत (O)

सॉफ्टवेयर इकाइयां विस्तार के लिए खुली होनी चाहिए, लेकिन संशोधन के लिए बंद। इसका मतलब है कि यदि आप कक्षा ए विकसित कर रहे हैं और आपके सहयोगी इस कक्षा के अंदर फ़ंक्शन बदलना चाहते हैं। इस वर्ग का विस्तार किए बिना वे स्वयं को आसानी से बदल सकते हैं।
एक सरल उदाहरण RecyclerView.Adcape क्लास है। आप आसानी से इसका विस्तार कर सकते हैं और अपने स्वयं के एडेप्टर को बिना RecyclerView.Adcape को संशोधित किए बिना गैर-मानक व्यवहार के साथ बना सकते हैं।

 class FriendListAdapter(val friendList: List<FriendListData.Friend>) : RecyclerView.Adapter<CountryAdapter.MyViewHolder>() { inner class MyViewHolder(view: View) : RecyclerView.ViewHolder(view) { var name: TextView = view.findViewById(R.id.text1) var popText: TextView = view.findViewById(R.id.text2) } override fun onBindViewHolder(holder: MyViewHolder, position: Int) { val friend = friendList[position] holder.name.text = friend.name holder.popText.text = friend.email } override fun getItemCount(): Int { return friendList.size } override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): MyViewHolder { val view = LayoutInflater.from(parent.context).inflate(R.layout.item_friendlist, parent, false) return MyViewHolder(view) } } 

बारबरा लिस्क प्रतिस्थापन सिद्धांत (L)

बाल वर्ग को माता-पिता का पूरक होना चाहिए, न कि उसे बदलना चाहिए। इसका मतलब यह है कि उपवर्ग उन मूल तरीकों को ओवरराइड करना चाहिए जो इस मूल वर्ग की कार्यक्षमता का उल्लंघन नहीं करते हैं। उदाहरण के लिए, हम एक वर्ग इंटरफ़ेस बनाते हैं जिसमें एक onClick () श्रोता होता है और फिर आप श्रोता को MyActivity में लागू करते हैं और जब उसे onClick () कहा जाता है तो उसे टोस्ट क्रिया देते हैं।

 interface ClickListener { fun onClick() } class MyActivity: AppCompatActivity(), ClickListener { //........ override fun onClick() { // Do the magic here toast("OK button clicked") } } 

इंटरफ़ेस जुदाई सिद्धांत

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

उदाहरण: हमारी गतिविधि में, हमें SearchView.OnQueryTextListener () को लागू करने की आवश्यकता है, लेकिन हमें केवल onQuerySubmit () विधि की आवश्यकता है।

 mSearchView.setOnQueryTextListener(object : SearchView.OnQueryTextListener{ override fun onQueryTextSubmit(query: String?): Boolean { // Only need this method return true } override fun onQueryTextChange(query: String?): Boolean { // We don't need to implement this method return false } }) 

हम यह कैसे करते हैं? आराम से! बस कॉलबैक बनाएं और SearchView.OnQueryTextListener () का विस्तार करने वाला एक वर्ग बनाएं

 interface SearchViewQueryTextCallback { fun onQueryTextSubmit(query: String?) } class SearchViewQueryTextListener(val callback: SearchViewQueryTextCallback): SearchView.OnQueryTextListener { override fun onQueryTextSubmit(query: String?): Boolean { callback.onQueryTextSubmit(query) return true } override fun onQueryTextChange(query: String?): Boolean { return false } } 

और इसलिए हम इसे अपने विचार से जोड़ते हैं

 val listener = SearchViewQueryTextListener( object : SearchViewQueryTextCallback { override fun onQueryTextSubmit(query: String?) { // Do the magic here } } ) mSearchView.setOnQueryTextListener(listener) 

या इसलिए कोटलिन में एक्सटेंशन फंक्शन का उपयोग करना

 interface SearchViewQueryTextCallback { fun onQueryTextSubmit(query: String?) } fun SearchView.setupQueryTextSubmit (callback: SearchViewQueryTextCallback) { setOnQueryTextListener(object : SearchView.OnQueryTextListener{ override fun onQueryTextSubmit(query: String?): Boolean { callback.onQueryTextSubmit(query) return true } override fun onQueryTextChange(query: String?): Boolean { return false } }) } 

 val listener = object : SearchViewQueryTextCallback { override fun onQueryTextSubmit(query: String?) { // Do the magic here } } mSearchView.setupQueryTextSubmit(listener) 

निर्भरता उलटा सिद्धांत

कुछ विशेष पर निर्भरता के बिना, अमूर्तता पर निर्भरता।
चाचा बॉब पर निर्भरता के उलटा की परिभाषा में दो अवधारणाएं हैं।

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

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

आइए एक उदाहरण देखें

 interface UserActionListener { fun getUserData() } class UserPresenter : UserActionListener() { // ..... override fun getUserData() { val userLoginData = gson.fromJson(session.getUserLogin(), DataLogin::class.java) } // ..... } 

और अब गतिविधि पर

 class UserActivity : AppCompatActivity() { //..... val presenter = UserPresenter() override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // Activity doesn't need to know how presenter works // for fetching data, it just know how to call the functions // So, if you add method inside presenter, it won't break the UI. // even the UI doesn't call the method. presenter.getUserData() } //.... } 

इस तरह, हम एक इंटरफ़ेस बनाते हैं जो प्रस्तुतकर्ता के कार्यान्वयन को सार करता है, और हमारा दृश्य वर्ग प्रस्तुतकर्ताइंटरफेस के संदर्भ को बनाए रखता है।