एक बार फिर Lisk प्रतिस्थापन के सिद्धांत के बारे में, या OOP में विरासत के शब्दार्थ

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

आमतौर पर, इस समस्या का वर्णन करने के लिए, वे आयत वर्ग से वर्ग वर्ग की विरासत के बारे में एक उदाहरण का उपयोग करते हैं, या इसके विपरीत।

हमें एक आयत श्रेणी दें:

class Rectangle: def __init__(self, width, height): self._width = width self._height = height def set_width(self, width): self._width = width def set_height(self, height): self._height = height def get_area(self): return self._width * self._height ... 

अब हम स्क्वायर वर्ग लिखना चाहते थे, लेकिन क्षेत्र गणना कोड का पुन: उपयोग करने के लिए, यह आयत से स्क्वायर को वारिस करने के लिए तर्कसंगत लगता है:

 class Square(Rectangle): def set_width(self, width): self._width = width self._height = width def set_height(self, height): self._width = height self._height = height 

ऐसा लगता है कि स्क्वायर और आयत वर्गों का कोड सुसंगत है। ऐसा लगता है कि स्क्वायर वर्ग के गणितीय गुणों को संरक्षित करता है, अर्थात। और एक आयत। इसका मतलब है कि हम आयत के बजाय स्क्वायर ऑब्जेक्ट पास कर सकते हैं।

लेकिन अगर हम ऐसा करते हैं, तो हम आयत वर्ग के व्यवहार का उल्लंघन कर सकते हैं:

उदाहरण के लिए, एक ग्राहक कोड है:

 def client_code(rect): rect.set_height(10) rect.set_width(20) assert rect.get_area() == 200 

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

यदि वर्ग वर्ग आयत वर्ग का वंशज है, तो वर्ग के साथ काम करना और आयत के तरीकों का प्रदर्शन करना, हमें यह भी ध्यान नहीं देना चाहिए कि यह एक आयत नहीं है।

आप इस समस्या को ठीक कर सकते हैं, उदाहरण के लिए, इस तरह:

1. कक्षा से पूरी तरह से मेल खाने के लिए, या अगर यह अलग-अलग वर्गों के लिए अलग-अलग काम करेगा, तो यह सुनिश्चित करें
2. स्क्वायर में, set_size () विधि बनाएँ और set_height, set_width विधियों को ओवरराइड करें ताकि वे अपवादों को फेंक दें
   आदि आदि

इस तरह के कोड और ऐसे वर्ग काम करेंगे, इस अर्थ में कि कोड काम कर रहा होगा।

एक और प्रश्न यह है कि स्क्वायर कोड या रेक्टेंगल क्लास का उपयोग करने वाले क्लाइंट कोड को आधार वर्ग और उसके व्यवहार के बारे में, या वंशज वर्ग और उसके व्यवहार के बारे में जानना होगा।

समय के साथ, हम यह प्राप्त कर सकते हैं:

• वंशज वर्ग अधिकांश तरीकों से आगे निकल जाएगा
• बेस क्लास के लिए तरीकों को फिर से लाने या जोड़ने से वंश का उपयोग करके कोड टूट जाएगा
• आधार वर्ग की वस्तुओं का उपयोग करने वाले कोड में ifs होगा, वस्तु वर्ग के लिए जाँच, और वंशजों के लिए व्यवहार और आधार वर्ग अलग है

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

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

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

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

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

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

यानी ऐसे वर्ग प्रतिस्थापन सिद्धांत को संतुष्ट करते हैं:

 class Rectangle: def draw(): ... def get_area(): ... class Square(Rectangle): pass 

हालांकि बेशक यह बहुत अच्छा कोड नहीं है, और यहां तक ​​कि, शायद, क्लास डिजाइनिंग का एंटीपैटर्न, लेकिन औपचारिक दृष्टिकोण से यह लिस्कोव सिद्धांत को संतुष्ट करता है।

एक और उदाहरण । एक सेट एक मल्टीसेट का एक उपप्रकार है। यह डोमेन सार का अनुपात है। लेकिन कोड को लिखा जा सकता है ताकि हम सेट क्लास को बैग से विरासत में प्राप्त करें और प्रतिस्थापन सिद्धांत का उल्लंघन किया जाता है, या हम लिख सकते हैं ताकि सिद्धांत का सम्मान किया जाए। एक ही विषय डोमेन शब्दार्थ के साथ।

सामान्य तौर पर, वर्गों के उत्तराधिकार को "आईएस" रिश्ते के कार्यान्वयन के रूप में माना जा सकता है, लेकिन विषय क्षेत्र की संस्थाओं के बीच नहीं, बल्कि कक्षाओं के बीच। और क्या वंशज वर्ग आधार वर्ग का एक उपप्रकार है, यह निर्धारित किया जाता है कि क्लाइंट कोड का उपयोग करने वाले प्रतिबंध और वर्ग व्यवहार क्या है (और सिद्धांत रूप में उपयोग कर सकते हैं)।

बाधाओं, आक्रमणकारियों, एक बेस क्लास अनुबंध कोड में तय नहीं किया गया है, लेकिन उन डेवलपर्स के प्रमुखों में तय किया गया है जो कोड को संपादित और पढ़ते हैं। "ब्रेकिंग" क्या है, "कॉन्ट्रैक्ट" को तोड़ना कोड द्वारा नहीं, बल्कि डेवलपर के सिर में वर्ग के शब्दार्थ द्वारा निर्धारित किया जाता है।

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

