क्या मैं अपनी कक्षाओं को भी दानेदार बना रहा हूँ? एकल जिम्मेदारी सिद्धांत कैसे लागू किया जाना चाहिए?

Question

मैं बहुत सारे कोड लिखता हूं जिसमें तीन बुनियादी चरण शामिल हैं।

1. कहीं से डेटा मिलता है।
2. उस डेटा को ट्रांसफॉर्म करें।
3. वह डेटा कहीं रख दें।

मैं आमतौर पर तीन प्रकार की कक्षाओं का उपयोग करके समाप्त होता हूं - उनके संबंधित डिजाइन पैटर्न से प्रेरित।

1. कारखानों - कुछ संसाधन से एक वस्तु का निर्माण करने के लिए।
2. मध्यस्थ - कारखाने का उपयोग करने के लिए, परिवर्तन का प्रदर्शन करें, फिर कमांडर का उपयोग करें।
3. कमांडर - उस डेटा को कहीं और लगाने के लिए।

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

जहां मैं संघर्ष करता हूं जब मैं परीक्षण करने आता हूं, तो मैं अंत में कसकर युग्मित परीक्षण करता हूं। उदाहरण के लिए;

• फैक्टरी - डिस्क से फाइल पढ़ता है।
• कमांडर - डिस्क पर फाइलें लिखता है।

मैं एक के बिना एक परीक्षण नहीं कर सकता। मैं डिस्क पढ़ने / लिखने के लिए अतिरिक्त 'टेस्ट' कोड भी लिख सकता था, लेकिन फिर मैं खुद को दोहरा रहा हूं।

.Net को देखते हुए, फ़ाइल वर्ग एक अलग दृष्टिकोण लेता है, यह जिम्मेदारियों (मेरे) कारखाने और कमांडर को एक साथ जोड़ता है। इसमें एक ही जगह पर Create, Delete, Exists, और Read सभी के लिए फ़ंक्शन हैं।

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

यहाँ मेरा मुद्दा यह है कि मैंने सिंगल रिस्पॉन्सिबिलिटी प्रिंसिपल को कुछ हद तक अधिक लापरवाही से लागू किया है? मेरे पास पढ़ने और लिखने के लिए अलग-अलग कक्षाएं हैं। जब मेरे पास एक संयुक्त वर्ग हो सकता है जो किसी विशेष संसाधन, जैसे सिस्टम डिस्क से निपटने के लिए जिम्मेदार है।

Comments

यह सुनिश्चित करने के लिए कि एक वर्ग एकल जिम्मेदारी सिद्धांत

— gnat

Looking at .Net, the File class takes a different approach, it combines the responsibilities (of my) factory and commander together. It has functions for Create, Delete, Exists, and Read all in one place.- ध्यान दें कि आप "जिम्मेदारी" का सामना "करने की चीज़" के साथ कर रहे हैं। एक जिम्मेदारी "चिंता का क्षेत्र" की तरह है। फ़ाइल वर्ग की जिम्मेदारी फ़ाइल संचालन कर रही है।

— रॉबर्ट हार्वे

यह मुझे लगता है कि आप अच्छे आकार में हैं। आप सभी की जरूरत है एक परीक्षण मध्यस्थ है (या हर प्रकार के रूपांतरण के लिए यदि आप इसे बेहतर पसंद करते हैं)। परीक्षण मध्यस्थ अपने .net फ़ाइल वर्ग का उपयोग करके, अपनी शुद्धता को सत्यापित करने के लिए फाइलें पढ़ सकते हैं। एक ठोस दृष्टिकोण से इसके साथ कोई समस्या नहीं है।

— मार्टिन मेट

जैसा कि @Robert हार्वे ने उल्लेख किया है, SRP का एक भद्दा नाम है क्योंकि यह वास्तव में जिम्मेदारियों के बारे में नहीं है। यह "चिंता का एक मुश्किल / मुश्किल क्षेत्र को बदलना और बदलना जो बदल सकता है" के बारे में है। मुझे लगता है कि STDACMC बहुत लंबी थी। :-) उस ने कहा, मुझे लगता है कि आपका विभाजन तीन भागों में उचित है।

— 229 में user949300

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

— एंडी

Answer 1

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

कमांड क्वेरी जिम्मेदारी अलगाव

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

आपने परीक्षण के बारे में चिंता व्यक्त की है। मुझे नहीं लगता कि निम्नलिखित CQRS परीक्षण कोड लिखने को रोकता है। आप बस एक तरह से CQRS का अनुसरण कर सकते हैं जो आपके कोड को परीक्षण योग्य नहीं बनाता है।

