"बताओ, मत पूछो" पर स्पष्टीकरण अच्छा OO माना जाता है


49

इस ब्लॉगपोस्ट को हैकर न्यूज़ पर कई अपवॉट्स के साथ पोस्ट किया गया था। C ++ से आ रहा है, इन उदाहरणों में से अधिकांश मुझे जो सिखाया गया है उसके खिलाफ जाना प्रतीत होता है।

जैसे उदाहरण # 2:

खराब:

def check_for_overheating(system_monitor)
  if system_monitor.temperature > 100
    system_monitor.sound_alarms
  end
end

बनाम अच्छा:

system_monitor.check_for_overheating

class SystemMonitor
  def check_for_overheating
    if temperature > 100
      sound_alarms
    end
  end
end

C ++ में सलाह यह है कि आपको सदस्य फ़ंक्शंस के बजाय फ़्री फ़ंक्शंस को प्राथमिकता देना चाहिए क्योंकि वे एन्कैप्सुलेशन बढ़ाते हैं। ये दोनों एक जैसे शब्दार्थ हैं, इसलिए उस पसंद को पसंद करें जिसकी पहुँच अधिक राज्य तक है?

उदाहरण 4:

खराब:

def street_name(user)
  if user.address
    user.address.street_name
  else
    'No street name on file'
  end
end

बनाम अच्छा:

def street_name(user)
  user.address.street_name
end

class User
  def address
    @address || NullAddress.new
  end
end

class NullAddress
  def street_name
    'No street name on file'
  end
end

Userएक असंबंधित त्रुटि स्ट्रिंग को प्रारूपित करने की जिम्मेदारी क्यों है ? क्या होगा अगर मैं प्रिंट के अलावा कुछ करना चाहता हूं 'No street name on file'अगर इसकी कोई सड़क नहीं है? क्या होगा अगर सड़क का नाम एक ही चीज़ हो?


क्या कोई मुझे बता सकता है "बताओ, मत पूछो" फायदे और औचित्य? मैं वह नहीं देख रहा हूं जो बेहतर है, बल्कि लेखक के दृष्टिकोण को समझने की कोशिश कर रहा हूं।


कोड उदाहरण रूबी हो सकते हैं और पायथन नहीं, मैं दुन्नो।
पब्बी

2
मुझे हमेशा आश्चर्य होता है कि क्या पहला उदाहरण एसआरपी का उल्लंघन नहीं है?
टिजिन

1
आप पढ़ सकते हैं कि: pragprog.com/articles/tell-dont-ask
Mik378

माणिक। @ उदाहरण के लिए आशुलिपि है और पाइथन व्हाट्सएप के साथ अपने ब्लॉकों को समाप्त करता है।
एरिक रेपेन

3
"सी ++ में सलाह यह है कि आपको सदस्य कार्यों के बजाय मुफ्त कार्यों को प्राथमिकता देना चाहिए क्योंकि वे एन्कैप्सुलेशन बढ़ाते हैं।" मैं नहीं जानता कि आपको किसने बताया, लेकिन यह सच नहीं है। नि: शुल्क कार्यों का उपयोग एन्कैप्सुलेशन बढ़ाने के लिए किया जा सकता है, लेकिन वे जरूरी नहीं कि एनकैप्सुलेशन को बढ़ाते हैं।
रोब के

जवाबों:


81

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

आपको वस्तुओं को यह बताने का प्रयास करना चाहिए कि आप उन्हें क्या करना चाहते हैं; उनसे उनके राज्य के बारे में सवाल न पूछें, निर्णय लें और फिर उन्हें बताएं कि क्या करना है।

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

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

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

http://pragprog.com/articles/tell-dont-ask


4
उदाहरण पाठ कई चीजों को अस्वीकार कर देता है जो स्पष्ट रूप से अच्छा अभ्यास है।
डेडएमजी जूल

13
@DeadMG यह वही करता है जो आप केवल उन लोगों के लिए कहते हैं जो इसे धीरे-धीरे पालन करते हैं, जो साइट के नाम और साइट लेखकों के प्रमुख विचार को "व्यावहारिक रूप से" नजरअंदाज करते हैं जो कि उनकी प्रमुख पुस्तक में स्पष्ट रूप से कहा गया है: "एक सबसे अच्छा समाधान जैसी कोई चीज नहीं है। ... "
gnat