यह समझना बेहद जरूरी है कि बेस क्लास में लागू की गई अमूर्तता की सीमाएं आमतौर पर प्रोग्राम कोड में नहीं होती हैं। ये प्रतिबंध डेवलपर द्वारा समझे, जाने और समर्थित हैं। यह अमूर्तता और कोड की स्थिरता की निगरानी करता है। कोड को व्यक्त करने के लिए इसका क्या मतलब है।

उदाहरण के लिए, एक आयत में एक और विधि है जो किसी दृश्य को json में लौटाती है

 class Rectangle: def to_dict(self): return {"height": self.height, "width": self.width} 

और स्क्वायर में हम इसे फिर से परिभाषित करते हैं:

 class Square: def to_dict(self): return {"size": self.height} 

यदि हम आयत वर्ग to_json के व्यवहार के लिए बुनियादी अनुबंध को ऊंचाई और चौड़ाई मानते हैं, तो कोड

 r = rect.to_dict() log(r['height'], r['width']) 

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

यदि हम मानते हैं कि आयत वर्ग के व्यवहार का मूल अनुबंध यह है कि to_dict एक ऐसा शब्दकोश देता है जिसे विशिष्ट क्षेत्रों पर रखे बिना क्रमबद्ध किया जा सकता है, तो ऐसी in_dict पद्धति ठीक होगी।

वैसे, यह एक अच्छा उदाहरण है, मिथक को नष्ट करना जो अपरिवर्तनीयता सिद्धांत के उल्लंघन से बचाता है।

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

जितना संभव हो सके अनुबंध और अपरिवर्तनों की सभी शर्तों को कोड में स्थानांतरित करना संभव है, लेकिन सामान्य स्थिति में, व्यवहार के शब्दार्थ सभी कोड के बाहर एक ही झूठ होते हैं - समस्या क्षेत्र में, और डेवलपर द्वारा समर्थित हैं। The_dict के बारे में उदाहरण एक उदाहरण है, जहां अनुबंध को कोड में वर्णित किया जा सकता है, लेकिन उदाहरण के लिए, गेट_हाश विधि वास्तव में हैश के सभी गुणों के साथ एक हैश लौटाती है, और न केवल एक पंक्ति, असंभव है।

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

इसलिए, अक्सर लिस्कोव सिद्धांत के बजाय, अनुबंध प्रोग्रामिंग से पूर्व शर्त और पोस्टकंडिशन के लिए औपचारिक नियमों का उपयोग किया जाता है:

• एक उपवर्ग में पूर्व शर्त को मजबूत नहीं किया जा सकता है - एक उपवर्ग को आधार वर्ग से अधिक की आवश्यकता नहीं होनी चाहिए
• उपवर्गों के पदावनतियों को शिथिल नहीं किया जा सकता है - उपवर्ग आधार वर्ग से कम (वादा) प्रदान नहीं करना चाहिए
• बेस क्लास के आक्रमणकारियों को वंशज वर्ग में संरक्षित किया जाना चाहिए।

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

जो मायने रखता है वह वर्ग का वर्तमान व्यवहार नहीं है, लेकिन क्या वर्ग परिवर्तन से तात्पर्य है वर्ग की जिम्मेदारी या शब्दार्थ।

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

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

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

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

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

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

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

निष्पक्षता में, कुछ नियम हैं जो प्रतिस्थापन के सिद्धांत का उल्लंघन नहीं करने की सबसे अधिक संभावना है। यदि आप सभी खतरनाक संरचनाओं को प्रतिबंधित करते हैं, तो आप यथासंभव अपनी रक्षा कर सकते हैं। उदाहरण के लिए, C ++ के लिए, ओलेग ने इस बारे में लिखा। लेकिन सामान्य तौर पर, ऐसे नियम कक्षाओं को शास्त्रीय अर्थों में कक्षाओं में नहीं बदलते हैं।

प्रशासनिक तरीकों का उपयोग करते हुए, कार्य भी बहुत अच्छी तरह से हल नहीं हुआ है। यहाँ आप पढ़ सकते हैं कि अंकल मार्टिन ने C ++ में क्या किया और कैसे काम नहीं किया।

लेकिन वास्तविक औद्योगिक कोड में, अक्सर, लिस्कोव सिद्धांत का उल्लंघन किया जाता है, और यह डरावना नहीं है । सिद्धांत का पालन करना मुश्किल है, क्योंकि 1) एक वर्ग की जिम्मेदारी और शब्दार्थ अक्सर स्पष्ट नहीं होते हैं और कोड 2 में व्यक्त नहीं किए जाते हैं) एक वर्ग की जिम्मेदारी बदल सकती है - दोनों आधार वर्ग में और वंशज वर्ग में। लेकिन यह हमेशा कुछ बहुत भयानक परिणाम नहीं देता है। सबसे आम, सरल और सबसे बुनियादी उल्लंघन यह है कि एक ओवरराइड विधि व्यवहार को संशोधित करती है। उदाहरण के लिए यहाँ पर:

 class Task: def close(self): self.status = CLOSED ... class ProjectTask(Task): def close(self): if status == STARTED: raise Exception("Cannot close a started Project Task") ... 

ProjectTask की करीबी विधि उन मामलों में अपवाद को छोड़ देगी जिनमें टास्क वर्ग की वस्तुएं ठीक काम करती हैं। सामान्य तौर पर, आधार वर्ग के तरीकों के पुनर्वितरण में अक्सर प्रतिस्थापन के सिद्धांत का उल्लंघन होता है, लेकिन समस्या नहीं बनती है।

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

क्या बहुत सारे कोड हैं जो एक बेस क्लास की एक वस्तु की अपेक्षा करते हैं, लेकिन क्या हम वंशज क्लास के ऑब्जेक्ट को पास करते हैं? कई कार्यों के लिए, ऐसे कोड कभी भी मौजूद नहीं होंगे।

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

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