रिफैक्टरिंग और ओपन / बंद सिद्धांत

Question

मैं हाल ही में स्वच्छ कोड विकास के बारे में एक वेब साइट पढ़ रहा हूं (मैं यहां लिंक नहीं डालता क्योंकि यह अंग्रेजी में नहीं है)।

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

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

1. यदि नई आवश्यकताएं आती हैं (जैसे प्रदर्शन, या इंटरफ़ेस का पूरी तरह से नया कार्यान्वयन), जिसमें कोड में बड़े बदलाव की आवश्यकता होती है, तो मैं एक नया कार्यान्वयन लिखता हूं B, और Aजब तक Bपरिपक्व नहीं होता है तब तक उपयोग करता रहता हूं । जब Bपरिपक्व होता है, तो जो कुछ भी आवश्यक है उसे बदलना है कि कैसे Iत्वरित किया जाए।
2. यदि नई आवश्यकताएं इंटरफ़ेस में बदलाव का सुझाव देती हैं, तो मैं एक नया इंटरफ़ेस I'और एक नया कार्यान्वयन परिभाषित करता हूं A'। इसलिए I, Aजमे हुए हैं और जब तक उत्पादन प्रणाली के लिए कार्यान्वयन बने रहते हैं I'और A'उन्हें बदलने के लिए पर्याप्त स्थिर नहीं होते हैं।

इसलिए, इन अवलोकन के मद्देनजर, मैं थोड़ा हैरान था कि वेब पेज ने फिर जटिल रिफैक्टोरिंग का उपयोग करने का सुझाव दिया , "... क्योंकि कोड को सीधे अपने अंतिम रूप में लिखना संभव नहीं है।"

क्या ओपन / बंद सिद्धांत को लागू करने और एक सर्वोत्तम अभ्यास के रूप में जटिल रिफ्लेक्टरिंग के उपयोग का सुझाव देने के बीच कोई विरोधाभास / संघर्ष नहीं है? या यहाँ विचार यह है कि एक वर्ग के विकास के दौरान कोई जटिल रिफलेक्टरिंग का उपयोग कर सकता है A, लेकिन जब उस कक्षा का सफलतापूर्वक परीक्षण किया गया है तो उसे जमे हुए होना चाहिए?

Answer 1

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

Refactoring का मतलब है कि आप कार्यक्षमता को बदले बिना डिज़ाइन को बदल रहे हैं। संभवतः आप अपना डिज़ाइन बदल रहे हैं क्योंकि इसके साथ कोई समस्या है। शायद समस्या यह है कि मौजूदा कोड में संशोधन करते समय खुले-बंद सिद्धांत का पालन करना मुश्किल है, और आप इसे ठीक करने की कोशिश कर रहे हैं।

जब आप ऐसा करते हैं तो आप OCP का उल्लंघन किए बिना अपनी अगली सुविधा को लागू करना संभव बनाने के लिए एक रिफैक्टिंग कर रहे होंगे ।

Comments

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

— टी। सर

@ T.Sar एक सिद्धांत एक दिशानिर्देश है, जिस चीज के लिए आप प्रयास करते हैं, वे रखरखाव और मापनीयता पर उन्मुख होते हैं। यह मेरे लिए एक डिजाइन लक्ष्य जैसा दिखता है। मैं उस तरह से एक उपकरण के रूप में एक सिद्धांत नहीं देख सकता जिस तरह से मैं एक उपकरण के रूप में एक डिज़ाइन पेटर्न या एक फ्रेमवर्क देखता हूं।

— ट्यूलेंस कोर्डोवा

@ TulainsCórdova मेंटेनेंस, परफॉर्मेंस, करेक्टनेस, स्केलेबिलिटी - ये लक्ष्य हैं। ओपन-क्लोज्ड सिद्धांत उनके प्रति एक साधन है - कई में से एक। अगर यह इस पर लागू नहीं होता है या परियोजना के वास्तविक लक्ष्यों से अलग नहीं होगा, तो आपको खुले-बंद सिद्धांत की ओर कुछ करने की जरूरत नहीं है। आप किसी क्लाइंट को "ओपन-क्लोजनेस" नहीं बेचते हैं । एक मात्र दिशा-निर्देश के रूप में , यह अंगूठे के नियम से बेहतर नहीं है कि अगर आप अपनी बात को और अधिक पठनीय और स्पष्ट तरीके से करने का तरीका ढूंढते हैं, तो इसे छोड़ दिया जा सकता है। दिशानिर्देश उपकरण हैं, आखिरकार, अधिक कुछ नहीं।

— टी। सार।

@ T.Sar ऐसी बहुत सी चीजें हैं, जिन्हें आप किसी ग्राहक को नहीं बेच सकते ... दूसरी तरफ, मैं आपसे सहमत हूं कि आपको उन चीजों को नहीं करना चाहिए जो प्रोजेक्ट के लक्ष्यों से अलग हैं।

— ट्यूलेंस कोर्डोवा

Answer 2

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

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

OC भग्न है । यह आपके डिजाइन की सभी गहराइयों पर अपील करता है। हर कोई मानता है कि इसे केवल कक्षा स्तर पर लागू किया जाता है। लेकिन यह विधि स्तर पर या विधानसभा स्तर पर समान रूप से लागू है।

