ऑब्जेक्ट ओरिएंटेड जिन इंस्टॉलर विकास

पहले भाग का लिंक
दूसरे भाग का लिंक

सामग्री और कंटेनर टीम

कुछ आदेशों में मूल रूप से पैकेज डेवलपर के कंप्यूटर पर संग्रहीत फ़ाइलों के साथ काम करना शामिल है। यह स्पष्ट है कि इन फाइलों को पैकेज (और अधिमानतः, पैकेज के अंदर सही) पैकेज के उपभोक्ता को एक साथ दिया जाना चाहिए। पहले, यह कल्पना करने की कोशिश करें कि यह कैसे काम करेगा।
हमारे पास PackageBilder श्रेणी का एक उदाहरण है, जिसमें हम PackageBody तर्क को नामित करते हैं, जिसमें अन्य बातों के अलावा, कमांड कमांड, जो पैकेज कमांड ट्री का रूट नोड है। PackageBuilder वर्ग के इंस्टेंस की SaveResult () विधि को पूरे ट्री को पुन: प्राप्त करना चाहिए, और उन आदेशों के लिए जो डेवलपर के कंप्यूटर पर स्थित सामग्री फ़ाइलों का उपयोग करते हैं, इन सभी फ़ाइलों की सामग्री को पैकेज बॉडी में शामिल करते हैं। इसमें पैकेज बॉडी में एक xml फ़ाइल भी शामिल होनी चाहिए, जिसमें पैकेजबॉडी को पैकेज के पूर्ण विवरण और उसके द्वारा निष्पादित कमांड के साथ क्रमबद्ध किया जाएगा।

SaveResult () मेथड कैसे हो सकता है, जब रीसर्चली कमांड ट्री को ट्रेस करता है, तो पता करें कि क्या करंट कमांड में ऐसी फाइलें हैं जिन्हें पैकेज में शामिल करने की जरूरत है? यदि हम इस तरह के छद्म कोड के प्रकार की एक सरल जाँच करते हैं: "यदि वर्तमान कमांड CreateFile है, तो हम SourceFile को इसमें से निकालते हैं", तो परिणामस्वरूप हमें यह मिलता है कि PackageBuilder वर्ग के स्रोत कोड तक पहुँच के बिना, इंस्टॉलर के लिए एक्सटेंशन का डेवलपर अब सक्षम नहीं होगा। अपनी नई सामग्री टीम के लिए यहां एक और जांच जोड़ें। यहाँ, हमें ContentCommand जैसे एक और सार वर्ग के निर्माण में मदद की जा सकती है, जहाँ से हम विरासत में प्राप्त करेंगे, लेकिन यह स्पष्ट नहीं है कि हम इस वर्ग को कमांड पदानुक्रम में कहाँ बनाएँगे? वर्तमान में, CreateFile कमांड TransactionalCommand से विरासत में मिली है, और CreateFile का अर्थ है कि यह एक सामग्री कमांड भी है। लेकिन WriteRegistry भी TransactionalCommand से विरासत में मिली है, हालांकि, यह सामग्री नहीं हो सकती क्योंकि यह केवल एक निश्चित कुंजी का उपयोग करके रजिस्ट्री के लिए मूल्य लिखता है। और यहाँ, वैसे, WriteRegistryFileCommand कमांड भी एक TransactionalCommand है, और साथ ही यह सामग्री भी है क्योंकि इसे * .reg निष्पादित करने की आवश्यकता है - एक फाइल जो सभी रजिस्ट्री कुंजियों को बदलने का वर्णन करती है।

इस प्रकार, यह स्पष्ट नहीं है कि कहाँ पदानुक्रम में ContentCommand वर्ग एम्बेड किया जा सकता है, और चूंकि C # अशुद्धता वर्गों का उपयोग नहीं कर सकता है, जैसा कि C ++ (स्रोत) में है, हम इस मुद्दे को एक नया IContentCandand इंटरफ़ेस पेश करके हल करेंगे, जिसे हम प्रत्येक सामग्री कमांड में लागू करेंगे। । सौभाग्य से, प्रत्येक विशेष वर्ग किसी भी संख्या में इंटरफेस को लागू कर सकता है, जो हमारे लिए है।

IContentCommand इंटरफ़ेस पहले सन्निकटन के रूप में है:

