गुप्त सूत्र को संहिताबद्ध करना

प्रत्येक अनुप्रयोग का अपना गुप्त सूत्र है, यह अस्तित्व का कारण है। गुप्त सूत्र को संहिताबद्ध करना रखरखाव योग्य और सफल अनुप्रयोगों को लिखने में महत्वपूर्ण है।

रुकिए। संहिताबद्ध करना क्या है? धैर्य रखें मेरे दोस्त, हम वहां पहुंचेंगे।

पहले आइए अनुमान लगाते हैं:

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

कुछ महीने बीत गए हैं, अधिकांश क्रॉस-कटिंग चिंताएं विकसित हो गई हैं (बहुत अच्छा!)। टीम अब अनुप्रयोग की स्वादिष्ट अच्छाई पर केंद्रित है: व्यावसायिक डोमेन (गुप्त सूत्र)। यह वह जगह है जहां गुप्त सूत्र को संहिताबद्ध करना शुरू होता है।

संहिताबद्ध करना, व्यावसायिक डोमेन में एक आवश्यक अवधारणा के चारों ओर संरचना डालना है।

लेखांकन में, मूल्य (P) कमाई (E) अनुपात (P/E अनुपात) एक कंपनी की कमाई का एक माप है। एक उच्च P/E अनुपात भविष्य में उच्च कमाई वृद्धि का सुझाव देता है। P/E अनुपात की गणना बाजार मूल्य प्रति शेयर (शेयर मूल्य) को प्रति शेयर कमाई (लाभ - लाभांश / बकाया शेयरों की संख्या) से विभाजित करके की जाती है।

एक सरल, और मैं तर्क देता हूं, भोली कार्यान्वयन:

public class Metric
{
    public string Name { get; set; }
    public decimal Value {get; set}
    public int Order {get; set;}
}
public class AccountingSummary
{
    public Metric[] GetMetrics(decimal price, decimal earnings)
    {
        var priceEarningsRatio = price/earnings;
        
        var priceEarningsRatioMetric = new Metric 
        {
            Name = "P/E Ratio",
            Value = priceEarningsRatio,
            Order = 0
        }
        return new [] {priceEarningsRatioMetric};
    }
}

यदि यह केवल एक जगह उपयोग किया जाता है, तो यह ठीक है। क्या होगा यदि आप P/E अनुपात को अन्य क्षेत्रों में उपयोग करते हैं?

जैसे यहां PriceEarnings.cs में

var priceEarningsRatio = price/earnings;

और यहां AccountSummary.cs में

var priceEarningsRatio = price/earnings;

और यहां StockSummary.cs में

var priceEarningsRatio = price/earnings;

P/E अनुपात इस अनुप्रयोग के लिए मूल है, लेकिन इसे कैसे लागू किया जाता है, विभिन्न स्थानों में हार्डकोड किया जाता है, P/E अनुपात के महत्व को कोड के समुद्र में खो देता है। यह केवल जंगल में एक और पेड़ है।

आप एक जगह अनुपात बदलने का जोखिम भी उठाते हैं लेकिन दूसरी जगह नहीं। यह डाउनस्ट्रीम गणनाओं को बंद कर सकता है। इस प्रकार की त्रुटियां खोजने के लिए कुख्यात रूप से कठिन हैं।

अक्सर परीक्षक मान लेंगे कि यदि यह एक क्षेत्र में काम करता है, तो यह सभी क्षेत्रों में सही है। अनुप्रयोग पूरे अनुप्रयोग के लिए P/E अनुपात उत्पन्न करने के लिए समान कोड का उपयोग क्यों नहीं करेगा? क्या यह ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग का बिंदु नहीं है?

मैं कल्पना कर सकता हूं कि इस तरह की एक त्रुटि उत्पादन में बनी रहे और तब तक खोजी न जाए जब तक आपके कार्यकारी का दौरा न हो जो जानना चाहता है कि SEC के P/E अनुपात की गणना कंपनी द्वारा दाखिल की गई गणना से अलग क्यों है। यह एक अच्छी जगह नहीं है।

आइए अपने P/E अनुपात कार्यान्वयन को फिर से देखें और देखें कि हम अपने पहले प्रयास में कैसे सुधार कर सकते हैं।

