मैं इस निष्कर्ष पर पहुंचा हूं कि CreateDataFileत्वरित माप करके एक काम कर रहा है और फिर डेटा को संग्रहीत कर रहा है, और दोनों को एक ही विधि में करना किसी और के लिए इस कोड का उपयोग करने के लिए अधिक सहज है, फिर माप करना और फ़ाइल में लिखना अलग विधि कॉल के रूप में।
मुझे लगता है कि यह वास्तव में आपकी समस्या है। विधि एक काम नहीं कर रही है। यह दो, अलग-अलग ऑपरेशन कर रहा है जिसमें विभिन्न उपकरणों में I / O शामिल है , दोनों ही यह अन्य वस्तुओं के लिए ऑफ-लोडिंग हैं:
- एक माप प्राप्त करें
- उस परिणाम को किसी फ़ाइल में सहेजें
ये दो अलग-अलग I / O ऑपरेशन हैं। विशेष रूप से, पहले वाला किसी भी तरह से फ़ाइल सिस्टम को म्यूट नहीं करता है।
वास्तव में, हमें ध्यान देना चाहिए कि एक निहित मध्य कदम है:
- एक माप प्राप्त करें
- एक ज्ञात प्रारूप में माप को क्रमबद्ध करें
- किसी फ़ाइल में क्रमबद्ध माप सहेजें
आपके एपीआई को इनमें से प्रत्येक को किसी न किसी रूप में अलग से प्रदान करना चाहिए। आप कैसे जानते हैं कि एक कॉलर कहीं भी स्टोर किए बिना माप नहीं लेना चाहेगा? आप कैसे जानते हैं कि वे दूसरे स्रोत से माप प्राप्त नहीं करना चाहेंगे? आप कैसे जानते हैं कि वे इसे डिवाइस के अलावा कहीं और स्टोर नहीं करना चाहेंगे? संचालन को कम करने का अच्छा कारण है। एक पर नंगे न्यूनतम, प्रत्येक व्यक्ति टुकड़ा होना चाहिए उपलब्ध किसी भी फोन करने वाले के लिए। यदि मेरा उपयोग मामला इसके लिए कॉल नहीं करता है, तो मुझे फ़ाइल को माप लिखने के लिए मजबूर नहीं किया जाना चाहिए।
एक उदाहरण के रूप में, आप इस तरह के संचालन को अलग कर सकते हैं।
IMeasurer माप लाने का एक तरीका है:
public interface IMeasurer
{
IMeasurement Measure(int someInput);
}
आपका माप प्रकार बस कुछ सरल हो सकता है, जैसे stringया decimal। मैं जोर देकर कह रहा हूं कि आपको इसके लिए एक इंटरफेस या क्लास की जरूरत नहीं है, लेकिन यह यहां के उदाहरण को और सामान्य बनाता है।
IFileAccess फ़ाइलों को सहेजने के लिए कुछ विधि है:
interface IFileAccess
{
void SaveFile(string fileContents);
}
फिर आपको माप को क्रमबद्ध करने का एक तरीका चाहिए। एक माप का प्रतिनिधित्व करने वाले वर्ग या इंटरफ़ेस में बनाएँ, या एक उपयोगिता विधि है:
interface IMeasurement
{
// As part of the type
string Serialize();
}
// Utility method. Makes more sense if the measurement is not a custom type.
public static string SerializeMeasurement(IMeasurement m)
{
return ...
}
यह स्पष्ट नहीं है कि आपके पास यह क्रमांकन ऑपरेशन अभी तक अलग है या नहीं।
इस तरह का अलगाव आपके एपीआई को बेहतर बनाता है। यह कॉलर को यह तय करने देता है कि उन्हें क्या और कब की जरूरत है, बजाय इसके कि आपके आई / ओ को प्रदर्शन करने के बारे में आपके पूर्व विचार पर मजबूर किया जाए। कॉलर्स के पास किसी भी वैध ऑपरेशन को करने के लिए नियंत्रण होना चाहिए , चाहे आपको लगता है कि यह उपयोगी है या नहीं।
एक बार जब आप प्रत्येक ऑपरेशन के लिए अलग-अलग कार्यान्वयन करते हैं, तो आपकी CreateDataFileविधि केवल एक शॉर्टहैंड बन जाती है
fileAccess.SaveFile(SerializeMeasurement(measurer.Measure()));
विशेष रूप से, आपके द्वारा यह सब करने के बाद आपका तरीका बहुत कम मूल्य जोड़ता है। कोड की उपरोक्त पंक्ति आपके कॉलर्स को सीधे उपयोग करने के लिए मुश्किल नहीं है, और आपकी विधि विशुद्ध रूप से सुविधा के लिए है। यह होना चाहिए और कुछ वैकल्पिक है । और यह एपीआई के लिए व्यवहार करने का सही तरीका है।
एक बार जब सभी संबंधित भागों को हटा दिया जाता है और हमने स्वीकार कर लिया है कि यह विधि सिर्फ एक सुविधा है, हमें आपके प्रश्न को फिर से लिखना होगा:
आपके कॉल करने वालों के लिए सबसे आम उपयोग मामला क्या होगा?
यदि पूरे बिंदु को एक ही बोर्ड से मापने और लिखने के सामान्य उपयोग के मामले को थोड़ा अधिक सुविधाजनक बनाना है, तो यह Boardसीधे कक्षा पर उपलब्ध कराने के लिए एकदम सही समझ में आता है :
public class Board : IMeasurer, IFileAccess
{
// Interface methods...
/// <summary>
/// Convenience method to measure and immediate record measurement in
/// default location.
/// </summary>
public void ReadAndSaveMeasurement()
{
this.SaveFile(SerializeMeasurement(this.Measure()));
}
}
यदि इससे सुविधा में सुधार नहीं होता है, तो मैं इस पद्धति से बिल्कुल नहीं परेशान होना चाहूंगा।
यह एक सुविधा पद्धति होने के नाते एक अन्य प्रश्न उठाती है।
क्या IFileAccessइंटरफ़ेस को माप प्रकार के बारे में जानना चाहिए और इसे कैसे क्रमबद्ध करना चाहिए? यदि हां, तो आप एक विधि जोड़ सकते हैं IFileAccess:
interface IFileAccess
{
void SaveFile(string fileContents);
void SaveMeasurement(IMeasurement m);
}
अब कॉलर बस यही करते हैं:
fileAccess.SaveFile(measurer.Measure());
जो प्रश्न में परिकल्पित होने के रूप में आपकी सुविधा पद्धति से कम और शायद अधिक स्पष्ट है।