देर से जवाब लेकिन मैं विरोध नहीं कर सकता।
क्या X अधिकांश कक्षाओं में Y अच्छा है या एक विरोधी पैटर्न है?
ज्यादातर मामलों में, ज्यादातर नियम, बिना सोचे-समझे लागू किए गए, ज्यादातर गलत तरीके से गलत होंगे (इस एक सहित)।
आपको एक वस्तु के जन्म के बारे में एक कहानी बताऊंगा, जो कुछ सही, त्वरित और गंदे, प्रक्रियात्मक कोड की अराजकता के बीच होती है, जो डिजाइन द्वारा नहीं, बल्कि हताशा से बाहर हुई है।
मेरा इंटर्न और मैं एक वेबपेज को स्क्रेप करने के लिए जल्दी से कुछ थ्रो कोड बनाने के लिए पेयर प्रोग्रामिंग हैं। हमारे पास इस कोड के लंबे समय तक रहने की उम्मीद करने का कोई कारण नहीं है, इसलिए हम बस कुछ ऐसा कर रहे हैं जो काम करता है। हम एक स्ट्रिंग के रूप में पूरे पृष्ठ को पकड़ते हैं और उस सामान को काटते हैं जिसकी हमें सबसे आश्चर्यजनक रूप से भंगुर तरीके से ज़रूरत होती है। न्याय मत करो। यह काम करता हैं।
अब ऐसा करते हुए मैंने कुछ स्थैतिक तरीकों को तैयार किया। मेरे इंटर्न ने एक डीटीओ क्लास बनाया, जो आपको बहुत पसंद आया CatData।
जब मैंने पहली बार डीटीओ को देखा तो यह मुझे बुरा लगा। मेरे मस्तिष्क को जावा ने जो नुकसान पहुँचाया है, उसने मुझे सार्वजनिक क्षेत्रों में पुन: स्थापित कर दिया है। लेकिन हम C # में काम कर रहे थे। C # को समयपूर्व गेटर्स की कोई आवश्यकता नहीं है और डेटा को अपरिवर्तनीय बनाने या बाद में एनकैप्सुलेट करने के अपने अधिकार को सुरक्षित रखने के लिए बसने की आवश्यकता है। इंटरफ़ेस को बदले बिना आप जब चाहें उन्हें जोड़ सकते हैं। शायद सिर्फ इसलिए कि आप एक ब्रेकपॉइंट सेट कर सकते हैं। सभी अपने ग्राहकों को इसके बारे में एक बात बताए बिना। Yea C #। बू जावा।
इसलिए मैंने अपनी जीभ को पकड़ रखा था। मैंने देखा कि जब उन्होंने इस चीज़ को इस्तेमाल करने से पहले अपने स्थिर तरीकों का इस्तेमाल किया। हम उनमें से लगभग 14 थे। यह बदसूरत था, लेकिन हमारे पास देखभाल करने का कोई कारण नहीं था।
तब हमें अन्य स्थानों पर इसकी आवश्यकता थी। हमने खुद को कोड कॉपी और पेस्ट करना चाहा। इनिशियलाइज़ेशन की 14 लाइनें चारों ओर बह रही हैं। दर्द होने लगा था। उसने झिझकते हुए मुझसे विचार पूछे।
अनिच्छा से मैंने पूछा, "क्या आप किसी वस्तु पर विचार करेंगे?"
उसने अपने डीटीओ को पीछे देखा और भ्रम में अपना चेहरा खराब कर दिया। "यह एक वस्तु है"।
"मेरा मतलब एक वास्तविक वस्तु है"
"ओह?"
"मुझे आपको कुछ दिखाने दें। आप तय करें कि क्या यह उपयोगी है"
मैंने एक नया नाम चुना और जल्दी से कुछ इस तरह से देखा कि कुछ इस तरह से फुसफुसाया:
public class Cat{
CatData(string catPage) {
this.catPage = catPage
}
private readonly string catPage;
public string name() { return chop("name prefix", "name suffix"); }
public string weight() { return chop("weight prefix", "weight suffix"); }
public string image() { return chop("image prefix", "image suffix"); }
private string chop(string prefix, string suffix) {
int start = catPage.indexOf(prefix) + prefix.Length;
int end = catPage.indexOf(suffix);
int length = end - start;
return catPage.Substring(start, length);
}
}
यह कुछ भी नहीं किया स्थिर तरीकों पहले से ही नहीं कर रहे थे। लेकिन अब मैं 14 स्थिर तरीकों को एक कक्षा में चूसा हूँ जहाँ वे उस डेटा के साथ अकेले हो सकते हैं जिस पर उन्होंने काम किया था।
मैंने अपने इंटर्न को इसका इस्तेमाल करने के लिए मजबूर नहीं किया। मैंने अभी इसकी पेशकश की और उसे यह तय करने दिया कि क्या वह स्थैतिक तरीकों से चिपकना चाहता है। मैं यह सोचकर घर गया कि वह पहले से ही काम कर रहा था। अगले दिन मैंने पाया कि वह स्थानों के एक समूह में इसका उपयोग कर रहा था। इसने बाकी कोड को घोषित कर दिया जो अभी भी बदसूरत और प्रक्रियात्मक था लेकिन यह जटिलता अब किसी वस्तु के पीछे हमसे छिपी थी। यह थोड़ा बेहतर था।
अब सुनिश्चित करें कि हर बार जब आप इसे एक्सेस करते हैं, तो यह बहुत काम करता है। एक DTO एक अच्छा तेज़ कैश्ड वैल्यू है। मुझे इस बात की चिंता थी लेकिन मुझे एहसास हुआ कि यदि कोई कभी भी उपयोग किए गए कोड को छूने के बिना हमें आवश्यकता हो तो मैं कैशिंग को जोड़ सकता हूं। इसलिए मैं परेशान नहीं होगा जब तक हम परवाह नहीं करते।
क्या मैं कह रहा हूं कि आपको हमेशा डीटीओ के ऊपर ओओ ऑब्जेक्ट्स से चिपके रहना चाहिए? नहीं, डीटीओ की चमक जब आपको एक सीमा पार करने की आवश्यकता होती है जो आपको चलती विधियों से रखती है। डीटीओ का अपना स्थान है।
लेकिन इसलिए OO ऑब्जेक्ट करते हैं। दोनों उपकरणों का उपयोग करना सीखें। जानें कि प्रत्येक लागत क्या है। समस्या, स्थिति और आंतरिक निर्णय लेने देना सीखें। डोगमा यहाँ तुम्हारा दोस्त नहीं है।
चूंकि मेरा जवाब पहले से ही हास्यास्पद है, इसलिए मुझे अपने कोड की समीक्षा के साथ कुछ गलतफहमियों से अवगत कराएं।
उदाहरण के लिए, एक वर्ग में आमतौर पर वर्ग के सदस्य और विधियाँ होती हैं, जैसे:
public class Cat{
private String name;
private int weight;
private Image image;
public void printInfo(){
System.out.println("Name:"+this.name+",weight:"+this.weight);
}
public void draw(){
//some draw code which uses this.image
}
}
आपका निर्माता कहां है? यह मुझे पता करने के लिए पर्याप्त नहीं है कि क्या यह उपयोगी है।
लेकिन एकल जिम्मेदारी सिद्धांत और ओपन क्लोज्ड सिद्धांत के बारे में पढ़ने के बाद, मैं डीटीओ और हेल्पर क्लास में अलग-अलग क्लास को स्टैटिक तरीकों से ही पसंद करता हूं, जैसे:
public class CatData{
public String name;
public int weight;
public Image image;
}
public class CatMethods{
public static void printInfo(Cat cat){
System.out.println("Name:"+cat.name+",weight:"+cat.weight);
}
public static void draw(Cat cat){
//some draw code which uses cat.image
}
}
मुझे लगता है कि यह एकल जिम्मेदारी सिद्धांत पर फिट बैठता है क्योंकि अब कैटडेटा की जिम्मेदारी केवल डेटा रखने की है, तरीकों की भी परवाह नहीं करता (कैटमेथोड्स के लिए भी)।
आप सिंगल रिस्पॉन्सिबिलिटी प्रिंसिपल के नाम पर कई मूर्खतापूर्ण काम कर सकते हैं। मैं तर्क दे सकता था कि कैट स्ट्रिंग्स और कैट इनट्स को अलग किया जाना चाहिए। उस ड्राइंग के तरीके और चित्र सभी के पास अपनी कक्षा होनी चाहिए। यह कि आपका रनिंग प्रोग्राम एक ही जिम्मेदारी है, इसलिए आपको केवल एक ही क्लास करना चाहिए। : पी
मेरे लिए, सिंगल रिस्पॉन्सिबिलिटी सिद्धांत का पालन करने का सबसे अच्छा तरीका एक अच्छा एब्सट्रैक्शन है जो आपको एक बॉक्स में जटिलता डाल देता है ताकि आप इसे छिपा सकें। यदि आप इसे एक अच्छा नाम दे सकते हैं जो लोगों को आश्चर्यचकित होने से रोकता है जो वे पाते हैं जब वे अंदर देखते हैं तो आपने इसे अच्छी तरह से पालन किया है। उम्मीद है कि यह और निर्णय लेने के लिए और फिर परेशानी पूछ रहा है। ईमानदारी से, आपके दोनों कोड लिस्टिंग ऐसा करते हैं, इसलिए मैं यह नहीं देखता कि एसआरपी यहां क्यों मायने रखता है।
और यह खुले बंद सिद्धांत को भी फिट करता है क्योंकि नए तरीकों को जोड़ने से कैटडेटा क्लास को बदलने की आवश्यकता नहीं है।
नहीं। खुला करीबी सिद्धांत नए तरीकों को जोड़ने के बारे में नहीं है। यह पुरानी विधियों के कार्यान्वयन को बदलने और कुछ भी संपादित नहीं करने के बारे में है। कुछ भी नहीं है कि आप का उपयोग करता है और अपने पुराने तरीकों का नहीं। इसके बजाय आप कहीं और कुछ नया कोड लिखें। बहुरूपता का कुछ रूप अच्छी तरह से करेंगे। यहाँ मत देखिए।
मेरा प्रश्न यह है कि क्या यह एक अच्छा या एक प्रतिमान है?
खैर नरक मैं कैसे पता होना चाहिए? देखिए, इसे करने के फायदे और लागत दोनों हैं। जब आप कोड को डेटा से अलग करते हैं तो आप दूसरे को फिर से चालू किए बिना बदल सकते हैं। हो सकता है कि यह आपके लिए महत्वपूर्ण हो। हो सकता है कि यह सिर्फ आपके कोड को बेकार में जटिल बना दे।
यदि यह आपको बेहतर महसूस कराता है तो आप उस चीज़ से दूर नहीं हैं जो मार्टिन फॉलर किसी ऑब्जेक्ट को कहते हैं । आपको केवल प्राथमिक वस्तु को अपनी वस्तु में नहीं रखना है।
मैं आपको जो करना चाहूंगा, वह यह है कि अपनी जुदाई कैसे की जाए, या नहीं, कोडिंग शैली में। क्योंकि यह विश्वास है या नहीं आप एक शैली का चयन करने के लिए मजबूर नहीं किया जा रहा है। आपको बस अपनी पसंद से रहना है।