public interface IContentCommand { string ContentPath { get; set; } } 

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

प्रत्येक सामग्री टीम के लिए इस इंटरफ़ेस का कार्यान्वयन सरल और स्पष्ट है। उदाहरण के लिए, CreateFile कमांड के लिए, यह इस तरह होगा:

 public string ContentPath { get { return SourcePath; } set { SourcePath = value; } } 

यह किसी भी अन्य सामग्री टीम के लिए समान दिखेगा।

IContentCommand इंटरफ़ेस का एकमात्र दोष यह है कि यह एक फ़ाइल पथ के साथ संचालित होता है, यानी एक फ़ाइल या एक फ़ोल्डर के साथ। लेकिन क्या होगा अगर कमांड में दो या अधिक फाइल या फ़ोल्डर्स के लिए पॉइंटर्स हों? तब इंटरफ़ेस इस तरह दिखेगा:

 interface IMultipleContentCommand { IEnumerable<ContentPath> ContentPaths { get; } } 

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

 public class ContentPath { private Command _command; private PropertyInfo _property; public ContentPath(Command command, PropertyInfo property) { if (!(command is IMultipleContentCommand)) { throw new ArgumentException("Must be the IMultipleContentCommand"); } _command = command; _property = property; } public string Name { get { return _property.Name; } } public string Value { get { return (string)_property.GetValue(_command, null); } set { _property.SetValue(_command, value, null); } } } 

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

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

1. पैकेज कमांड वाले XML फ़ाइल बनाना
2. मूल रूप से पैकेज डेवलपर की मशीन पर संग्रहीत सभी सामग्री फ़ाइलों के पैकेज में समावेश
3. फ़ाइलों की एक सरणी को एक संग्रह फ़ाइल में संयोजित करना।

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

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

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

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

PackageBuilder के लिए यह पता लगाने के लिए कि क्या वर्तमान कमांड में कमांड एम्बेडेड है, हम इसे बनाएंगे ताकि सभी कमांड (उन्हें कंटेनर कहते हैं) जिसमें अन्य कमांड होते हैं, इस बारे में कॉलिंग कोड को सूचित कर सकते हैं। ऐसा करने के लिए, वे IContainerCommand इंटरफ़ेस को लागू करेंगे, इसका विवरण यहां दिया गया है:

 public interface IContainerCommand { IEnumerable<Command> InnerCommands { get; } } 

कंटेनर कमांड के लिए इस इंटरफ़ेस को लागू करना तुच्छ होगा। उदाहरण के लिए, CommandSequence बस अपनी कमानों की संपत्ति वापस करेगा:

 public IEnumerable<Command> InnerCommands { get { return Commands; } } 

और ExecuteIf एक एकल कमांड कमांड से मिलकर एक सूची लौटाएगा:

 public IEnumerable<Command> InnerCommands { get { return new List<Command>() { Command }; } } 

मैं अब यह सब कैसे काम करता है इसकी सटीक समझ के लिए SaveResult और ProcessIncludedFiles विधियों का कोड देगा:

 public const string MAIN_PACKAGE_FILENAME = "package.xml"; public const string PACKAGE_FILE_EXTENSION = ".gin"; public const string PACKAGE_CONTENT_FILE_EXTENSION = ".cnt"; public void SaveResult(string filePath) { ProcessIncludedFiles(_body.Command); string xmlFilePath = GinSerializers.PackageBodySerializer.Serialize(_body); _content.AddContent(xmlFilePath, MAIN_PACKAGE_FILENAME); _content.SaveAs(filePath); } private void ProcessIncludedFiles(Command command) { if (command is IContainerCommand) { IContainerCommand iContainer = (IContainerCommand)command; foreach (Command cmd in iContainer.InnerCommands) { ProcessIncludedFiles(cmd); } } if (command is IContentCommand) { IContentCommand cntCommand = (IContentCommand)command; string sourceFilePath = cntCommand.ContentPath; if (!_content.ContainFilePath(sourceFilePath)) { string destFileName = GetGuidContentFileName(); _content.AddContent(sourceFilePath, destFileName); cntCommand.ContentPath = destFileName; } else { string destFileName = _content.GetFileName(sourceFilePath); cntCommand.ContentPath = destFileName; } } } private string GetGuidContentFileName() { return Guid.NewGuid().ToString("N") + PACKAGE_CONTENT_FILE_EXTENSION; } 