यह जानने में मदद करता है कि नियंत्रण के प्रवाह को बदलने की आवश्यकता के बिना स्रोत कोड निर्भरता को उलटने के लिए बहुरूपता का उपयोग कैसे करें। मुझे वास्तव में यकीन नहीं है कि आपका कौशल सेट परीक्षण लिखने पर कहां है।

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

यह कहना नहीं है कि CQRS का पालन नहीं करने वाले पूरी तरह से वैध उदाहरण नहीं हैं। इसका पालन करना हमेशा थोड़ा दर्द होगा। यह हमेशा भुगतान के लायक नहीं है। लेकिन अगर आपको जरूरत है तो आपको खुशी होगी कि आपने इसका इस्तेमाल किया।

यदि आप इसका उपयोग करते हैं तो चेतावनी के इस शब्द का उपयोग करें:

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

मार्टिन फ्लोवर: CQRS

Comments

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

— जेम्स वुड

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

— वाल्फ्रैट

Answer 2

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

कहते हैं कि आप XML फ़ाइल में एप्लिकेशन डेटा संग्रहीत करते हैं। पढ़ने या लिखने से संबंधित कोड बदलने के लिए कौन से कारण हो सकते हैं? कुछ संभावनाएँ:

• जब एप्लिकेशन में नई सुविधाएँ जोड़ी जाती हैं तो एप्लिकेशन डेटा मॉडल बदल सकता है।
• नए प्रकार के डेटा - उदाहरण के चित्र - मॉडल में जोड़े जा सकते हैं
• स्टोरेज फॉर्मेट को एप्लिकेशन लॉजिक से स्वतंत्र बदला जा सकता है: इंटरऑपरेबिलिटी या प्रदर्शन चिंताओं के कारण XML से JSON या बाइनरी फॉर्मेट में कहें।

इन सभी मामलों में, आपको रीडिंग और राइटिंग लॉजिक दोनों को बदलना होगा । दूसरे शब्दों में, वे अलग-अलग जिम्मेदारियां नहीं हैं ।

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

नीचे पंक्ति: आप सामान्य रूप से यह नहीं कह सकते हैं कि यदि फाइल पढ़ना और लिखना अलग-अलग ज़िम्मेदारियाँ हैं, तो यह अनुप्रयोग की भूमिकाओं पर निर्भर करता है। लेकिन परीक्षण के बारे में आपके संकेत के आधार पर, मुझे लगता है कि यह आपके मामले में एक ही जिम्मेदारी है।

Answer 3

आम तौर पर आपके पास सही विचार है।

कहीं से डेटा मिलता है। उस डेटा को ट्रांसफॉर्म करें। वह डेटा कहीं रख दें।

लगता है कि आप तीन जिम्मेदारियाँ हैं। IMO "मध्यस्थ" बहुत कुछ कर सकता है। मुझे लगता है कि आपको अपनी तीन ज़िम्मेदारियों को निभाना शुरू करना चाहिए:

interface Reader[T] {
    def read(): T
}

interface Transformer[T, U] {
    def transform(t: T): U
}

interface Writer[T] {
    def write(t: T): void
}

तब एक कार्यक्रम के रूप में व्यक्त किया जा सकता है:

def program[T, U](reader: Reader[T], 
                  transformer: Transformer[T, U], 
                  writer: Writer[U]): void =
    writer.write(transformer.transform(reader.read()))

इससे वर्गों का प्रसार होता है

मुझे नहीं लगता कि यह कोई समस्या है। IMO बहुत सारे छोटे कोष्ठक, परीक्षण योग्य वर्ग बड़े, कम-कोशिक्टिव वर्गों की तुलना में बेहतर होते हैं।

जहां मैं संघर्ष करता हूं जब मैं परीक्षण करने आता हूं, तो मैं अंत में कसकर युग्मित परीक्षण करता हूं। मैं एक के बिना एक परीक्षण नहीं कर सकता।

प्रत्येक टुकड़ा स्वतंत्र रूप से परीक्षण योग्य होना चाहिए। ऊपर मॉडलिंग की गई है, आप एक फ़ाइल में पढ़ने / लिखने का प्रतिनिधित्व कर सकते हैं:

class FileReader(fileName: String) implements Reader[String] {
    override read(): String = // read file into string
}

class FileWriter(fileName: String) implements Writer[String] {
    override write(str: String) = // write str to file
}

फाइल सिस्टम पर पढ़ने और लिखने के लिए आप इन कक्षाओं के परीक्षण के लिए एकीकरण परीक्षण लिख सकते हैं। बाकी तर्क को परिवर्तन के रूप में लिखा जा सकता है। उदाहरण के लिए यदि फाइलें JSON फॉर्मेट की हैं, तो आप s को बदल सकते हैं String।

class JsonParser implements Transformer[String, Json] {
    override transform(str: String): Json = // parse as json
}

तब आप उचित वस्तुओं में बदल सकते हैं:

