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

इस लेख में, मैं स्कॉट व्लासचिन टाइप डिज़ाइन के एक लेख से उदाहरणों का अनुवाद करूंगा : कैसे मुहावरेदार सी # में अमान्य राज्यों को अक्षम किया जाए । मैं यह भी दिखाने की कोशिश करूंगा कि यह दृष्टिकोण न केवल प्रयोग के रूप में लागू है, बल्कि काम करने वाले कोड में भी है।

डोमेन प्रकार बनाएँ

पहले आपको श्रृंखला में पिछले लेख के प्रकारों को पोर्ट करने की आवश्यकता है, जो एफ # में उदाहरणों में उपयोग किए जाते हैं।

डोमेन में आदिम प्रकार लपेटें

F # उदाहरण ईमेल पते, यूएस ज़िप कोड और राज्य कोड के लिए आदिम के बजाय डोमेन प्रकार का उपयोग करते हैं। आइए C # में एक आदिम प्रकार को लपेटने का प्रयास करें:

public sealed class EmailAddress { public string Value { get; } public EmailAddress(string value) { if (value == null) { throw new ArgumentNullException(nameof(value)); } if (!Regex.IsMatch(value, @"^\S+@\S+\.\S+$")) { throw new ArgumentException("Email address must contain an @ sign"); } Value = value; } public override string ToString() => Value; public override bool Equals(object obj) => obj is EmailAddress otherEmailAddress && Value.Equals(otherEmailAddress.Value); public override int GetHashCode() => Value.GetHashCode(); public static implicit operator string(EmailAddress address) => address?.Value; } 

 var a = new EmailAddress("a@example.com"); var b = new EmailAddress("b@example.com"); var receiverList = String.Join(";", a, b); 

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

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

यह ध्यान दिया जाना चाहिए कि आदिम मूल्यों से डोमेन प्रकारों का निर्माण कार्यात्मक प्रोग्रामिंग की विशिष्टता नहीं है। इसके विपरीत, आदिम प्रकारों का उपयोग ओओपी में खराब कोड का संकेत माना जाता है। आप इस तरह के रैपर के उदाहरण देख सकते हैं, उदाहरण के लिए, NLog और NBitcoin में , और TimeSpan का मानक प्रकार, वास्तव में, टिक की संख्या पर एक आवरण है।

मान ऑब्जेक्ट बनाना

अब हमें प्रविष्टि का एक एनालॉग बनाने की आवश्यकता है:

 public sealed class EmailContactInfo { public EmailAddress EmailAddress { get; } public bool IsEmailVerified { get; } public EmailContactInfo(EmailAddress emailAddress, bool isEmailVerified) { if (emailAddress == null) { throw new ArgumentNullException(nameof(emailAddress)); } EmailAddress = emailAddress; IsEmailVerified = isEmailVerified; } public override string ToString() => $"{EmailAddress}, {(IsEmailVerified ? "verified" : "not verified")}"; } 

फिर, एफ # की तुलना में अधिक कोड लिया गया, लेकिन अधिकांश काम आईडीई में रिफैक्टिंग के माध्यम से किया जा सकता है।

EmailAddress तरह, EmailContactInfo एक मान ऑब्जेक्ट ( DDD के अर्थ में, .NET में मान प्रकार नहीं है), लंबे समय से ज्ञात और ऑब्जेक्ट मॉडलिंग में उपयोग किया जाता है।

अन्य प्रकार - StateCode , StateCode , PostalAddress और PersonalName एक समान तरीके से C # में पोर्ट PersonalName ।

संपर्क बनाएँ

इसलिए, कोड को नियम को व्यक्त करना चाहिए "संपर्क में एक ईमेल पता या एक डाक पता (या दोनों पते) होना चाहिए।" इस नियम को व्यक्त करना आवश्यक है ताकि राज्य की शुद्धता प्रकार परिभाषा से दिखाई दे और संकलक द्वारा जाँच की जाए।

विभिन्न संपर्क राज्यों को व्यक्त करें

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

 public abstract class Contact { public PersonalName Name { get; } protected Contact(PersonalName name) { if (name == null) { throw new ArgumentNullException(nameof(name)); } Name = name; } } public sealed class PostOnlyContact : Contact { private readonly PostalContactInfo post_; public PostOnlyContact(PersonalName name, PostalContactInfo post) : base(name) { if (post == null) { throw new ArgumentNullException(nameof(post)); } post_ = post; } } public sealed class EmailOnlyContact : Contact { private readonly EmailContactInfo email_; public EmailOnlyContact(PersonalName name, EmailContactInfo email) : base(name) { if (email == null) { throw new ArgumentNullException(nameof(email)); } email_ = email; } } public sealed class EmailAndPostContact : Contact { private readonly EmailContactInfo email_; private readonly PostalContactInfo post_; public EmailAndPostContact(PersonalName name, EmailContactInfo email, PostalContactInfo post) : base(name) { if (email == null) { throw new ArgumentNullException(nameof(email)); } if (post == null) { throw new ArgumentNullException(nameof(post)); } email_ = email; post_ = post; } } 

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

संपर्क बनाएँ

संपर्क बनाना काफी सरल है।

 public abstract class Contact { public static Contact FromEmail(PersonalName name, string emailStr) { var email = new EmailAddress(emailStr); var emailContactInfo = new EmailContactInfo(email, false); return new EmailOnlyContact(name, emailContactInfo); } } 

 var name = new PersonalName("A", null, "Smith"); var contact = Contact.FromEmail(name, "abc@example.com"); 