बस ऊपर, मैंने पहले ही इस कोड के संचालन के बारे में विस्तार से वर्णन किया है।

तुलनात्मक संचालक

मैंने पहले भाग में स्ट्रिंग तुलना ऑपरेटरों को देखा। यहां मैं संख्यात्मक डेटा के लिए तुलना ऑपरेटरों को लागू करने का प्रयास करूंगा। जैसा कि हम याद करते हैं, ExecuteIf कमांड को निष्पादन संदर्भ (ExecutionContext) में बूलियन चर की आवश्यकता होती है, जो दो ऑपरेंड की तुलना करने का परिणाम है। इन ऑपरेंडों में विभिन्न प्रकार (इंट, डबल, आदि) हो सकते हैं। तुलना ऑपरेटर स्वयं, बदले में, अलग भी हो सकता है (लेसथन, ग्रेटरथन, इक्वल, इत्यादि), और, जैसा कि आप देख सकते हैं, ऑपरेटर का प्रत्येक सेट प्रत्येक विशिष्ट प्रकार के ऑपरेंड्स पर लागू नहीं हो सकता है, उदाहरण के लिए, स्टार्ट-मैथ ऑपरेटर शायद ही पूर्णांक के लिए आवेदन करने लायक नहीं है। जैसा कि आप देख सकते हैं, एक टीम बनाना जो ऑपरेंड्स की तुलना को लागू करता है, एक बहुत ही गैर-तुच्छ कार्य है, विशेष रूप से टीम को डिजाइन करने की हमारी इच्छा पर विचार करना ताकि अंत उपयोगकर्ता-प्रोग्रामर अपने ऑपरेटरों के साथ तुलना ऑपरेटरों के मूल सेट का विस्तार कर सके।

पहला, सबसे स्पष्ट, तुलनात्मक ऑपरेटरों को लागू करने के लिए दृष्टिकोण तर्कों के साथ एक कमांड की तरह दिखता है:

स्ट्रिंग FirstOperandName,
स्ट्रिंग दूसराऑपरैंडनाम,
तुलनाऑपरेशन ऑपरेशन।

पूर्णांक के लिए, यह इस तरह दिखता है:

 public enum CompareOperation { Equals, GreaterThan } public class StringCompareCommand : Command { public string FirstOperandName { get; set; } public string SecondOperandName { get; set; } public CompareOperation Operation { get; set; } private ExecutionContext _context; public StringCompareCommand(ExecutionContext context) { _context = context; } public override void Do() { bool compareResult = false; int firstOperand = (int)_context.GetResult(FirstOperandName); int secondOperand = (int)_context.GetResult(SecondOperandName); switch (Operation) { case CompareOperation.Equals: compareResult = firstOperand == secondOperand; break; case CompareOperation.GreaterThan: compareResult = firstOperand < secondOperand; break; } _context.SaveResult(ResultName, compareResult); } } 

यहां मैंने केवल दो तुलनात्मक ऑपरेटरों का वर्णन किया है, और केवल पूर्णांकों के लिए। तदनुसार, यदि हम दशमलव संख्याओं की तुलना करना चाहते हैं, तो हम DecimalCompareCommand वर्ग को कमांड से विरासत में जोड़ देंगे, जो कि (दशमलव) प्रकार के लिए छोड़कर लगभग पूरी तरह से IntCompareCommand वर्ग को दोहराएगा। और अगर हम उनके साथ लेथन ऑपरेटर को जोड़ना चाहते हैं, तो हमें Do () विधि के स्विच स्टेटमेंट में दो वर्गों IntCompareCommand, DecimalCompareCommand में परिवर्तन करना होगा।

मुझे इस दृष्टिकोण के बारे में क्या नापसंद है? दोहराए जाने वाले पैटर्न की एक बड़ी संख्या - प्रत्येक वर्ग का कोड आम तौर पर लगभग समान होता है। तुलनात्मक गणना के लिए नए तुलना ऑपरेटरों को जोड़ने के लिए एक तृतीय-पक्ष डेवलपर द्वारा असमर्थता।