class FooParser implements Transformer[Json, Foo] {
    override transform(json: Json): Foo = // ...
}

इनमें से प्रत्येक स्वतंत्र रूप से परीक्षण योग्य है। आप programमॉकिंग और reader, द्वारा उपरोक्त टेस्ट भी कर सकते हैं ।transformerwriter

Comments

यह बहुत ज्यादा है जहाँ मैं अभी हूँ। मैं प्रत्येक फ़ंक्शन को व्यक्तिगत रूप से परीक्षण कर सकता हूं, हालांकि परीक्षण करके वे युग्मित हो जाते हैं। जैसे कि FileWriter का परीक्षण किया जाना है, तो कुछ और पढ़ना है जो लिखा गया था, स्पष्ट समाधान FileReader का उपयोग कर रहा है। Fwiw, मध्यस्थ अक्सर कुछ और करते हैं जैसे व्यवसाय तर्क को लागू करते हैं या शायद मूल एप्लिकेशन मुख्य फ़ंक्शन द्वारा दर्शाए जाते हैं।

— जेम्स वुड

@JamesWood अक्सर एकीकरण परीक्षण के साथ मामला है। हालाँकि आपको परीक्षण में कक्षाएं जोड़ी नहीं हैं । आप FileWriterउपयोग करने के बजाय सीधे फाइलसिस्टम से पढ़कर परीक्षण कर सकते हैं FileReader। यह वास्तव में आपके ऊपर है कि आपके लक्ष्य क्या हैं। आप का उपयोग करते हैं FileReader, परीक्षण करता है, तो या तो टूट जाएगा FileReaderया FileWriterटूट गया है - जो डिबग करने के लिए और अधिक समय लग सकता है।

— शमूएल

इसके अलावा देखें stackoverflow.com/questions/1087351/… यह आपके परीक्षणों को अच्छा बनाने में मदद कर सकता है

— सैमुअल

यह बहुत ज्यादा है जहाँ मैं अभी हूँ - यह 100% सच नहीं है। आपने कहा कि आप मध्यस्थ पैटर्न का उपयोग कर रहे हैं। मुझे लगता है कि यह यहाँ उपयोगी नहीं है; इस पैटर्न का उपयोग तब किया जाता है जब आपके पास बहुत से अलग-अलग ऑब्जेक्ट होते हैं जो एक दूसरे के साथ बहुत भ्रमित प्रवाह में बातचीत करते हैं; आप सभी रिश्तों को सुविधाजनक बनाने और उन्हें एक जगह लागू करने के लिए वहां एक मध्यस्थ रखते हैं। ऐसा लगता है कि यह आपका मामला नहीं है; आपकी छोटी इकाइयाँ बहुत अच्छी तरह से परिभाषित हैं। इसके अलावा, @Samuel द्वारा ऊपर की टिप्पणी की तरह, आपको एक इकाई का परीक्षण करना चाहिए, और अन्य इकाइयों को कॉल किए बिना अपना दावा करना चाहिए

— Emerson Cardoso

@EmersonCardoso; मैंने अपने प्रश्न में परिदृश्य को सरल बनाया है। जबकि मेरे कुछ मध्यस्थ काफी सरल हैं, अन्य अधिक जटिल हैं और अक्सर कई कारखानों / कमांडरों का उपयोग करते हैं। मैं एक एकल परिदृश्य के विस्तार से बचने की कोशिश कर रहा हूं, मैं उच्च स्तर की डिजाइन वास्तुकला में अधिक रुचि रखता हूं जिसे कई परिदृश्यों पर लागू किया जा सकता है।

— जेम्स वुड

Answer 4

मैं अंत में कसकर युग्मित परीक्षण करूंगा। उदाहरण के लिए;

• फैक्टरी - डिस्क से फाइल पढ़ता है।
• कमांडर - डिस्क पर फाइलें लिखता है।

तो यहाँ ध्यान केंद्रित है कि उन्हें एक साथ युग्मित करना क्या है । क्या आप दोनों के बीच एक वस्तु को पास करते हैं (जैसे कि File?) तो यह वह फाइल है जिसके साथ वे एक-दूसरे से जुड़े हैं।

आपने जो कहा है उससे आपने अपनी कक्षाएं अलग कर ली हैं। जाल यह है कि आप उन्हें एक साथ परीक्षण कर रहे हैं क्योंकि यह आसान है या 'समझ में आता है' ।

आपको Commanderडिस्क से आने के लिए इनपुट की आवश्यकता क्यों है ? इसके बारे में सभी को एक निश्चित इनपुट का उपयोग करते हुए लिखना है, फिर आप यह सत्यापित कर सकते हैं कि परीक्षण में क्या है इसका उपयोग करके फ़ाइल को सही ढंग से लिखा है ।

