एक निर्माता में वैध "असली काम"?

Question

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

हालाँकि, मैं इससे जूझ रहा हूँ, लेकिन यह नोड ट्री का निर्माण है। यह पेड़ पूरी तरह से सरल "मूल्य" वस्तुओं से बना है जो स्वतंत्र रूप से परीक्षण करने की आवश्यकता नहीं होगी। (हालांकि, मैं अभी भी इन वस्तुओं के निर्माण के साथ सहायता करने के लिए ModelDef में एक सार फैक्टरी पारित कर सकता हूं।)

लेकिन मैं पढ़ता रहता हूं कि एक कंस्ट्रक्टर को कोई वास्तविक काम नहीं करना चाहिए (जैसे फ़्लाव: कंस्ट्रक्टर रियल वर्क करता है )। यह मेरे लिए एकदम सही समझ में आता है यदि "वास्तविक कार्य" का अर्थ है भारी-भरकम आश्रित वस्तुओं का निर्माण करना जो कि बाद में परीक्षण के लिए रोकना चाहते हैं। (जिन्हें डीआई के माध्यम से पारित किया जाना चाहिए।)

लेकिन इस नोड ट्री जैसे हल्के वजन वाले ऑब्जेक्ट के बारे में क्या? वृक्ष को कहीं पैदा करना है, है न? क्यों नहीं ModelDef (का उपयोग करते हुए, एक buildNodeTree () विधि) के निर्माता के माध्यम से?

मैं वास्तव में ModelDef के बाहर नोड ट्री नहीं बनाना चाहता हूं और फिर इसे (कंस्ट्रक्टर DI के माध्यम से) पास कर सकता हूं, क्योंकि स्कीमा को पार्स करके नोड ट्री बनाने के लिए एक महत्वपूर्ण मात्रा में जटिल कोड की आवश्यकता होती है - कोड जिसे पूरी तरह से जांचने की आवश्यकता होती है । मैं इसे "गोंद" कोड में नहीं बदलना चाहता हूं (जो अपेक्षाकृत तुच्छ होना चाहिए, और संभवतः सीधे परीक्षण नहीं किया जाएगा)।

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

Comments

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

— जेसन सी

संभावित डुप्लिकेट क्या किसी निर्माता में किसी वस्तु के काम करने का कोई कारण है?

— gnat

Answer 1

और, रॉस पैटरसन ने जो सुझाव दिया उसके अलावा, इस स्थिति पर विचार करें जो इसके ठीक विपरीत है:

1. नमक के एक दाने के साथ "थाउ शल्ट नॉट डू ए रियल वर्क इन थ्री कंस्ट्रक्टर्स" जैसे मैक्सिमम लें।

2. एक रचनाकार, वास्तव में, एक स्थिर विधि के अलावा और कुछ नहीं है। इसलिए, संरचनात्मक रूप से, वास्तव में बहुत अंतर नहीं है:

   a) एक साधारण कंस्ट्रक्टर और जटिल स्टेटिक फैक्ट्री विधियों का एक गुच्छा, और

   बी) एक साधारण कंस्ट्रक्टर और अधिक जटिल कंस्ट्रक्टर का एक गुच्छा।

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

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

इन सबके अलावा, व्यक्तिगत रूप से, मैं एक्सएमएल पार्सिंग लॉजिक को कंस्ट्रक्टर से बाहर ले जाऊंगा, इसलिए नहीं कि किसी कंस्ट्रक्टर में कॉम्प्लेक्स लॉजिक होना बुरा है, बल्कि इसलिए कि "सरोकारों के अलगाव" सिद्धांत का पालन करना अच्छा है। इसलिए, मैं XML पार्सिंग तर्क को कुछ अलग वर्ग में ले जाऊंगा, कुछ स्थिर तरीकों में नहीं जो आपकी ModelDefकक्षा के हैं।

संशोधन