मुझे लगता है कि यह पॉलीमोर्फिज़्म के उपयोग के साथ स्विच स्टेटमेंट को बदलने के लायक है। आइए इसे जीवन में लाने का प्रयास करें।
चूंकि हमारी समस्या में समय के साथ दो पहलू बदल सकते हैं - ऑपरेंड्स का प्रकार और ऑपरेशन का प्रकार, इन पहलुओं में से प्रत्येक को एक अलग अमूर्त वर्ग में समझाया जाना चाहिए। उन्हें कम्पेरिमांड और तुलनाऑपरैंड कहा जाता है।

 public abstract class CompareCommand: Command { public string FirstOperandName { get; set; } public string SecondOperandName { get; set; } public override void Do(ExecutionContext context) { bool result = Compare(Subtract(context)); context.SaveResult(ResultName, result); } protected abstract bool Compare(int compareResult); private int Subtract(ExecutionContext context) { CompareOperand firstOperand = CompareOperand.Create(context.GetResult(FirstOperandName)); CompareOperand secondOperand = CompareOperand.Create(context.GetResult(SecondOperandName)); return (firstOperand - secondOperand); } } 

इस वर्ग में हैं:

1. निष्पादन के संदर्भ में उनके नाम द्वारा दिए गए दो तर्क,
2. Do (ExecutionContext) विधि, जो दो मात्राओं (घटाव विधि) के बीच अंतर के संकेत को खोजने के लिए तुलना करती है, और इस संकेत को अमूर्त तुलना (इंट) विधि से पास करती है। हम तुलना विधि के ठोस वंशजों में तुलना विधि को लागू करते हैं।
3. सार तुलना (int) विधि
4. एक विशिष्ट सबट्रेक्ट विधि जो संदर्भ से दो ऑपरेंड को निकालती है और उन्हें अमूर्त वर्ग के वंशजों के उदाहरणों में संग्रहीत करती है। तुलनात्मक रूप से, और फिर एक को दूसरे से घटाती है। यह स्पष्ट है कि वहां भी बहुरूपता का उपयोग किया जाएगा।

उत्तराधिकारी इस तरह दिखेंगे:

 public class CompareLessThan : CompareCommand { protected override bool Compare(int compareResult) { return compareResult < 0; } } 

अब हम तुलना कक्षा का वर्णन करते हैं:

 public abstract class CompareOperand { public static CompareOperand Create(object operand) { if (operand is ulong) { return new ULongCompareOperand() { Value = (ulong)operand }; } .. .. .. .. .. .. .. .. .. return new DefaultCompareOperand() { Value = (DefaultType)operand }; } public static int operator -(CompareOperand operand1, CompareOperand operand2) { return operand1 - operand2; } } 

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

और उसके वारिस इस तरह होंगे:

 public class LongCompareOperand : CompareOperand { public long Value { get; set; } public static int operator -(LongCompareOperand operand1, LongCompareOperand operand2) { return Math.Sign(operand1.Value - operand2.Value); } } 

योजना सुंदर दिखती है सिवाय इसके कि घटाव ऑपरेटर को एक स्थिर विधि के रूप में लागू किया जाता है, जिसका अर्थ है कि इस मामले में बहुरूपता काम नहीं करेगी (स्थैतिक विधि आभासी नहीं हो सकती है, जिसका अर्थ है कि बहुरूपता इसके सम्मान में काम नहीं करेगा)। VisualStudio ने तुरंत एक परीक्षण मामला चलाने के बाद हमें इस तथ्य के बारे में बताया - घटाव ऑपरेटर को कॉल करना स्टैक ओवरफ्लो का कारण बना, क्योंकि तुलनात्मक रूप से लागू किए गए घटाव को स्वयं कहा जाता है, न कि आधार वर्ग के बहुरूपिक घटाव ऑपरेटर। ठीक है, हम घटाव "-" ऑपरेटर के साथ नहीं करते हैं, लेकिन घटाव () विधि के साथ करते हैं।

 public abstract class CompareOperand { public static CompareOperand Create(object operand) { return new DefaultCompareOperand() { Value = (DefaultType)operand }; } public abstract int Subtract(CompareOperand operand2); public static int operator -(CompareOperand operand1, CompareOperand operand2) { return operand1.Subtract(operand2); } } public class LongCompareOperand : CompareOperand { public long Value { get; set; } public override int Subtract(CompareOperand operand2) { return Math.Sign(this.Value - ((LongCompareOperand)operand2).Value); } } 

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

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

चौथे भाग का लिंक