अनुप्रयोग विकास के लिए ठोस सिद्धांतों को लागू करना

हमने हाल ही में SOLID कार्यप्रणाली पर सामग्री प्रकाशित की है। आज हम आपके ध्यान में एक लेख का अनुवाद लाते हैं जो लोकप्रिय रिएक्ट लाइब्रेरी का उपयोग करके अनुप्रयोग विकास में SOLID सिद्धांतों के अनुप्रयोग को संबोधित करता है।



लेख के लेखक का कहना है कि यहां, संक्षिप्तता के लिए, वह कुछ घटकों के पूर्ण कार्यान्वयन को नहीं दिखाता है।

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

सिंगल रिस्पांसिबिलिटी सिद्धांत हमें बताता है कि एक मॉड्यूल में बदलाव का एक और एक ही कारण होना चाहिए।

कल्पना करें कि हम एक एप्लिकेशन विकसित कर रहे हैं जो एक तालिका में उपयोगकर्ताओं की सूची प्रदर्शित करता है। यहाँ App घटक के लिए कोड है:

 class App extends Component {   state = {       users: [{name: 'Jim', surname: 'Smith', age: 33}]   };   componentDidMount() {       this.fetchUsers();   }   async fetchUsers() {       const response = await fetch('http://totallyhardcodedurl.com/users');       const users = await response.json();       this.setState({users});   }   render() {       return (           <div className="App">               <header className="App-header">                 //                     </header>               <table>                   <thead>                       <tr>                           <th>First name</th>                           <th>Last name</th>                           <th>Age</th>                       </tr>                   </thead>                   <tbody>                       {this.state.users.map((user, index) => (                           <tr key={index}>                               <td><input value={user.name} onChange={/* update name in the state */}/></td>                               <td><input value={user.surname} onChange={/* update surname in the state*/}/></td>                               <td><input value={user.age} onChange={/* update age in the state */}/></td>                           </tr>                       ))}                   </tbody>               </table>               <button onClick={() => this.saveUsersOnTheBackend()}>Save</button>           </div>       );   }   saveUsersOnTheBackend(row) {       fetch('http://totallyhardcodedurl.com/users', {           method: "POST",           body: JSON.stringify(this.state.users),       })   } } 

हमारे पास एक ऐसी स्थिति है जिसमें उपयोगकर्ताओं की सूची संग्रहीत है। हम एक निश्चित सर्वर से HTTP के माध्यम से इस सूची को डाउनलोड करते हैं; सूची संपादन योग्य है। हमारा घटक एकमात्र जिम्मेदारी के सिद्धांत का उल्लंघन करता है, क्योंकि इसमें बदलाव का एक से अधिक कारण है।

विशेष रूप से, मैं एक घटक को बदलने के चार कारण देख सकता हूं। अर्थात्, घटक निम्नलिखित मामलों में बदलता है:

• हर बार आपको एप्लिकेशन शीर्षक बदलने की आवश्यकता होती है।
• हर बार आपको एप्लिकेशन में एक नया घटक जोड़ने की आवश्यकता होती है (उदाहरण के लिए पृष्ठ पाद लेख)।
• हर बार आपको उपयोगकर्ता डेटा लोड करने के लिए तंत्र को बदलना होगा, उदाहरण के लिए, सर्वर एड्रेस या प्रोटोकॉल।
• हर बार आपको तालिका बदलने की आवश्यकता होती है (उदाहरण के लिए, स्तंभों का स्वरूप बदलना या इस तरह की कुछ अन्य क्रियाएं करना)।

इन समस्याओं को कैसे हल करें? यह आवश्यक है कि घटक को बदलने के कारणों की पहचान करने के बाद, उन्हें खत्म करने की कोशिश करें, मूल घटक से कटौती करने के लिए, ऐसे प्रत्येक कारण के लिए उपयुक्त सार (घटकों या कार्यों) का निर्माण करें।

हम अपने App घटक की समस्याओं को हल करके इसे हल करेंगे। इसका कोड, इसे कई घटकों में तोड़ने के बाद, इस तरह दिखेगा:

 class App extends Component {   render() {       return (           <div className="App">               <Header/>               <UserList/>           </div>       );   } } 

अब, यदि आपको शीर्षक बदलने की आवश्यकता है, तो हम Header घटक को बदलते हैं, और यदि आपको एप्लिकेशन में एक नया घटक जोड़ने की आवश्यकता है, तो हम App घटक को बदलते हैं। यहां हमने समस्याओं को हल किया नंबर 1 (आवेदन के हेडर को बदलकर) और समस्या नंबर 2 (एप्लिकेशन में एक नया घटक जोड़कर)। यह App घटक से संबंधित तर्क को नए घटकों में स्थानांतरित करके किया जाता है।

अब हम UserList वर्ग बनाकर समस्याओं नंबर 3 और नंबर 4 को हल करेंगे। यहाँ उसका कोड है:

 class UserList extends Component {   static propTypes = {       fetchUsers: PropTypes.func.isRequired,       saveUsers: PropTypes.func.isRequired   };   state = {       users: [{name: 'Jim', surname: 'Smith', age: 33}]   };   componentDidMount() {       const users = this.props.fetchUsers();       this.setState({users});   }   render() {       return (           <div>               <UserTable users={this.state.users} onUserChange={(user) => this.updateUser(user)}/>               <button onClick={() => this.saveUsers()}>Save</button>           </div>       );   }   updateUser(user) {     //         }   saveUsers(row) {       this.props.saveUsers(this.state.users);   } } 

UserList हमारा नया कंटेनर घटक है। उसके लिए धन्यवाद, हमने fetchUser और saveUser संपत्ति saveUser को बनाकर समस्या नंबर 3 (उपयोगकर्ता लोडिंग तंत्र को बदलते हुए) को fetchUser । परिणामस्वरूप, अब जब हमें उपयोगकर्ताओं की सूची लोड करने के लिए उपयोग किए जाने वाले लिंक को बदलने की आवश्यकता है, तो हम संबंधित फ़ंक्शन की ओर मुड़ते हैं और उसमें परिवर्तन करते हैं।

अंतिम समस्या जो हमारे पास नंबर 4 पर है (तालिका जो उपयोगकर्ताओं की सूची को प्रदर्शित करती है) को उपयोगकर्ताटेबल प्रस्तुति घटक को परियोजना में पेश करके हल किया गया है, जो HTML कोड के गठन को UserTable और उपयोगकर्ताओं के साथ तालिका को स्टाइल करता है।

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

ओपन क्लोज्ड सिद्धांत बताता है कि विस्तार के लिए प्रोग्राम इकाइयां (कक्षाएं, मॉड्यूल, फ़ंक्शन) खुली होनी चाहिए, लेकिन संशोधन के लिए नहीं।

यदि आप ऊपर वर्णित UserList घटक को देखते हैं, तो आप देखेंगे कि यदि आपको उपयोगकर्ताओं की सूची को एक अलग प्रारूप में प्रदर्शित करने की आवश्यकता है, तो हमें इस घटक की render विधि को संशोधित करना होगा। यह खुलेपन-घनिष्ठता के सिद्धांत का उल्लंघन है।

आप घटकों की संरचना का उपयोग करके इस सिद्धांत के अनुरूप कार्यक्रम ला सकते हैं।

उपयोगकर्ता के घटक के कोड पर एक नज़र डालें, जिसे हटा दिया गया है:

 export class UserList extends Component {   static propTypes = {       fetchUsers: PropTypes.func.isRequired,       saveUsers: PropTypes.func.isRequired   };   state = {       users: [{id: 1, name: 'Jim', surname: 'Smith', age: 33}]   };   componentDidMount() {       const users = this.props.fetchUsers();       this.setState({users});   }   render() {       return (           <div>               {this.props.children({                   users: this.state.users,                   saveUsers: this.saveUsers,                   onUserChange: this.onUserChange               })}           </div>       );   }   saveUsers = () => {       this.props.saveUsers(this.state.users);   };   onUserChange = (user) => {       //         }; } 

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

अब देखते हैं कि कैसे, नए घटक का उपयोग करके, उपयोगकर्ताओं की एक सूची प्रदर्शित की जाती है।

 export class PopulatedUserList extends Component {   render() {       return (           <div>               <UserList>{                   ({users}) => {                       return <ul>                           {users.map((user, index) => <li key={index}>{user.id}: {user.name} {user.surname}</li>)}                       </ul>                   }               }               </UserList>           </div>       );   } } 

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

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

बारबरा लिस्कोव (लिस्कोव सबस्टीट्यूशन सिद्धांत) का प्रतिस्थापन सिद्धांत इंगित करता है कि कार्यक्रमों में वस्तुओं को कार्यक्रम के सही संचालन का उल्लंघन किए बिना उनके उपप्रकारों के उदाहरणों के साथ प्रतिस्थापित किया जाना चाहिए।

यदि यह परिभाषा आपको बहुत स्वतंत्र रूप से लगती है - तो इसका अधिक कठोर संस्करण है।


बारबरा लिस्कोव प्रतिस्थापन सिद्धांत: यदि कोई बतख की तरह बतख और क्वैक्स की तरह दिखता है, लेकिन बैटरी की जरूरत है - शायद गलत अमूर्त चुना जाता है

निम्नलिखित उदाहरण पर एक नज़र डालें:

 class User { constructor(roles) {   this.roles = roles; } getRoles() {   return this.roles; } } class AdminUser extends User {} const ordinaryUser = new User(['moderator']); const adminUser = new AdminUser({role: 'moderator'},{role: 'admin'}); function showUserRoles(user) { const roles = user.getRoles(); roles.forEach((role) => console.log(role)); } showUserRoles(ordinaryUser); showUserRoles(adminUser); 

हमारे पास एक User वर्ग है जिसका निर्माता उपयोगकर्ता भूमिकाओं को स्वीकार करता है। इस वर्ग के आधार पर, हम AdminUser वर्ग बनाते हैं। उसके बाद, हमने एक सरल showUserRoles फ़ंक्शन बनाया, जो User एक ऑब्जेक्ट को एक पैरामीटर के रूप में लेता है और कंसोल में उपयोगकर्ता को सौंपी गई सभी भूमिकाओं को प्रदर्शित करता है।

हम इस फ़ंक्शन को adminUser और adminUser ऑब्जेक्ट्स को पास करके इसे कॉल करते हैं, जिसके बाद हम एक त्रुटि का सामना करते हैं।


त्रुटि

क्या हुआ? AdminUser वर्ग AdminUser ऑब्जेक्ट User वर्ग के ऑब्जेक्ट के समान है। यह निश्चित रूप से User रूप में "क्वैक्स" करता है, क्योंकि इसमें User के समान तरीके हैं। समस्या "बैटरी" है। तथ्य यह है कि जब adminUser ऑब्जेक्ट बनाते हैं, तो हमने कुछ ऑब्जेक्ट्स को इसमें पास किया, न कि एक सरणी के लिए।

यहां प्रतिस्थापन के सिद्धांत का उल्लंघन किया गया है, क्योंकि showUserRoles फ़ंक्शन को User वर्ग की वस्तुओं और इस वर्ग के वंशजों के आधार पर बनाई गई वस्तुओं के साथ सही ढंग से काम करना चाहिए।

इस समस्या को AdminUser करना मुश्किल नहीं है - बस ऑब्जेक्ट्स के बजाय AdminUser कंस्ट्रक्टर के लिए AdminUser सरणी पास करें:

 const ordinaryUser = new User(['moderator']); const adminUser = new AdminUser(['moderator','admin']); 

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

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

यह सिद्धांत विशेष रूप से स्थिर टाइपिंग वाली भाषाओं में प्रासंगिक है, जिसमें निर्भरता को स्पष्ट रूप से इंटरफेस द्वारा परिभाषित किया गया है।

एक उदाहरण पर विचार करें:

 class UserTable extends Component {   ...     render() {       const user = {id: 1, name: 'Thomas', surname: 'Foobar', age: 33};       return (           <div>               ...                 <UserRow user={user}/>               ...           </div>       );   }    ... } class UserRow extends Component {   static propTypes = {       user: PropTypes.object.isRequired,   };   render() {       return (           <tr>               <td>Id: {this.props.user.id}</td>               <td>Name: {this.props.user.name}</td>           </tr>       )   } } 

UserTable घटक UserTable घटक को UserRow , इसे पास करते हुए, गुणों में, पूर्ण उपयोगकर्ता जानकारी के साथ एक ऑब्जेक्ट। यदि हम UserRow घटक के कोड का विश्लेषण करते हैं, तो यह पता चलता है कि यह उपयोगकर्ता के बारे में पूरी जानकारी रखने वाली वस्तु पर निर्भर करता है, लेकिन उसे केवल id और name गुणों की आवश्यकता होती है।

यदि आप इस घटक के लिए एक परीक्षण लिखते हैं और टाइपस्क्रिप्ट या फ्लो का उपयोग करते हैं, तो आपको इसके सभी गुणों के साथ user ऑब्जेक्ट के लिए एक नकली बनाना होगा, अन्यथा कंपाइलर एक त्रुटि फेंक देगा।

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

जैसा कि यह हो सकता है, एक प्रोग्राम जो इंटरफ़ेस के पृथक्करण के सिद्धांत को संतुष्ट करता है वह अधिक समझने योग्य है।

 class UserTable extends Component {   ...     render() {       const user = {id: 1, name: 'Thomas', surname: 'Foobar', age: 33};       return (           <div>               ...                 <UserRow id={user.id} name={user.name}/>               ...           </div>       );   }    ... } class UserRow extends Component {   static propTypes = {       id: PropTypes.number.isRequired,       name: PropTypes.string.isRequired,   };   render() {       return (           <tr>               <td>Id: {this.props.id}</td>               <td>Name: {this.props.name}</td>           </tr>       )   } } 

याद रखें कि यह सिद्धांत न केवल घटकों पर पारित संपत्ति प्रकारों पर लागू होता है।

निर्भरता उलटा सिद्धांत (डी)

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

निम्नलिखित उदाहरण पर विचार करें:

 class App extends Component { ... async fetchUsers() {   const users = await fetch('http://totallyhardcodedurl.com/stupid');   this.setState({users}); } ... } 

यदि हम इस कोड का विश्लेषण करते हैं, तो यह स्पष्ट हो जाता है कि App घटक वैश्विक fetch फ़ंक्शन पर निर्भर करता है। यदि आप UML में इन संस्थाओं के संबंध का वर्णन करते हैं, तो आपको निम्नलिखित चित्र मिलते हैं।


घटक और कार्य के बीच संबंध

एक उच्च-स्तरीय मॉड्यूल को किसी चीज के निम्न-स्तरीय कंक्रीट कार्यान्वयन पर निर्भर नहीं होना चाहिए। यह अमूर्तता पर निर्भर होना चाहिए।

App घटक को यह जानने की जरूरत नहीं है कि उपयोगकर्ता जानकारी कैसे डाउनलोड करें। इस समस्या को हल करने के लिए, हमें App कंपोनेंट और fetch फंक्शन के बीच निर्भरता को fetch करना होगा। नीचे एक यूएमएल आरेख है जो इसे दिखाता है।


निर्भरता का उलटा

यहाँ इस तंत्र का कार्यान्वयन है।

 class App extends Component {   static propTypes = {       fetchUsers: PropTypes.func.isRequired,       saveUsers: PropTypes.func.isRequired   };   ...     componentDidMount() {       const users = this.props.fetchUsers();       this.setState({users});   }   ... } 

अब हम कह सकते हैं कि घटक बहुत जुड़ा नहीं है, क्योंकि इसमें इस बारे में कोई जानकारी नहीं है कि हम किस प्रोटोकॉल का उपयोग करते हैं - HTTP, SOAP, या कोई अन्य। घटक की बिल्कुल भी परवाह नहीं है।

निर्भरता उलटा के सिद्धांत का अनुपालन कोड के साथ काम करने के लिए हमारी संभावनाओं का विस्तार करता है, क्योंकि हम बहुत आसानी से डेटा लोडिंग तंत्र को बदल सकते हैं, और App घटक बिल्कुल भी नहीं बदलेगा।

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

परिणाम

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

प्रिय पाठकों! रिएक्ट एप्लिकेशन विकसित करते समय क्या आप SOLID सिद्धांतों का उपयोग करते हैं?