उचित स्तर पर OC का लगातार उल्लंघन यह सुझाव दे रहा है कि शायद रिफ्लेक्टर का समय आ गया है । "उचित स्तर" एक निर्णय कॉल है जिसमें आपके समग्र डिजाइन के साथ सब कुछ है।

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

Comments

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

— जियोर्जियो

यहाँ CodeReview उत्तर है जो विस्तार के लिए खुला दिखाता है । वह वर्ग डिजाइन विस्तार योग्य है। इसके विपरीत, एक विधि जोड़कर वर्ग को संशोधित किया जाता है।

— राडारबॉब

नए तरीकों को जोड़ने से एलएसपी का उल्लंघन होता है, ओसीपी का नहीं।

— ट्यूलेंस कोर्डोवा

नए तरीकों को जोड़ने से एलएसपी का उल्लंघन नहीं होता है । यदि आप एक विधि जोड़ने, तो आप एक शुरूआत की है जो नए इंटरफ़ेस @ TulainsCórdova

— RubberDuck

Answer 3

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

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

Comments

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

— जियोर्जियो

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

— जियोर्जियो

आपको लगता है कि वर्ग केवल आपके कोडबेस में उपयोग नहीं किया जाएगा। आपके द्वारा लिखी गई लाइब्रेरी का उपयोग अन्य परियोजनाओं में किया जा सकता है। इसलिए OCP महत्वपूर्ण है। इसके अलावा, एक नए प्रोग्रामर को कार्यक्षमता के साथ एक फैली हुई कक्षा के बारे में नहीं पता होना चाहिए कि उसे संचार / प्रलेखन समस्या है, न कि डिजाइन की समस्या।

— ट्यूलेंस कोर्डोवा

@ TulainsCórdova एप्लीकेशन कोड में यह प्रासंगिक नहीं है। लाइब्रेरी कोड के लिए मैं तर्क देता हूं कि शब्दार्थ संस्करण में ब्रेकिंग परिवर्तनों को संप्रेषित करने के लिए एक बेहतर फिट था।

— opsb

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

— आवश्यक है

Answer 4

आम आदमी के शब्दों में:

ए। ओ / सी सिद्धांत का मतलब है कि विशेषज्ञता को विस्तारित करने के लिए किया जाना चाहिए, विशेष आवश्यकताओं के लिए समायोजित करने के लिए एक वर्ग को संशोधित करके नहीं।

B. अनुपलब्ध (विशेषीकृत नहीं) कार्यक्षमता का अर्थ है कि डिज़ाइन पूर्ण नहीं था और आपको इसे आधार वर्ग में जोड़ना होगा, जाहिर है कि अनुबंध का उल्लंघन किए बिना। मुझे लगता है कि यह सिद्धांत का उल्लंघन नहीं है।

C. रिफ्लैक्टरिंग सिद्धांत का उल्लंघन नहीं करता है।

जब एक डिजाइन परिपक्व होता है , कहते हैं, उत्पादन के कुछ समय बाद:

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

Comments

खुला / बंद सिद्धांत बहुत गलत समझा गया है। आपके अंक A और B ठीक उसी तरह से मिलते हैं।

— gnasher729

Answer 5

मेरे लिए, ओपन-क्लोज्ड सिद्धांत एक दिशानिर्देश है, न कि एक कठिन और तेज़ नियम।

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

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

Answer 6

परिभाषा के अनुसार, रीफैक्टरिंग, व्यवहार को बदले बिना कोड संरचना को बदल रहा है। इसलिए जब आप रिफ्लेक्टर करते हैं, तो आप नई सुविधाओं को नहीं जोड़ते हैं।

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

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

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

परफेक्ट डिजाइन जैसी कोई चीज नहीं है। ऐसा कोई डिज़ाइन नहीं है जो सभी मौजूदा सिद्धांतों या पैटर्नों का सम्मान कर सके। यह यूटोपिया कोडिंग है।

मुझे उम्मीद है कि इस जवाब ने आपकी दुविधा में मदद की। जरूरत पड़ने पर स्पष्टीकरण मांगने के लिए स्वतंत्र महसूस करें।

Comments

"इसलिए जब आप रिफ्लेक्टर करते हैं, तो आप नई सुविधाओं को नहीं जोड़ते हैं।": लेकिन मैं एक परीक्षण किए गए सॉफ़्टवेयर में बगों को पेश कर सकता हूं।

— जियोर्जियो

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

— जियोर्जियो

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

— पटकोस सेबा

@ जियोर्जियो अगर कोड के विकास के रूप में Bकोड पर बनाया गया Aहै A, तो, जब Bजारी किया जाता है, Aको हटा दिया जाना चाहिए और फिर कभी उपयोग नहीं किया जाना चाहिए। पूर्व में उपयोग किए गए ग्राहक Aकेवल Bपरिवर्तन के बारे में जाने बिना उपयोग करेंगे , चूंकि इंटरफ़ेस Iनहीं बदला गया था (शायद यहां

— लिस्कोव सबस्टीट्यूशन

हां, यह वही है जो मेरे मन में था: जब तक आपके पास एक वैध (अच्छी तरह से परीक्षण) प्रतिस्थापन नहीं होता है तब तक काम कोड को फेंक न दें।

— जियोर्जियो

Answer 7

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