एक कक्षा के लिए कितना बड़ा है?

Question

मैं लंबे समय से डेवलपर हूं (मैं 49 वर्ष का हूं) लेकिन ऑब्जेक्ट ओरिएंटेड डेवलपमेंट के लिए नया हूं। मैं बर्ट्रेंड मेयर्स एफिल के बाद से ओओ के बारे में पढ़ रहा हूं, लेकिन वास्तव में बहुत कम ओओ प्रोग्रामिंग किया है।

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

इसलिए वे आम तौर पर कुछ ऐसा करते हैं जैसे "बेहतर मॉडल जितना बेहतर वह आवेदन में वस्तु का प्रतिनिधित्व करता है और उतना ही बेहतर होता है।"

अब तक बहुत अच्छा है, लेकिन, दूसरी ओर, मैंने कई लेखकों को पाया है कि "एक वर्ग को केवल एक पृष्ठ में फिट होना चाहिए" जैसे व्यंजनों को देते हैं "(मैं क्या मॉनिटर के आकार पर" जोड़ूंगा? अब हम कोशिश करेंगे कि नहीं? कोड प्रिंट करने के लिए!)।

उदाहरण के लिए एक PurchaseOrderवर्ग लें , जिसमें एक परिमित राज्य मशीन है जो उसके व्यवहार को नियंत्रित करती है और एक संग्रह है PurchaseOrderItem, यहाँ काम पर एक तर्क यह है कि हमें एक PurchaseOrderसाधारण वर्ग का उपयोग करना चाहिए , कुछ विधियों के साथ (डेटा वर्ग से थोड़ा अधिक), और है एक PurchaseOrderFSM"विशेषज्ञ वर्ग" जो के लिए परिमित राज्य मशीन को संभालता है PurchaseOrder।

मैं कहूंगा कि जेफ एटवुड के कोड स्मोल्स के कोडिंग हॉरर पर "फीचर ईर्ष्या" या "अनुचित अंतरंगता" वर्गीकरण में आता है । मैं इसे सामान्य ज्ञान कहूंगा। यदि मैं अपने वास्तविक खरीद आदेश को जारी कर सकता हूं, अनुमोदित कर सकता हूं या रद्द कर सकता हूं, तो PurchaseOrderकक्षा होनी चाहिए issuePO, approvePOऔर cancelPOविधियां।

क्या यह "अधिकतम सामंजस्य" और "पुराने युगलों को कम करने वाले" पुराने सिद्धांतों के साथ नहीं जाता है जिन्हें मैं OO के कोने के रूप में समझता हूं?

इसके अलावा, क्या यह कक्षा की स्थिरता को बनाए रखने में मदद नहीं करता है?

Comments

विधि नाम में टाइपनेम को एनकोड करने का कोई कारण नहीं है। यानी अगर आपके पास PurchaseOrderहै, तो आप सिर्फ अपने तरीकों नाम दे सकते हैं issue, approve, और cancel। POप्रत्यय केवल नकारात्मक मूल्य कहते हैं।

— डैश-टॉम-बैंग

जब तक आप ब्लैक होल विधियों से दूर रहते हैं , तब तक आपको ठीक होना चाहिए। :)

— मार्क सी

अपने वर्तमान स्क्रीन रिज़ॉल्यूशन के साथ, मैं 145 चरित्रों को बड़ा कहूंगा।

— DavRob60

आपकी टिप्पणियों के लिए सभी को धन्यवाद, उन्होंने वास्तव में इस मुद्दे पर मेरी मदद की। यदि इस साइट ने मुझे अनुमति दी है तो मैंने TMN और लाजर का उत्तर भी चुना होगा, लेकिन यह केवल एक की अनुमति देता है, इसलिए यह क्रेग के पास गया। सादर।

— मिगुएल वेलोसो

Answer 1

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

Comments

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

— मिगुएल वेलोसो

एक बहुत अच्छा और रसीला जवाब के लिए +1। वास्तविक रूप से, एक वर्ग कितना बड़ा होना चाहिए, इसका कोई निश्चित उपाय नहीं हो सकता है। SRP सुनिश्चित उस वर्ग केवल के रूप में बड़े रूप में यह है को लागू करने की जरूरत है हो सकता है।

— S.Robins

@MiguelVeloso - पीओ को स्वीकृत करना संभवतः पीओ जारी करने की तुलना में अलग तर्क और नियम सहयोगी है। यदि हां, तो यह एक POApprover और POIssuer में जिम्मेदारियों को अलग करने के लिए समझ में आता है। विचार यह है कि यदि नियम एक के लिए बदल जाते हैं, तो आप उस वर्ग के साथ गड़बड़ क्यों करना चाहेंगे जिसमें दूसरा है।

— मैथ्यू फ्लिन

Answer 2

मेरी राय में वर्ग आकार तब तक मायने नहीं रखता है जब तक कि चर, कार्य और विधियां प्रश्न में वर्ग के लिए प्रासंगिक हैं।

Comments

दूसरी ओर, बड़े आकार से संकेत मिलता है कि वे विधियां संभवतः विचाराधीन वर्ग के लिए प्रासंगिक नहीं हैं।

