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

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

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

पहले आइए एक परिकल्पना करते हैं:

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

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

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

अकाउंटिंग में, मूल्य (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 अनुपात है:

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

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 की अवधारणा को संहिताबद्ध किया है। जब एक नया इंजीनियर टीम में शामिल होता है, तो वे जानेंगे कि फॉर्मूले एप्लिकेशन और बिजनेस डोमेन के लिए आवश्यक हैं।

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

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