मुझे लगता है कि अगर आपके पास एक ऐसी विधि है ModelDefजिसके बाहर ModelDefXML से निर्माण होता है , तो आपको कुछ गतिशील अस्थायी ट्री डेटा संरचना को तुरंत करने की आवश्यकता होगी, इसे अपने XML को पार्स करके पॉप्युलेट करें, और फिर ModelDefएक कंस्ट्रक्टर पैरामीटर के रूप में अपना नया पासिंग स्ट्रक्चर बनाएं । तो, कि शायद "बिल्डर" पैटर्न के एक आवेदन के रूप में सोचा जा सकता है। वहाँ आप क्या करना चाहते हैं और दोनों के बीच एक बहुत करीबी सादृश्य है Stringऔर StringBuilderजोड़ी। हालाँकि, मुझे यह Q & A मिला है, जो उन कारणों से असहमत है, जो मेरे लिए स्पष्ट नहीं हैं: Stackoverflow - StringBuilder और Builder Pattern । इसलिए, StringBuilder"बिल्डर" पैटर्न को लागू करता है या नहीं करता है , इस पर एक लंबी बहस से बचने के लिए , मैं कहूंगा कि यह कैसे प्रेरित होगाStrungBuilder एक समाधान के साथ आने में काम करता है जो आपकी आवश्यकताओं के अनुरूप होता है, और इसे "बिल्डर" पैटर्न के एक आवेदन को स्थगित करने तक कहा जाता है जब तक कि थोड़ा विस्तार नहीं किया गया हो।

इस ब्रांड का नया प्रश्न देखें: प्रोग्रामर SE: क्या "StringBuilder" बिल्डर डिज़ाइन पैटर्न का अनुप्रयोग है?

Comments

@RichardLevasseur मैं नब्बे के दशक की शुरुआत में C ++ प्रोग्रामर के बीच चिंता और बहस का विषय होने के नाते इसे याद करता हूं। यदि आप इस पोस्ट को देखते हैं : gotw.ca/gotw/066.htm आप देखेंगे कि यह काफी जटिल है, और काफी जटिल चीजें विवादास्पद हैं। मुझे निश्चित रूप से नहीं पता है, लेकिन मुझे लगता है कि नब्बे के दशक के शुरुआती दिनों में उस सामान को अभी तक मानकीकृत नहीं किया गया था। लेकिन क्षमा करें, मैं एक अच्छा संदर्भ प्रदान नहीं कर सकता।

— माइक नाकिस

@Gurtz मैं इस तरह के वर्ग को एप्लिकेशन-विशिष्ट "xml उपयोगिताओं" के रूप में सोचूंगा, क्योंकि xml फ़ाइल का प्रारूप (या दस्तावेज़ की संरचना) संभवतः उस विशेष एप्लिकेशन से बंधा हुआ है जिसे आप विकसित कर रहे हैं, किसी भी संभावनाओं की परवाह किए बिना। अपने "मॉडलडिफ" का पुन: उपयोग करें।

— माइक नाकिस

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

— माइक नाकिस

@ गर्ट्ज ने पहले "बिल्डर" दृष्टिकोण को संबोधित नहीं करने के लिए माफी मांगी। मैंने अपना उत्तर संशोधित कर दिया।

— माइक नाकिस

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

— जेसन C

Answer 2

आप पहले से ही इस काम को ModelDefकंस्ट्रक्टर में नहीं करने का सबसे अच्छा कारण देते हैं :

1. एक XML दस्तावेज़ को नोड ट्री में पार्स करने के बारे में "हल्का" कुछ भी नहीं है।
2. इस बारे में कुछ भी स्पष्ट नहीं है ModelDefकि यह केवल एक XML दस्तावेज़ से बनाया जा सकता है।

ऐसा लगता है कि आपकी कक्षा में विभिन्न प्रकार के स्थिर तरीके होने चाहिए ModelDef.FromXmlString(string xmlDocument), जैसे ModelDef.FromXmlDoc(XmlDoc parsedNodeTree), आदि।

Comments

उत्तर के लिए धन्यवाद! स्थिर तरीकों के सुझाव के बारे में। क्या ये स्थैतिक कारखाने होंगे जो मॉडलडिफ (विभिन्न xml स्रोतों से) का एक उदाहरण बनाते हैं? या वे पहले से निर्मित मॉडलडिफ ऑब्जेक्ट को लोड करने के लिए जिम्मेदार होंगे? यदि बाद में, मैं केवल आंशिक रूप से आरंभिक रूप से ऑब्जेक्ट होने के बारे में चिंतित हूँ (क्योंकि एक ModelDef को पूरी तरह से आरंभ करने के लिए नोड ट्री की आवश्यकता है)। विचार?