2
किताब कभी नहीं पढ़ी। न ही मेरी इच्छा होगी। मैंने केवल उदाहरण पाठ पढ़ा, जो पूरी तरह से निष्पक्ष है।
डेडएमजी जूल

3
@DeadMG कोई चिंता नहीं। अब जब आप उस महत्वपूर्ण बिंदु को जानते हैं जो इस उदाहरण को (और उस मामले के लिए प्रागप्रोग से किसी अन्य को) संबंधित संदर्भ में ("सबसे अच्छा समाधान के रूप में ऐसी कोई बात नहीं है ..."), यह पुस्तक पढ़ने के लिए ठीक नहीं है
gnat

1
मुझे अभी भी यकीन नहीं है कि बताओ, डोन्ट आस्क को संदर्भ के बिना तुम्हारे लिए वर्तनी के लिए माना जाता है लेकिन यह वास्तव में अच्छा OOP सलाह है।
एरिक रेपेन

16

आम तौर पर, टुकड़ा बताता है कि आपको दूसरों के बारे में तर्क करने के लिए सदस्य राज्य को उजागर नहीं करना चाहिए, यदि आप स्वयं इसके बारे में तर्क कर सकते हैं

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

उदाहरण के लिए, यदि सिस्टम temperatureक्वेरी के रूप में प्रदान करता है , तो कल, क्लाइंट check_for_underheatingको बदलने के बिना हो सकता है SystemMonitor। यह तब नहीं है जब खुद को SystemMonitorलागू check_for_overheatingकरता है। इस प्रकार, एक ऐसा SystemMonitorवर्ग जिसका काम बहुत अधिक होने पर अलार्म SystemMonitorबजाना है, इस पर अमल करता है- लेकिन एक वर्ग जिसका काम तापमान को पढ़ने के लिए किसी अन्य कोड की अनुमति देना है ताकि वह नियंत्रित कर सके, कह सकता है, टर्बोबोस्ट या ऐसा कुछ , नहीं चाहिए।

यह भी ध्यान दें कि दूसरा उदाहरण निरर्थक वस्तु विरोधी पैटर्न का उपयोग करता है।


19
"अशक्त वस्तु" वह नहीं है जिसे मैं एक विरोधी प्रतिरूप कहूंगा, इसलिए मुझे आश्चर्य है कि ऐसा करने का आपका कारण क्या है?
कोनराड रूडोल्फ

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

4
मेरा तर्क है कि यह पूरी तरह से समस्या डोमेन पर निर्भर करता है।
कोनराड रुडोल्फ

5
@DeadMG मैं मानता हूँ कि ऊपर के उदाहरण अशक्त वस्तु पैटर्न के एक बुरा उपयोग है, लेकिन वहाँ है इसे का उपयोग करने के लिए एक योग्यता। कुछ बार मैंने कुछ इंटरफ़ेस या अन्य के 'नो-ऑप' क्रियान्वयन का उपयोग किया है ताकि सिस्टम की अनुमति देने वाली अशक्तता की जांच या सही 'शून्य' होने से बचा जा सके।
मैक्स

6
यकीन नहीं है कि मैं आपकी बात "ग्राहक check_for_underheatingको बदलने के बिना कर सकता हूं" के साथ देख रहा हूं SystemMonitor। ग्राहक SystemMonitorउस बिंदु से अलग कैसे है ? क्या आप अब कई वर्गों में अपने निगरानी तर्क को भंग नहीं कर रहे हैं? मैं एक मॉनिटर क्लास के साथ समस्या को भी नहीं देखता हूं जो स्वयं को अलार्म फ़ंक्शन को संग्रहीत करते समय अन्य वर्गों को सेंसर की जानकारी प्रदान करता है। बूस्टर कंट्रोलर को बूस्ट w / o कंट्रोल करना चाहिए जिससे तापमान बढ़ने पर अलार्म बजने की चिंता हो।
TMN

9

