सॉफ्टवेअर प्रोग्रामिंगचा काही अनुभव असलेला कोणीही आपल्या करिअरच्या मार्गावर आधारित न्यायाधीश पॅरामीटर्स वापरुन, इतरांनी लिहिलेला सॉफ्टवेअर कोड न्यायाधीश करतो.
माझ्या व्यावसायिक कारकिर्दीत मी बर्‍याच विकसकांना ओळखतो आणि मी कोड्यांच्या हजारो ओळी पाहिल्या आहेत आणि जेव्हा विकसकाच्या कौशल्याचे मूल्यांकन करण्याची आवश्यकता असते तेव्हा मी मुख्यतः दोन घटकांकडे पाहतो:
सुदैवाने, अशी काही मूलभूत तत्त्वे किंवा तत्त्वे आहेत जी कोडींगमध्ये अधिक सुलभ बनवतात.
परिवर्णी शब्द SOLID याचा अर्थ:
S: एकच जबाबदारी तत्त्व
O: मुक्त-बंद तत्त्व
L: लिस्कोव्ह बदलण्याचे तत्व
I: इंटरफेस वेगळा करण्याचे तत्व
D: अवलंबित्व उलटा करण्याचे सिद्धांत
प्रथम SOLID तत्त्व म्हणजेच
वर्ग (किंवा विभाग) विकसित होण्यासाठी फक्त बदलण्याचे एक कारण असू शकते.
संकल्पना स्वतःच अगदी सोपी आहे, परंतु ही साधेपणा साध्य करण्यासाठी अंमलबजावणीचा मार्ग खूप क्लिष्ट होऊ शकतो. वर्ग बदलण्यासाठी फक्त एकच कारण असावे.
पण का?
फक्त एकच कारण बदलण्याचे कारण इतके महत्वाचे का आहे?
उदाहरणार्थ, बदलण्याकरिता दोन भिन्न कारणे असल्यास, दोन भिन्न कार्यसंघ दोन भिन्न कारणांमुळे समान कोडवर कार्य करू शकतात हे समजण्यासारखे आहे. प्रत्येकाला त्यांचे स्वतःचे निराकरण अंमलात आणावे लागेल, जे संकलित भाषेच्या बाबतीत (जसे की सी ++, सी # किंवा जावा) मोड्यूल्स होऊ शकते जे इतर कार्यसंघ किंवा अनुप्रयोगाच्या इतर भागांशी विसंगत आहेत.
दुसरे उदाहरण, जर आपण दुभाषित भाषा वापरत असाल तर आपल्याला वेगवेगळ्या कारणांसाठी समान वर्ग किंवा मॉड्यूलची परीक्षा घ्यावी लागेल. यात गुणवत्ता नियंत्रणासाठी अधिक काम, वेळ आणि प्रयत्न यांचा समावेश आहे.
वर्ग किंवा मॉड्यूलचे एक वैशिष्ट्य ओळखणे केवळ चाचण्या चालविण्यासाठी चेकलिस्टकडे पाहण्यापेक्षा बरेच अवघड आहे.
परंतु आपण अगदी कमी तांत्रिक दृष्टिकोनातून विचार करण्याचा प्रयत्न करूया, म्हणजे आपल्या वर्ग किंवा मॉड्यूलच्या वापरकर्त्याचे विश्लेषण करण्याचा प्रयत्न करूया, तोच याचा उपयोग कोण करेल. एक मूलभूत पैलू जी आपण नेहमी लक्षात ठेवली पाहिजे, ती म्हणजे आपण विकसित केलेला अनुप्रयोग किंवा सिस्टम ज्या विशिष्ट मॉड्यूलद्वारे सेवा दिली आहेत त्यांचे वापरकर्ते त्यामध्ये बदल करण्याची विनंती करणारे असतील. ते दिलेला वर्ग किंवा विभाग बदलण्यास सांगेल.
मॉड्यूल आणि त्यांच्या वापराची काही उदाहरणे:
म्हणून जर पहिला चरण मॉड्यूलमध्ये संवाद साधणार्‍याची भूमिका असणारा अभिनेता किंवा अभिनेता शोधणे असेल तर, सर्व भूमिकांमध्ये व्यक्तींना जोडणे कठीण आहे. एका छोट्या कंपनीत एक व्यक्ती एकाधिक भूमिका निभावू शकते तर मोठ्या कंपनीत एक भूमिका असणारे अनेक लोक असू शकतात.
लोक किंवा वापरकर्त्यांऐवजी भूमिका ओळखणे अधिक वाजवी वाटते.
म्हणून:
चला काही उदाहरणे पाहूया
समजा आपल्याकडे एखादा बुक क्लास आहे जो पुस्तकाची संकल्पना आणि त्याची कार्यक्षमता समेटित करतो.
वर्ग पुस्तक {
फंक्शन getTitle () {
“एक उत्तम पुस्तक” परत;
}
फंक्शन getAuthor () {
“अ‍ॅलेसॅन्ड्रो बॅरिको” परत करा;
}
कार्य पुढील पृष्ठ () {
// पुढील पृष्ठ
}
फंक्शन प्रिंटकंटरपेज () {
एको “वर्तमान पृष्ठाची सामग्री”;
}
}
हा एक अतिशय सामान्य वर्ग आहे. आमच्याकडे एक पुस्तक आहे, आणि वर्ग आम्हाला शीर्षक देऊ शकेल, ते आम्हाला लेखक देऊ शकतात आणि ते पुढे जाऊ शकतात. शेवटी, ते वर्तमान पृष्ठ स्क्रीनवर मुद्रित करण्यास देखील सक्षम आहे.
तथापि, एक छोटी समस्या आहे.
बुक ऑब्जेक्टच्या व्यवस्थापनात गुंतलेल्या कलाकारांबद्दल विचार करता, ते कोण असू शकतात?
आम्ही येथे दोन भिन्न कलाकारांचा सहज विचार करू शकतो: पुस्तक व्यवस्थापन (म्हणून ग्रंथपाल) आणि डेटा सबमिशन यंत्रणा (जसे की आम्ही वापरकर्त्यास सामग्री कशी वितरित करू इच्छितो: ऑन-स्क्रीन, ग्राफिकल यूजर इंटरफेस, मजकूर-केवळ वापरकर्ता इंटरफेस, कदाचित मुद्रण).
आमच्याकडे म्हणून दोन अतिशय भिन्न कलाकार वर्गात संवाद साधत आहेत.
थोडक्यात हा वर्ग यामध्ये मिसळतो:
ही समस्या असू शकते कारण ते सिंगल लायबिलिटी तत्त्व (एसआरपी) चे उल्लंघन करते.
एकल जबाबदारीच्या तत्त्वाचा आदर करण्यासाठी आपण ही संहिता कशी सुधारू शकतो?
पुढील कोड पहा:
वर्ग पुस्तक {
फंक्शन getTitle () {
"ओशिनो मारे" परत;
}
फंक्शन getAuthor () {
“अ‍ॅलेसॅन्ड्रो बॅरिको” परत करा;
}
फंक्शन टर्न पेज () {
// पुढील पृष्ठ
}
फंक्शन getCurrentPage () {
एको “वर्तमान पृष्ठाची सामग्री”;
}
}
इंटरफेस प्रिंटर
फंक्शन प्रिंटपेज ($ पृष्ठ);
}
क्लास स्टँपलाइब्रो प्रिंटरची अंमलबजावणी करते {
फंक्शन प्रिंटपेजेस ($ पृष्ठ) {
प्रतिध्वनी
}
}
वर्ग एचटीएमएलप्रिंटर प्रिंटर लागू करतो {
फंक्शन प्रिंटपेजेस ($ पृष्ठ) {
प्रतिध्वनी '. . पृष्ठ ' ';
}
}
हे अगदी सोप्या उदाहरणात दिसते की व्यवसायाच्या तार्किकतेपासून सादरीकरण कसे वेगळे करावे आणि एसआरपीच्या अनुपालनात हे आमच्या प्रकल्पाच्या लवचिकतेमध्ये चांगले फायदे देतात.
दुसरे उदाहरण पाहूया:
जेव्हा एखादी वस्तू स्वतःला सादरीकरणातून जतन आणि पुनर्प्राप्त करू शकते तेव्हा वरील प्रमाणेच एक उदाहरण आहे.
वर्ग पुस्तक {
फंक्शन getTitle () {
"ओशिनो मारे" परत;
}
फंक्शन getAuthor () {
“अ‍ॅलेसॅन्ड्रो बॅरिको” परत करा;
}
फंक्शन टर्न पेज () {
// पुढील पृष्ठ
}
फंक्शन getCurrentPage () {
"वर्तमान पृष्ठाची सामग्री" परत करा;
}
फंक्शन सेव्ह () {
$ फाइलनाव = '/ दस्तऐवज /'. $ हे-> getTitolo (). '-'. $ हे-> getAuthor ();
file_put_contents ($ फाइलनाव, अनुक्रमांक ($ हे));
}
}
पूर्वीप्रमाणेच येथेही आम्ही वेगवेगळ्या कलाकारांना ओळखू शकतो पुस्तक व्यवस्थापन (म्हणून ग्रंथपाल) आणि चिकाटी. जेव्हा जेव्हा आपल्याला पृष्ठावरून पृष्ठाकडे जाणारा मार्ग बदलायचा असतो तेव्हा आपल्याला हा वर्ग बदलण्याची आवश्यकता असते. आपल्याकडे परिवर्तनाची अनेक कारणे असू शकतात.
वर्ग पुस्तक {
फंक्शन getTitle () {
"ओशिनो मारे" परत;
}
फंक्शन getAuthor () {
“अ‍ॅलेसॅन्ड्रो बॅरिको” परत करा;
}
फंक्शन टर्न पेज () {
// पुढील पृष्ठ
}
फंक्शन getCurrentPage () {
"वर्तमान पृष्ठाची सामग्री" परत करा;
}
}
वर्ग सिंपलफाइलपर्सिटी {
फंक्शन सेव्ह (बुक $ बुक)
$ फाइलनाव = '/ दस्तऐवज /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();
file_put_contents ($ फाइलनाव, अनुक्रमांक ($ पुस्तक));
}
}
चिकाटी ऑपरेशन दुसर्‍या वर्गाकडे हलविण्यामुळे जबाबदा clearly्या स्पष्टपणे स्वतंत्र होतील आणि आम्ही आमच्या बुक वर्गावर परिणाम न करता चिकाटीच्या पद्धतींची देवाणघेवाण करण्यास मुक्त आहोत. उदाहरणार्थ, डेटाबेसपर्सिस्ट क्लासची अंमलबजावणी करणे क्षुल्लक असेल आणि बुक ऑपरेशन्सभोवती तयार केलेला आमचा व्यवसाय तर्क बदलणार नाही.
द्वितीय तत्व उघडा / बंद -> वाचून सुरू ठेवा
Ercole Palmeri
Veeam द्वारे Coveware सायबर खंडणी घटना प्रतिसाद सेवा प्रदान करणे सुरू ठेवेल. Coveware फॉरेन्सिक आणि उपाय क्षमता प्रदान करेल…
वनस्पती व्यवस्थापनासाठी नाविन्यपूर्ण आणि सक्रिय दृष्टीकोनसह, भविष्यसूचक देखभाल तेल आणि वायू क्षेत्रात क्रांती घडवत आहे.…
UK CMA ने आर्टिफिशियल इंटेलिजन्स मार्केटमध्ये बिग टेकच्या वर्तनाबद्दल चेतावणी जारी केली आहे. तेथे…
इमारतींची उर्जा कार्यक्षमता वाढविण्यासाठी युरोपियन युनियनने तयार केलेल्या "ग्रीन हाऊसेस" डिक्रीने त्याची वैधानिक प्रक्रिया पूर्ण केली आहे ...
