फ़ाइलों में विभाजन - कितना विभाजन?


9

अगर मैं कहता हूं कि मेरे पास एक घटक मॉडल के बजाय एक हाइरारच्ल इकाई ढांचा है। कुछ इस तरह:
(हाँ, यह बना हुआ है)

हथियार-> गन-> ऑटोमुनगुन-> एमपी ४४
या, एक शास्त्रीय उदाहरण के अधिक:
इकाई-> जंगम क्षमता-> दुश्मन-> चलना

आप पठनीयता और संगठन के लिए स्रोत / हेडर फ़ाइलों को कितनी दूर तक विभाजित करेंगे? क्या Entity.cpp, MovableEntity.cpp, Enemy.cpp, इत्यादि जैसे कुछ जाना सबसे अच्छा है या Entity.cpp [Entity और MovableEntity युक्त] और Enemy.cpp [दुश्मन और WalkingEnemy युक्त] बेहतर होगा? (या अधिक भाषा अज्ञेय तरीके से, एक शत्रु फ़ाइल और प्रत्येक वर्ग के लिए एक फ़ाइल बनाम एक इकाई फ़ाइल?)
इसके अलावा, क्या यह पठनीयता और संगठन के अलावा कुछ भी प्रभावित करेगा?


1
Nitpicky, लेकिन मुझे नहीं लगता कि language-agnosticयह एक उपयुक्त टैग है क्योंकि यह उस भाषा पर बहुत निर्भर करता है जिसे आप दुष्प्रभावों के रूप में उपयोग कर रहे हैं।
टेट्राद

अच्छी बात है, मुझे लगता है कि मैं रिटैग कर सकता हूं।
कम्युनिस्ट डक

जवाबों:


12

यह पूरी तरह से प्राथमिकता का विषय है। हालाँकि, मैं व्यक्तिगत रूप से यह मानता हूं कि अधिक फ़ाइलों के पक्ष में गलती करना सबसे अच्छा है। जावा को फ़ाइल के लिए एक वर्ग की आवश्यकता होती है , फ़ाइल नाम के साथ वर्ग नाम के समान, उदाहरण के लिए; वे इस अच्छे व्यवहार को लागू करने के लिए नीति द्वारा ऐसा करते हैं (हालांकि आपके पास उपवर्ग हो सकते हैं जो मूल रूप से इस के आसपास मिलते हैं)।

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

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


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

1
क्या आपके एनमों को समूहीकृत करने का मतलब यह नहीं है कि एक एकल मान को बदलने के कारण उस नामस्थान में एक एनुम का उपयोग करने वाली हर फ़ाइल का पुन: उपयोग होगा?
कम्युनिस्ट डक

खैर, यह वास्तव में भाषा पर निर्भर करता है, लेकिन हां, इसका प्रभाव निश्चित रूप से हो सकता है। यह वास्तव में मेरे लिए कोई समस्या नहीं है, क्योंकि मैं मुख्य रूप से C # (कोई फ़ाइल-दर-फ़ाइल संकलन) में विकसित नहीं हुआ हूं, लेकिन यह C ++ और अन्य भाषाओं में समस्याग्रस्त हो सकता है। हमेशा की तरह, विचार करने के लिए भाषा-विशिष्ट कारक हैं, और यह उनमें से एक होगा :)।
माइक स्ट्रोबेल

2

C / C ++ के बाहर की कई भाषाएं फाइलों पर अड़चन डालती हैं। रिक ने जावा के 'एक वर्ग प्रति फ़ाइल' का उल्लेख किया; पायथन नामस्थान के रूप में फ़ाइलों का उपयोग करता है; अन्य भाषाएं अक्सर उन लोगों की भावना की नकल करती हैं।

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

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

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


मैं एक उदाहरण के रूप में पदानुक्रम का उपयोग कर रहा था; मुझे लगा कि इसने इस बात पर जोर दिया है कि मेरा क्या मतलब है। वास्तविक कोड में, मैं घटकों की ओर प्रयास कर रहा हूं।
कम्युनिस्ट डक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.