— गुर्ट्ज़

मेरे लिए ब्यूटिंग के लिए क्षमा करें, लेकिन हाँ, रॉस का मतलब स्थिर कारखाने के तरीके हैं जो पूरी तरह से निर्मित उदाहरण लौटाते हैं। पूर्ण प्रोटोटाइप कुछ इस तरह होगा public static ModelDef createFromXmlString( string xmlDocument )। यह काफी सामान्य प्रथा है। कभी-कभी मैं भी करता हूं। मेरा सुझाव है कि आप सिर्फ कंस्ट्रक्टर भी कर सकते हैं, उन परिस्थितियों में मेरी प्रतिक्रिया का एक मानक प्रकार है जहां मुझे संदेह है कि वैकल्पिक दृष्टिकोण को अच्छे कारण के बिना "कोषेर नहीं" के रूप में खारिज कर दिया गया है।

— माइक नाकिस

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

— गुर्ट्ज़

@ गर्तज बिल्कुल।

— रॉस पैटरसन

Answer 3

मैंने सुना है कि पहले "नियम"। मेरे अनुभव में यह सच और गलत दोनों है।

अधिक "क्लासिक" ऑब्जेक्ट ओरिएंटेशन में हम राज्य और व्यवहार को घेरने वाली वस्तुओं के बारे में बात करते हैं। इस प्रकार एक ऑब्जेक्ट कंस्ट्रक्टर को यह सुनिश्चित करना चाहिए कि ऑब्जेक्ट को एक वैध स्थिति में आरम्भ किया गया है (और एक गलती को इंगित करता है यदि प्रदान किए गए तर्क ऑब्जेक्ट को वैध नहीं बनाते हैं)। यह सुनिश्चित करना कि किसी वस्तु को एक मान्य स्थिति के लिए आरम्भ किया गया है, निश्चित है कि मेरे लिए वास्तविक कार्य जैसा लगता है। और इस विचार की योग्यता है, यदि आपके पास एक ऐसी वस्तु है जो केवल निर्माणकर्ता के माध्यम से एक वैध राज्य को आरंभीकरण की अनुमति देता है और ऑब्जेक्ट इसे ठीक से राज्य में बदल देता है ताकि राज्य को बदलने वाला प्रत्येक तरीका यह भी जांच ले कि यह राज्य को कुछ बुरा नहीं बदलता है ... तो सार में वह वस्तु गारंटी देती है कि यह "हमेशा मान्य" है। यह एक बहुत अच्छी संपत्ति है!

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

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

तो कौन सही है?

वास्तव में कोई नहीं। विचार के दोनों विद्यालयों में उनके गुण हैं। वर्तमान में SOLID सभी गुस्से में है और हर कोई SRP और Open / Closed और उस सभी जाज के बारे में बात कर रहा है। लेकिन सिर्फ इसलिए कि कुछ लोकप्रिय है इसका मतलब यह नहीं है कि यह हर एक आवेदन के लिए सही डिजाइन विकल्प है। तो यह निर्भर करता है। यदि आप एक कोड बेस में काम कर रहे हैं जो कि ठोस सिद्धांतों का पालन कर रहा है तो हां, कंस्ट्रक्टर में असली काम शायद एक बुरा विचार है। लेकिन अन्यथा, स्थिति को देखें और अपने निर्णय का उपयोग करने का प्रयास करें। कंस्ट्रक्टर में काम करने से आपकी वस्तु को क्या लाभ होता है, क्या गुण खोते हैं ? यह आपके एप्लिकेशन के समग्र आर्किटेक्चर के साथ कितना सही बैठता है?

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

Comments

यह एक शानदार जवाब है।

— जहाराली

Answer 4

इस नियम के साथ एक मूलभूत समस्या है और यह है कि , "वास्तविक कार्य" क्या है?

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

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

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

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

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