— बिली ओनली

@ बिली: मैं कहूंगा कि बड़ी कक्षाएं एक कोड गंध हैं, लेकिन वे स्वचालित रूप से खराब नहीं हैं।

— डेविड थॉर्नले

@ डेविड: यही कारण है कि वहां "शायद" शब्द है - यह महत्वपूर्ण है :)

— बिली ओनेल

मुझे असहमत होना पड़ेगा ... मैं एक ऐसी परियोजना पर काम करता हूं जिसमें एक बहुत सुसंगत नामकरण सम्मेलन है और चीजें अच्छी तरह से रखी गई हैं ... लेकिन मेरे पास अभी भी एक वर्ग है जो कोड की 50k लाइनें है। यह सिर्फ बहुत बड़ा है :)

— जे। जे।

यह उत्तर ठीक दिखाता है कि "नरक की सड़क" कैसे जाती है - यदि कोई वर्ग की जिम्मेदारियों को प्रतिबंधित नहीं करता है, तो कई चर, कार्य और विधियां कक्षा के लिए प्रासंगिक हो जाएंगी - और यह आसानी से उनमें से बहुत से होने की ओर जाता है।

— डॉक्टर ब्राउन

Answer 3

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

आपकी कार सादृश्य के लिए, यदि कक्षा carबहुत बड़ी है, तो यह संभवतः एक संकेत है कि इसे वर्ग engine, वर्ग doorएस, और कक्षा वर्ग windshield, आदि में विभाजित करने की आवश्यकता है ।

Comments

और भूल जाते हैं कि एक कार को वाहन इंटरफ़ेस को लागू नहीं करना चाहिए। :-)

— क्रिस

Answer 4

मुझे नहीं लगता कि एक वर्ग की एक विशिष्ट परिभाषा बहुत बड़ी है। हालाँकि, मैं निम्नलिखित दिशा-निर्देशों का उपयोग यह निर्धारित करने के लिए करूँगा कि मुझे अपनी कक्षा को फिर से तैयार करना चाहिए या कक्षा के दायरे को फिर से परिभाषित करना चाहिए:

1. क्या कई चर हैं जो एक दूसरे से स्वतंत्र हैं? (ज्यादातर मामलों में मेरी व्यक्तिगत सहिष्णुता लगभग 10 ~ 20 है)
2. क्या कोने के मामलों के लिए कई तरीके तैयार किए गए हैं? (मेरी व्यक्तिगत सहिष्णुता है ... ठीक है, यह बहुत हद तक मेरे मनोदशा पर निर्भर करता है)

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

2 के संबंध में, कल्पना करें कि आप उन सभी व्यवहारों को परिभाषित करने का प्रयास करते हैं जो एक कार में कक्षा में हो सकते हैं car, लेकिन car::open_roof()केवल कन्वर्टिबल के लिए उपलब्ध होंगे, और car::open_rear_door()उन 2-डोर कारों पर लागू नहीं होते हैं। हालाँकि, कन्वर्टिबल और 2-डोर कार परिभाषा के अनुसार "कार" हैं, उन्हें कक्षा में लागू करने से कक्षा carजटिल हो जाती है। कक्षा का उपयोग करना कठिन हो जाता है और बनाए रखना कठिन हो जाता है।

इन 2 दिशानिर्देशों के अलावा, मैं कक्षा के दायरे की स्पष्ट परिभाषा सुझाऊंगा। एक बार जब आप दायरे को परिभाषित करते हैं, तो परिभाषा के आधार पर कक्षा को सख्ती से लागू करें। अधिकांश समय, लोगों को एक "बहुत बड़ा" वर्ग मिलता है क्योंकि गुंजाइश की खराब परिभाषा के कारण, या मनमाने ढंग से सुविधाओं के कारण वर्ग में जोड़ा जाता है

Answer 5

कहें कि आपको 300 लाइनों में क्या चाहिए

नोट: अंगूठे का यह नियम मानता है कि आप 'फाइल प्रति एक वर्ग' दृष्टिकोण का पालन कर रहे हैं जो अपने आप में एक अच्छा रख-रखाव विचार है

यह एक पूर्ण नियम नहीं है, लेकिन अगर मुझे एक कक्षा में 200 से अधिक कोड की लाइनें दिखती हैं तो मुझे संदेह है। 300 लाइनें और चेतावनी घंटियाँ आती हैं। जब मैं किसी और के कोड को खोलता हूं और 2000 लाइनें ढूंढता हूं, तो मुझे पता है कि यह पहले पृष्ठ को पढ़े बिना भी समय को वापस ला रहा है।

ज्यादातर यह स्थिरता के लिए नीचे आता है। यदि आप वस्तु इतनी जटिल है कि आप 300 लाइनों में उसके व्यवहार को व्यक्त नहीं कर सकते हैं, तो किसी अन्य व्यक्ति को समझना बहुत मुश्किल होगा।