जिस वास्तविक भाग का आप परीक्षण कर रहे हैं, Factoryवह है 'क्या यह इस फ़ाइल को सही ढंग से पढ़ेगा और सही चीज़ का उत्पादन करेगा'? इसलिए टेस्ट में पढ़ने से पहले फाइल को मॉक कर दें ।

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

Comments

उस विशेष उदाहरण में वह चीज़ जो उन्हें एक साथ जोड़ती है वह है संसाधन - जैसे सिस्टम डिस्क। अन्यथा दोनों वर्गों के बीच कोई बातचीत नहीं है।

— जेम्स वुड

Answer 5

कहीं से डेटा मिलता है। उस डेटा को ट्रांसफॉर्म करें। वह डेटा कहीं रख दें।

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

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

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

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

class FinanceTransaction
{
    private $id;
    private $storage;

    public function __construct(UUID $id, DataStorage $storage)
    {
        $this->id = $id;
        $this->storage = $storage;
    }

    public function perform(
        Order $order,
        Customer $customer,
        Merchant $merchant
    )
    {
        if ($order->isExpired()) {
            throw new Exception('Order expired');
        }

        if ($customer->canNotPurchase($order)) {
            throw new Exception('It is not legal to purchase this kind of stuff by this customer');
        }

        $this->storage->save($this->id, $order, $customer, $merchant);
    }
}

(new FinanceTransaction())
    ->perform(
        new Order(
            new Product(
                $_POST['product_id']
            ),
            new Card(
                new CardNumber(
                    $_POST['card_number'],
                    $_POST['cvv'],
                    $_POST['expires_at']
                )
            )
        ),
        new Customer(
            new Name(
                $_POST['customer_name']
            ),
            new Age(
                $_POST['age']
            )
        ),
        new Merchant(
            new MerchantId($_POST['merchant_id'])
        )
    )
;

नतीजतन कुछ कार्यक्षमता का प्रतिनिधित्व करने वाले कुछ कोशिक्टिव वर्ग हैं। ध्यान दें कि सत्यापन आमतौर पर मूल्य-वस्तुओं पर जाता है - कम से कम डीडीडी दृष्टिकोण में।

Answer 6

जहां मैं संघर्ष करता हूं जब मैं परीक्षण करने आता हूं, तो मैं अंत में कसकर युग्मित परीक्षण करता हूं। उदाहरण के लिए;

• फैक्टरी - डिस्क से फाइल पढ़ता है।
• कमांडर - डिस्क पर फाइलें लिखता है।

फ़ाइल सिस्टम के साथ काम करते समय टपका हुआ सार देखने के लिए देखें - मैंने इसे अक्सर उपेक्षित तरीके से देखा, और इसमें आपके द्वारा वर्णित लक्षण हैं।

यदि वर्ग उन डेटा पर काम करता है जो इन फाइलों से आता है / इन फाइलों में चला जाता है तो फाइल सिस्टम कार्यान्वयन विस्तार (I / O) हो जाता है और इसे इससे अलग कर देना चाहिए। इन वर्गों (कारखाने / कमांडर / मध्यस्थ) को फाइल सिस्टम के बारे में पता नहीं होना चाहिए जब तक कि उनका एकमात्र काम प्रदान किए गए डेटा को संग्रहीत / पढ़ना नहीं है। कक्षाएं जो फ़ाइल सिस्टम से निपटती हैं, उन्हें संदर्भ विशिष्ट मापदंडों जैसे कि पथ (निर्माणकर्ता के माध्यम से पारित किया जा सकता है) को अतिक्रमण करना चाहिए, इसलिए इंटरफ़ेस ने अपनी प्रकृति प्रकट नहीं की (इंटरफ़ेस नाम में "फ़ाइल" एक समय की सबसे अधिक गंध है)।

Comments

"इन वर्गों (कारखाने / कमांडर / मध्यस्थ) को फ़ाइल सिस्टम के बारे में पता नहीं होना चाहिए जब तक कि उनका एकमात्र काम प्रदान किए गए डेटा को संग्रहीत / पढ़ना न हो।" इस विशेष उदाहरण में, यह सब वे कर रहे हैं।

— जेम्स वुड

Answer 7

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

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

आप डेटा के पढ़ने / लिखने को अमूर्त करने पर भी गौर कर सकते हैं। अब आप एक फ़ाइल सिस्टम पर जा रहे हैं, लेकिन भविष्य में किसी डेटाबेस या किसी सॉकेट में भी जाना चाहते हैं। यदि डेटा का स्रोत / गंतव्य बदलता है तो आपके मध्यस्थ वर्ग को बदलना नहीं चाहिए।

Comments

YAGNI एक ऐसी चीज है जिसके बारे में आपको सोचना चाहिए।

— whatsisname