आपके ओवरहेटिंग उदाहरण के साथ वास्तविक मुद्दा यह है कि ओवरहिटिंग के रूप में जो योग्यता होती है उसके नियम अलग-अलग प्रणालियों के लिए आसानी से भिन्न नहीं होते हैं। मान लीजिए कि सिस्टम A ऐसा है जैसा आपके पास है (अस्थायी> 100 ओवरहीटिंग है) लेकिन सिस्टम B अधिक नाजुक है (अस्थायी> 93 ओवरहीटिंग है)। क्या आप सिस्टम के प्रकार की जांच करने के लिए अपना नियंत्रण फ़ंक्शन बदलते हैं, और फिर सही मान लागू करते हैं?

if (system is a System_A and system_monitor.temp >100)
  system_monitor.sound_alarms
else if (system is a System_B and system_monitor.temp > 93)
  system_monitor.sound_alarms
end

या क्या आपके पास प्रत्येक प्रकार की प्रणाली इसकी हीटिंग क्षमता को परिभाषित करती है?

संपादित करें:

system.check_for_overheating

class SystemA : System
  def check_for_overheating
    if temperature > 100
      sound_alarms
    end
  end
end

class SystemB : System
  def check_for_overheating
    if temperature > 93
      sound_alarms
    end
  end
end

पूर्व तरीका आपके नियंत्रण फ़ंक्शन को बदसूरत बना देता है क्योंकि आप अधिक सिस्टम के साथ काम करना शुरू करते हैं। उत्तरार्द्ध नियंत्रण समारोह को स्थिर होने देता है क्योंकि समय आगे बढ़ता है।


1
मॉनिटर के साथ प्रत्येक सिस्टम रजिस्टर क्यों नहीं है। पंजीकरण के दौरान वे संकेत दे सकते हैं कि ओवरहीटिंग कब होती है।
मार्टिन

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

1
यही कारण है कि आपको एक मॉडल बताना चाहिए। आप सिस्टम को वर्तमान स्थितियां बताते हैं और यह सामान्य कार्य स्थितियों के बाहर होने पर आपको सूचित करता है। इस प्रकार आपको SystemMoniter को संशोधित करने की आवश्यकता नहीं है। यह आपके लिए एनकैप्सुलेशन है।
मार्टिन

@ लोकीअस्तारी - मुझे लगता है कि हम यहां क्रॉस के उद्देश्यों पर बात कर रहे हैं - मैं वास्तव में अलग-अलग मॉनिटरों के बजाय अलग-अलग सिस्टम बनाने पर विचार कर रहा था। बात यह है, सिस्टम को पता होना चाहिए कि यह उस स्थिति में है जो अलार्म उठाता है, जैसा कि कुछ बाहरी नियंत्रक फ़ंक्शन के विपरीत है। SystemA का अपना मापदंड होना चाहिए, SystemB का अपना होना चाहिए। नियंत्रक को बस (नियमित अंतराल पर) यह पूछने में सक्षम होना चाहिए कि क्या सिस्टम ठीक है या नहीं।
मैथ्यू फ्लिन

6

सबसे पहले, मुझे लगता है कि मुझे उदाहरणों के आपके चरित्रांकन को "बुरा" और "अच्छा" कहना चाहिए। आलेख "इतना अच्छा नहीं" और "बेहतर" शब्दों का उपयोग करता है, मुझे लगता है कि उन शर्तों को एक कारण के लिए चुना गया था: ये दिशानिर्देश हैं, और परिस्थितियों के आधार पर "इतना अच्छा नहीं" दृष्टिकोण उचित हो सकता है, या वास्तव में एकमात्र समाधान हो सकता है।

जब एक विकल्प दिया जाता है, तो आपको किसी भी कार्यक्षमता को शामिल करने के लिए प्राथमिकता देनी चाहिए जो पूरी तरह से बाहर के बजाय कक्षा में कक्षा पर निर्भर करती है - इसका कारण एन्कैप्सुलेशन के कारण होता है, और यह तथ्य कि इससे समय के साथ कक्षा को विकसित करना आसान हो जाता है। वर्ग भी विज्ञापन का एक बेहतर काम करता है यह मुफ्त कार्यों के एक समूह की तुलना में क्षमता है।

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

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