लेखांकन प्रणालियों में सूत्र एक चीज हैं, आइए एक इंटरफेस जोड़कर सूत्रों के चारों ओर संरचना डालें:

public interface IFormula
{
    decimal Calculate<T>(T model);
}

अब प्रत्येक सूत्र इस इंटरफेस के साथ लागू किया जाता है जो हमें स्थिरता और पूर्वानुमानशीलता देता है।

यहां हमारा सुधारा गया P/E अनुपात है हमारे इंटरफेस को लागू करने के बाद:

हमने एक PriceEarningsModel जोड़ा है जो हमारी Calculate विधि में आवश्यक डेटा पास करने के लिए।

public class PriceEarningsModel
{
    public decimal Price {get; set;}
    public decimal Earnings {get; set;}
}

PriceEarningsModel का उपयोग करते हुए, हमने P/E अनुपात के लिए IFormula इंटरफेस का एक कार्यान्वयन बनाया है।

public class PriceEarningsRatioFormula : IFormula
{
    public decimal Calculate<PriceEarningsModel>(PriceEarningsModel model)
    {
        return model.Price / model.Earnings;
    }
}

हमने अब P/E अनुपात को संहिताबद्ध कर दिया है। यह हमारे अनुप्रयोग में एक प्रथम-श्रेणी की अवधारणा है। हम इसे कहीं भी उपयोग कर सकते हैं। यह परीक्षण योग्य है, और एक परिवर्तन पूरे अनुप्रयोग को प्रभावित करता है।

एक अनुस्मारक के रूप में, यहां वह कार्यान्वयन है जिससे हमने शुरुआत की थी:

public class Metric
{
    public string Name { get; set; }
    public decimal Value {get; set}
    public int Order {get; set;}
}
public class AccountingSummary
{
    public Metric[] GetMetrics(decimal price, decimal earnings)
    {
        var priceEarningsRatio = price/earnings;
        
        var priceEarningsRatioMetric = new Metric 
        {
            Name = "P/E Ratio",
            Value = priceEarningsRatio,
            Order = 0
        }
        return new [] {priceEarningsRatioMetric};
    }
}

यह सरल है और काम पूरा करता है। समस्या यह है कि P/E अनुपात, जो हमारे लेखांकन अनुप्रयोग में एक मूल अवधारणा है, बाहर नहीं निकलता है। अनुप्रयोग या व्यावसायिक डोमेन से परिचित नहीं इंजीनियर इसके महत्व को नहीं समझेंगे।

हमारा सुधारा गया कार्यान्वयन हमारी नई P/E अनुपात क्लास का उपयोग करता है। हम PriceEarningsRatioFormula क्लास को AccountSummary क्लास में इंजेक्ट करते हैं।

हम अपने हार्डकोड किए गए P/E अनुपात को अपनी नई PriceEarningsRatioFormula क्लास से बदलते हैं।

public class AccountingSummary
{
    private PriceEarningsRatioFormula _peRatio;
    
    public AccountingSummary(PriceEarningsRatioFormula peRatio)
    {
        _peRatio = peRatio;
    }
    
    public Metric[] GetMetrics(decimal price, decimal earnings)
    {
        var priceEarningsRatio = _peRatio.Calculate(new PriceEarningsModel 
        { 
            Price = price, 
            Earnings = earnings
        });
        
        var priceEarningsRatioMetric = new Metric 
        {
            Name = "P/E Ratio",
            Value = priceEarningsRatio,
            Order = 0
        }
        return new [] {priceEarningsRatioMetric};
    }
}

कोई यह तर्क दे सकता है कि PriceEarningsRationFormula के साथ पिछले कार्यान्वयन की तुलना में थोड़ा अधिक काम है और मैं सहमत हूं। थोड़ा अधिक समारोह है लेकिन लाभ कोड और समारोह में छोटी वृद्धि के लायक हैं।

सबसे पहले, हम पूरे अनुप्रयोग के लिए P/E अनुपात बदलने की क्षमता प्राप्त करते हैं। हमारे पास डिबग करने के लिए एक एकल कार्यान्वयन भी है यदि दोष उत्पन्न होते हैं।

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

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

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