मुझे लग रहा है कि मैं इस नियम को मॉडल में झुका रहा हूं -> ViewModel -> दुनिया को देखता हूं जहां मैं UI पृष्ठ के लिए एक 'व्यवहार ऑब्जेक्ट' बना रहा हूं क्योंकि व्यवहार की पूरी श्रृंखला का वर्णन करने में अक्सर 300 से अधिक लाइनें लगती हैं एक पन्ना। हालाँकि, मैं अभी भी इस प्रोग्रामिंग मॉडल के लिए नया हूँ और पृष्ठों / viewmodels के बीच व्यवहार / पुन: उपयोग करने के अच्छे तरीके ढूंढ रहा हूं जो धीरे-धीरे मेरे ViewModels के आकार को कम कर रहा है।

Comments

मेरी व्यक्तिगत गाइडलाइन भी लगभग 300 लाइनों की है। +1

— मार्की

मुझे लगता है कि ओपी एक न्यायवादी की तलाश कर रहा है, और यह एक अच्छा है।

— नेवतापीर 22

धन्यवाद, यह दिशानिर्देश के रूप में सटीक संख्याओं का उपयोग करने के लिए मूल्यवान है।

— शेपर्ड

Answer 6

आइये इसे पिछड़े:

क्या यह "अधिकतम सामंजस्य" और "पुराने युगलों को कम करने वाले" पुराने सिद्धांतों के साथ नहीं जाता है जिन्हें मैं OO के कोने के रूप में समझता हूं?

दरअसल, यह प्रोग्रामिंग की आधारशिला है, जिसमें से OO एक प्रतिमान है।

मैं एंटोनी डी सेंट-एक्सुप्री को आपके प्रश्न का उत्तर दूंगा (क्योंकि मैं आलसी हूं;))।

पूर्णता तब प्राप्त होती है, जब जोड़ने के लिए और कुछ नहीं होता है, लेकिन जब लेने के लिए कुछ नहीं बचता है।

कक्षा जितनी सरल होगी, आप उतना ही अधिक आत्मविश्वास से सही होंगे, इसे पूरी तरह से परखना आसान होगा ।

Answer 7

मैं फीचर एनवी वर्गीकरण पर ओपी के साथ हूं। कुछ भी मुझे परेशान नहीं करता है वर्गों के एक झुंड के साथ तरीकों का एक गुच्छा है जो कुछ अन्य वर्ग के आंतरिक पर काम करता है। OO बताता है कि आप डेटा और उस डेटा के संचालन को मॉडल करते हैं। इसका मतलब यह नहीं है कि आपने ऑपरेशन को डेटा से अलग जगह पर रखा है! यह आपको डेटा और उन तरीकों को एक साथ लाने की कोशिश कर रहा है ।

carऔर personप्रचलित मॉडल के साथ , यह विद्युत कनेक्शन बनाने के लिए कोड डालने या स्टार्टर को personकक्षा में घूमने के समान होगा । मुझे उम्मीद है कि यह किसी भी अनुभवी प्रोग्रामर के लिए स्पष्ट रूप से गलत होगा ।

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

Comments

+1 - अंगूठे के अच्छे नियम लेकिन इसके बारे में सत्तावादी नहीं होना। मैं फिर भी कहूंगा कि सिर्फ इसलिए कि एक वर्ग टूट गया है इसका मतलब यह नहीं है कि विभिन्न वर्गों को एक-दूसरे के निजी सदस्यों को छूना चाहिए।

— बिली ओनेल

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

— डैश-टॉम-बैंग

Answer 8

जब एक वर्ग परिभाषा में कुछ सौ विधियाँ होती हैं, तो यह बहुत बड़ी है।

Answer 9

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

Answer 10

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

कोई भी जो विधि / वर्ग आकार के लिए "नियम" को आगे बढ़ाता है, उसने स्पष्ट रूप से वास्तविक दुनिया में पर्याप्त समय नहीं बिताया है। जैसा कि दूसरों ने उल्लेख किया है, यह अक्सर एक रिफलेक्टरिंग संकेतक होता है, लेकिन कभी-कभी (विशेष रूप से "डेटा प्रोसेसिंग" -टाइप कार्य) में आपको वास्तव में एक एकल विधि के साथ एक वर्ग लिखने की आवश्यकता होती है जो 500+ लाइनों को फैलाता है। उस पर लटका मत करो।

Comments

मुझे लगता है कि POManager "कंट्रोलर" होगा और PurchaseOrder MVC पैटर्न में "मॉडल" होगा, है ना?

— मिगेल वेलोसो

Answer 11

मुझे ऐसे कई लेखक मिले हैं जो रेसिपी देते हैं जैसे "एक वर्ग को एक ही पृष्ठ में फिट होना चाहिए"

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

इसलिए वे आम तौर पर कुछ ऐसा करते हैं जैसे "बेहतर मॉडल जितना बेहतर वह आवेदन में वस्तु का प्रतिनिधित्व करता है और उतना ही बेहतर होता है।"

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

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

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

Answer 12

यह काम करने के लिए सभी आवश्यक तर्क सम्‍मिलित करने के लिए काफी बड़ा है।

अनुरक्षण योग्य होने के लिए छोटा और एकल जिम्मेदारी सिद्धांत का पालन करें ।