क्या एसओएलआईडी सिद्धांत में एसआरपी लासगना कोड का कारण बनता है?

Question

ठोस सिद्धांत विशेष रूप से SRP, हम तो बहुत सारे वर्ग के साथ ..
मेरा मतलब है, यह सिर्फ जैसे आप फिर एक डेटाबेस वर्ग
का निर्माण करना चाहते है, तो आप (
DatabaseHandler वर्ग जो डेटाबेस संभाल है का चयन करें, सम्मिलित करें, अद्यतन, हटाएं, आदि),

डेटाबेस एडाप्टर क्लास जो एक विस्तारित पीडीओ कक्षा है (निर्माण में पसंदीदा डिफ़ॉल्ट मोड सेट कर सकता है, एक नई तैयार विधि जो सीधे कथन तैयार करती है, इसे पैरामीटर से बांधती है, और इसे निष्पादित करती है,

क्वेरीब्यूल्डर क्लास जो SelectStatementBuilder क्लास के माता-पिता हैं, InsertStatementBuilder क्लास, DeleteStatementBuilde आर क्लास, UpdateStatementBuilder क्लास (SQLStatement निर्माण करने के लिए),

अभिव्यक्ति कक्षा जिसमें जरूरत अभिव्यक्ति बनाता है कहां खंड

SQLStatement क्लास (जो सिर्फ एक सामान्य स्ट्रिंग की तरह काम करता है, लेकिन इसके इंटरफेस SQLStatementInterface तो हम पता कर सकते हैं कि यह एक एसक्यूएल है वक्तव्य आदि ..

और, मुझे पता है कि यदि मैं इसे गहराई से खोदता हूं, और फिर से प्रतिक्रिया करता हूं तो मुझे और कक्षाएं मिलेंगी।

क्या एसआरपी सिद्धांत कार्यान्वयन Lasagna कोड का कारण बनता है? लासगना कोड ठीक है?

Answer 1

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

Uncle Bob defined SRP के रूप में:

एक वर्ग में केवल एक ही कारण बदलने के लिए होना चाहिए।

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

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