बताओ-मत-पूछें

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


आइए एक उदाहरण देखें। आइए कल्पना करें कि हमें अलार्म को नियंत्रित करने की आवश्यकता है, जो कि संख्या एक निश्चित स्तर से ऊपर उठने पर काम करेगी। यदि हम इसे "पूछना" शैली में लिखते हैं, तो हमें एक डेटा संरचना मिलती है ...

class AskMonitor... private int value; private int limit; private boolean isTooHigh; private String name; private Alarm alarm; public AskMonitor (String name, int limit, Alarm alarm) { this.name = name; this.limit = limit; this.alarm = alarm; } 

... फिर डेटा एक्सेस विधियों के साथ संगत:

 class AskMonitor... public int getValue() {return value;} public void setValue(int arg) {value = arg;} public int getLimit() {return limit;} public String getName() {return name;} public Alarm getAlarm() {return alarm;} 

और वे इसे इस तरह उपयोग करेंगे:

  AskMonitor am = new AskMonitor("Time Vortex Hocus", 2, alarm); am.setValue(3); if (am.getValue() > am.getLimit()) am.getAlarm().warn(am.getName() + " too high"); 

बताएं-मत पूछें हमें याद दिलाता है कि व्यवहार को ऑब्जेक्ट के अंदर वर्णित किया जाना चाहिए (समान फ़ील्ड का उपयोग करके):

 class TellMonitor... public void setValue(int arg) { value = arg; if (value > limit) alarm.warn(name + " too high"); } 

और यह इस तरह काम करेगा:

  TellMonitor tm = new TellMonitor("Time Vortex Hocus", 2, alarm); tm.setValue(3); 

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

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

लगभग। अनुवादक: मुझे सिद्धांत के नाम का अनुवाद करने की आवश्यकता पर संदेह है, लेकिन मेरे द्वारा प्रस्तावित विकल्पों में से एक के रूप में - "पूछें, न पूछें"