यदि ईमेल पता गलत है, तो यह कोड एक अपवाद फेंक देगा, जिसे मूल उदाहरण में None वापसी का एक एनालॉग माना जा सकता है।

संपर्क अपडेट करें

किसी संपर्क को अपडेट करना भी सीधा है - आपको बस Contact प्रकार में एक अमूर्त विधि जोड़ने की आवश्यकता है।

 public abstract class Contact { public abstract Contact UpdatePostalAddress(PostalContactInfo newPostalAddress); } public sealed class EmailOnlyContact : Contact { public override Contact UpdatePostalAddress(PostalContactInfo newPostalAddress) => new EmailAndPostContact(Name, email_, newPostalAddress); } public sealed class PostOnlyContact : Contact { public override Contact UpdatePostalAddress(PostalContactInfo newPostalAddress) => new PostOnlyContact(Name, newPostalAddress); } public sealed class EmailAndPostContact : Contact { public override Contact UpdatePostalAddress(PostalContactInfo newPostalAddress) => new EmailAndPostContact(Name, email_, newPostalAddress); } 

 var state = new StateCode("CA"); var zip = new ZipCode("97210"); var newPostalAddress = new PostalAddress("123 Main", "", "Beverly Hills", state, zip); var newPostalContactInfo = new PostalContactInfo(newPostalAddress, false); var newContact = contact.UpdatePostalAddress(newPostalContactInfo); 

विकल्प के रूप में। एफ # में, ईमेल पते, ज़िप कोड, या राज्य गलत है, तो कंस्ट्रक्टरों से एक अपवाद फेंकना संभव है, लेकिन सी # के लिए यह एक आम बात है। बेशक, अपवाद कोड यहाँ काम कोड में या कहीं कॉलिंग कोड में प्रदान किया जाना चाहिए।

संपर्क को पदानुक्रम के बाहर संभालना

Contact पदानुक्रम में किसी संपर्क को अपडेट करने के लिए तर्क को रखना तर्कसंगत है। लेकिन क्या होगा अगर आप कुछ ऐसा हासिल करना चाहते हैं जो उसके ज़िम्मेदारी के क्षेत्र में फिट न हो? मान लीजिए कि आप उपयोगकर्ता इंटरफ़ेस पर संपर्क प्रदर्शित करना चाहते हैं।

आप निश्चित रूप से फिर से बेस क्लास में अमूर्त पद्धति को जोड़ सकते हैं और हर बार किसी भी तरह से संपर्क को संसाधित करने के लिए एक नई विधि जोड़ना जारी रखेंगे। लेकिन फिर एकमात्र जिम्मेदारी के सिद्धांत का उल्लंघन किया जाएगा, Contact पदानुक्रम को अव्यवस्थित कर दिया जाएगा, और Contact कार्यान्वयन और वास्तव में प्रसंस्करण के लिए जिम्मेदार स्थानों के बीच प्रसंस्करण तर्क को धुंधला कर दिया जाएगा। F # में ऐसी कोई समस्या नहीं थी, मैं चाहूंगा कि C # कोड कोई ख़राब न हो!

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

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

 public abstract class Contact { public abstract void AcceptVisitor(IContactVisitor visitor); } public interface IContactVisitor { void Visit(PersonalName name, EmailContactInfo email); void Visit(PersonalName name, PostalContactInfo post); void Visit(PersonalName name, EmailContactInfo email, PostalContactInfo post); } public sealed class EmailOnlyContact : Contact { public override void AcceptVisitor(IContactVisitor visitor) { if (visitor == null) { throw new ArgumentNullException(nameof(visitor)); } visitor.Visit(Name, email_); } } public sealed class PostOnlyContact : Contact { public override void AcceptVisitor(IContactVisitor visitor) { if (visitor == null) { throw new ArgumentNullException(nameof(visitor)); } visitor.Visit(Name, post_); } } public sealed class EmailAndPostContact : Contact { public override void AcceptVisitor(IContactVisitor visitor) { if (visitor == null) { throw new ArgumentNullException(nameof(visitor)); } visitor.Visit(Name, email_, post_); } } 

अब आप संपर्क प्रदर्शित करने के लिए कोड लिख सकते हैं। सादगी के लिए, मैं कंसोल इंटरफ़ेस का उपयोग करूंगा।

 public sealed class ContactUi { private sealed class Visitor : IContactVisitor { void IContactVisitor.Visit(PersonalName name, EmailContactInfo email) { Console.WriteLine(name); Console.WriteLine("* Email: {0}", email); } void IContactVisitor.Visit(PersonalName name, PostalContactInfo post) { Console.WriteLine(name); Console.WriteLine("* Postal address: {0}", post); } void IContactVisitor.Visit(PersonalName name, EmailContactInfo email, PostalContactInfo post) { Console.WriteLine(name); Console.WriteLine("* Email: {0}", email); Console.WriteLine("* Postal address: {0}", post); } } public void Display(Contact contact) => contact.AcceptVisitor(new Visitor()); } 

 var ui = new ContactUi(); ui.Display(newContact); 

और सुधार

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

 public abstract class Contact { private sealed class EmailOnlyContact : Contact { public EmailOnlyContact(PersonalName name, EmailContactInfo email) : base(name) { } } private Contact(PersonalName name) { } public static Contact EmailOnly(PersonalName name, EmailContactInfo email) => new EmailOnlyContact(name, email); } 

इस प्रकार, टाइप-योग की गैर-एक्स्टेंसिबिलिटी को पुन: पेश करना संभव है, हालांकि, एक नियम के रूप में, यह आवश्यक नहीं है।

निष्कर्ष

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

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

→ नमूना कोड GitHub पर उपलब्ध है