तो ऐसे मामले हो सकते हैं जहां "अच्छा नहीं है" जाने का रास्ता है, लेकिन आम तौर पर, "बेहतर" है, ठीक है, बेहतर है।


3

डेटा / ऑब्जेक्ट एंटी-सिमेट्री

जैसा कि अन्य ने बताया है, टेल-डॉन्ट-आस्क विशेष रूप से उन मामलों के लिए है जहां आप ऑब्जेक्ट स्टेट को बदलने के बाद कहते हैं (उदाहरण के लिए इस पृष्ठ पर कहीं और प्रागप्रोग पाठ पोस्ट किया गया है)। यह हमेशा ऐसा नहीं होता है, उदाहरण के लिए 'user' ऑब्जेक्ट को उसके user.address के लिए पूछे जाने के बाद नहीं बदला जाता है। इसलिए यह बताने योग्य है कि अगर टेल-डॉन्ट-आस्क को लागू करने के लिए यह एक उपयुक्त मामला है।

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

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

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

बॉब मार्टिन, अपनी पुस्तक "क्लीन कोड" में, इसे "डेटा / ऑब्जेक्ट एंटी-सिमेट्री" (p.95ff) कहते हैं, अन्य समुदाय इसे " अभिव्यक्ति समस्या " के रूप में संदर्भित कर सकते हैं ।


3

इस प्रतिमान को कभी-कभी 'बताओ, मत पूछो' के रूप में जाना जाता है , जिसका अर्थ है कि वस्तु को क्या करना है, उसके राज्य के बारे में मत पूछो; और कभी-कभी 'पूछें, नहीं बताएं' के रूप में , इसका मतलब है कि आप के लिए कुछ करने के लिए कहें, यह न बताएं कि इसकी स्थिति क्या होनी चाहिए। किसी भी तरह से सबसे अच्छा अभ्यास एक ही है - जिस तरह से किसी वस्तु को एक क्रिया करनी चाहिए वह वस्तु की चिंता है, न कि कॉलिंग ऑब्जेक्ट की। इंटरफेस को अपने राज्य को उजागर करने से बचना चाहिए (जैसे एक्सेसर्स या पब्लिक प्रॉपर्टीज के माध्यम से) और इसके बजाय उन तरीकों को उजागर करना चाहिए जिनके कार्यान्वयन अपारदर्शी है। दूसरों ने इसे व्यावहारिक प्रोग्रामर के लिंक के साथ कवर किया है।

यह नियम "डबल-डॉट" या "डबल एरो" कोड से बचने के बारे में नियम से संबंधित है, जिसे अक्सर 'केवल तात्कालिक दोस्तों से बात' के रूप में संदर्भित किया जाता है, जो राज्यों foo->getBar()->doSomething()में खराब है, इसके बजाय foo->doSomething();बार की कार्यक्षमता के आसपास एक रैपर कॉल का उपयोग करें, और बस के रूप में कार्यान्वित return bar->doSomething();- यदि fooप्रबंधन के लिए जिम्मेदार है bar, तो इसे ऐसा करने दें!


1

"बताओ, मत पूछो" के बारे में अन्य अच्छे उत्तरों के अलावा, आपके विशिष्ट उदाहरणों पर कुछ टिप्पणी जो मदद कर सकती हैं:

C ++ में सलाह यह है कि आपको सदस्य फ़ंक्शंस के बजाय फ़्री फ़ंक्शंस को प्राथमिकता देना चाहिए क्योंकि वे एन्कैप्सुलेशन बढ़ाते हैं। ये दोनों एक जैसे शब्दार्थ हैं, इसलिए उस पसंद को पसंद करें जिसकी पहुँच अधिक राज्य तक है?

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

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

_ सड़क का नाम ’और the त्रुटि संदेश प्रदान करना’ दोनों करने की जिम्मेदारी _ सड़क_नाम ’की क्यों है? कम से कम 'अच्छा' संस्करण में, प्रत्येक टुकड़े की एक जिम्मेदारी होती है। फिर भी, यह एक महान उदाहरण नहीं है।


2
यह सच नहीं है। आप मानते हैं कि तापमान के साथ ओवरहीटिंग के लिए जाँच एकमात्र समझदार चीज़ है। क्या होगा यदि कक्षा को कई तापमान मॉनिटरों में से एक माना जाता है, और एक प्रणाली को उदाहरण के लिए, उनके कई परिणामों के आधार पर अलग-अलग कार्रवाई करनी चाहिए? जब यह व्यवहार किसी एकल उदाहरण के पूर्व-परिभाषित व्यवहार तक सीमित हो सकता है, तो सुनिश्चित करें। और, यह स्पष्ट रूप से लागू नहीं हो सकता।
डेडएमजी

ज़रूर, या अगर थर्मोस्टैट और अलार्म अलग-अलग वर्गों में मौजूद थे (जैसा कि उन्हें संभावना होनी चाहिए)।
तेलस्टीन

1
@ डीडीएमजी: सामान्य सलाह यह है कि चीजों को निजी / संरक्षित किया जाए, जब तक कि आपको उन तक पहुंचने की आवश्यकता न हो। हालांकि यह विशेष उदाहरण meh है, जो मानक अभ्यास का विवाद नहीं करता है।
ग्वांटे

'Meh' थोथा के प्रचलन के बारे में एक लेख में एक उदाहरण इसे विवादित करता है। यदि यह प्रथा मानक है क्योंकि इसके बड़े लाभ हैं, तो एक उपयुक्त उदाहरण खोजने में परेशानी क्यों?
स्टिजन डे विट

1

ये उत्तर बहुत अच्छे हैं, लेकिन यहाँ केवल एक और उदाहरण पर जोर दिया गया है: ध्यान दें कि यह आमतौर पर दोहराव से बचने का एक तरीका है। उदाहरण के लिए, मान लें कि आपके पास किसी कोड के साथ SEALAL स्थान हैं:

Product product = productMgr.get(productUuid)
if (product.userUuid != currentUser.uuid) {
    throw BlahException("This product doesn't belong to this user")
}

इसका मतलब है कि आपके पास कुछ बेहतर होगा:

Product product = productMgr.get(productUuid, currentUser)

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


0

मेरा मानना ​​है कि उच्च-स्तरीय ऑब्जेक्ट लिखते समय यह अधिक सच है, लेकिन गहरे स्तर पर नीचे जाने पर कम सच है जैसे कि क्लास लाइब्रेरी। क्योंकि सभी वर्ग उपभोक्ताओं को संतुष्ट करने के लिए हर एक विधि को लिखना असंभव है।

उदाहरण के लिए # 2, मुझे लगता है कि यह अति-सरलीकृत है। अगर हम वास्तव में इसे लागू करने जा रहे थे, तो SystemMonitor उसी स्तर पर एम्बेडेड उच्च स्तर के अमूर्त के लिए निम्न स्तर के हार्डवेयर एक्सेस और लॉजिक के लिए कोड को समाप्त कर देगा। दुर्भाग्य से, अगर हम इसे दो वर्गों में अलग करने की कोशिश कर रहे हैं, तो हम "बताओ, मत पूछो" का उल्लंघन करेंगे।

उदाहरण # 4 कमोबेश एक ही है - यह यूआई लॉजिक को डेटा टियर में एम्बेड कर रहा है। अब अगर हम यह तय करने जा रहे हैं कि कोई पता न होने की स्थिति में उपयोगकर्ता क्या देखना चाहता है, तो हमें डेटा टियर में ऑब्जेक्ट को ठीक करना होगा, और क्या होगा यदि दो एक ही ऑब्जेक्ट का उपयोग कर रहे हैं, लेकिन अशक्त पते के लिए अलग पाठ का उपयोग करने की आवश्यकता है?

मैं सहमत हूं कि अगर हम हर चीज के लिए "बताओ, मत पूछो" को लागू कर सकते हैं, तो यह बहुत उपयोगी होगा - मैं खुद खुश रहूंगा अगर मैं वास्तविक जीवन में केवल पूछने के बजाय (और खुद ऐसा कर सकूं)! हालांकि, वास्तविक जीवन में भी, समाधान की व्यवहार्यता उच्च स्तर की कक्षाओं तक ही सीमित है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.