"आदिम जुनून" की अनुमति देने के लिए "यो-यो समस्या से बचने के लिए" एक वैध कारण है?

Question

के अनुसार कब आदिम जुनून एक कोड गंध नहीं है? , मैं एक स्ट्रिंग कोड के बजाय एक ज़िप कोड का प्रतिनिधित्व करने के लिए एक ZipCode ऑब्जेक्ट बनाना चाहिए।

हालांकि, मेरे अनुभव में, मैं देखना पसंद करता हूं

public class Address{
    public String zipCode;
}

के बजाय

public class Address{
    public ZipCode zipCode;
}

क्योंकि मुझे लगता है कि बाद वाले को प्रोग्राम को समझने के लिए मुझे ZipCode क्लास में जाना होगा।

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

इसलिए मैं उदाहरण के लिए, जिपकोड विधियों को एक नई कक्षा में ले जाना चाहूंगा:

पुराना:

public class ZipCode{
    public boolean validate(String zipCode){
    }
}

नया:

public class ZipCodeHelper{
    public static boolean validate(String zipCode){
    }
}

ताकि ज़िप कोड को मान्य करने के लिए केवल उसी व्यक्ति को ज़िपकोडहेल्पर क्लास पर निर्भर रहना पड़े। और मुझे आदिम जुनून रखने का एक और "लाभ" मिला: यह वर्ग को उसके क्रमबद्ध रूप की तरह दिखता है, यदि कोई हो, उदाहरण के लिए: स्ट्रिंग स्तंभ zipCode के साथ एक पता तालिका।

मेरा प्रश्न है, "" यो-यो समस्या से बचना "(वर्ग परिभाषाओं के बीच चाल)" आदिम जुनून "की अनुमति देने का एक वैध कारण है?"

Comments

@ jpmc26 तब आप चौंक जाएंगे कि हमारा ज़िप कोड ऑब्जेक्ट कितना जटिल है - यह नहीं कह रहा है कि यह सही है, लेकिन यह मौजूद नहीं है

— जेरेड गोगुएन

@ jpmc26, मैं यह देखने में विफल हूं कि आप "कॉम्प्लेक्स" से "बुरी तरह से डिज़ाइन किए गए" कैसे प्राप्त करें। कॉम्प्लेक्स कोड अक्सर साधारण कोड के परिणाम के रूप में वास्तविक दुनिया की जटिलता के संपर्क में आने के बजाय आदर्श दुनिया है जिसमें हम कामना कर सकते हैं। "उस दो पेज के समारोह में वापस। हाँ, मुझे पता है, यह एक खिड़की को प्रदर्शित करने के लिए सिर्फ एक सरल कार्य है, लेकिन यह उस पर थोड़ा बाल और सामान उगाया है और कोई नहीं जानता है। ठीक है, मैं आपको बताता हूं कि क्यों: वे बग हैं। ठीक किए गए। "

— Kyralessa

@ jpmc26 - ज़िपकोड जैसी वस्तुओं को लपेटने का बिंदु प्रकार की सुरक्षा है। ज़िप कोड एक स्ट्रिंग नहीं है, यह एक ज़िप कोड है। यदि कोई फ़ंक्शन ज़िप कोड की अपेक्षा करता है, तो आपको केवल एक ज़िप कोड पारित करने में सक्षम होना चाहिए, न कि एक स्ट्रिंग।

— oद्रालो

यह अत्यधिक भाषा विशेष को महसूस करता है, विभिन्न भाषाएं यहां विभिन्न चीजें करती हैं। @ Davor shoulddralo उसी खिंचाव में हमें बहुत सारे संख्यात्मक प्रकार भी जोड़ने चाहिए। "केवल सकारात्मक पूर्णांक", "केवल संख्याएँ" भी सभी प्रकार हो सकते हैं।

— पौल

@ paul23 वास्तव में हां, और मुख्य कारण जो हमारे पास नहीं है, वह यह है कि बहुत सी भाषाएं उन्हें परिभाषित करने के लिए सुरुचिपूर्ण तरीके का समर्थन नहीं करती हैं। यह "डिग्री सेल्सियस में तापमान" से एक अलग प्रकार के रूप में "उम्र" को परिभाषित करने के लिए पूरी तरह से उचित है, यदि केवल इतना है कि "userAge == currentTemper" को बकवास के रूप में पाया जाता है।

— IMSoP

Answer 1

धारणा यह है कि आपको पता वर्ग को समझने के लिए ZipCode वर्ग के लिए यो-यो करने की आवश्यकता नहीं है। यदि ZipCode अच्छी तरह से डिज़ाइन किया गया है तो यह स्पष्ट होना चाहिए कि यह पता वर्ग को पढ़कर क्या करता है।

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

उदाहरण के लिए, मुझे यकीन है कि जब भी आप स्ट्रिंग का सामना कोड में करते हैं, तो स्ट्रिंग के स्रोत कोड को पढ़ने में आप यो-यो नहीं करते हैं।

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

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

जैसा कि क्रमांकन के लिए मुझे लगता है कि यह आपके द्वारा उपयोग किए जा रहे ढांचे में एक सीमा की तरह लगता है। निश्चित रूप से आपको एक जिपकोड को स्ट्रिंग में क्रमबद्ध करने या डेटाबेस में एक कॉलम में मैप करने में सक्षम होना चाहिए।

Comments

मैं "सार्थक इकाइयों" (मुख्य-) भाग से सहमत हूं, लेकिन इतना नहीं कि एक ज़िप कोड और ज़िप कोड सत्यापन समान अवधारणा हैं। ZipCodeHelper(जिसे मैं बल्कि कॉल करूंगा ZipCodeValidator) यह काम करने के लिए एक वेब सेवा से बहुत अच्छी तरह से संबंध स्थापित कर सकता है। यह एकल ज़िम्मेदारी का हिस्सा नहीं होगा "ज़िप कोड डेटा पकड़ो"। अमान्य ज़िप कोड को टाइप करने वाली प्रणाली को बनाना अभी भी ZipCodeकंस्ट्रक्टर को जावा के पैकेज-प्राइवेट के बराबर बनाकर और कॉल करके प्राप्त किया जा सकता है ZipCodeFactoryजिसके साथ हमेशा सत्यापनकर्ता को कॉल किया जाता है।

— आर। शमित्ज़

@ R.Schmitz: वह नहीं है जो "जिम्मेदारी" का अर्थ एकल जिम्मेदारी सिद्धांत के अर्थ में है। लेकिन किसी भी मामले में, आपको निश्चित रूप से कई वर्गों का उपयोग करना चाहिए, जब तक आपको ज़िप कोड और उसके सत्यापन को अलग करना है। ओपी ज़िप कोड को एनकैप्सुलेट करने के बजाय एक सहायक का सुझाव देता है , जो एक बुरा विचार है।

— जैक्सबी

मैं सम्मानपूर्वक असहमत होना चाहता हूं। एसआरपी का मतलब है कि एक वर्ग में "एक, और केवल एक, कारण बदलने का" होना चाहिए ("एक ज़िपकोड में क्या परिवर्तन होता है" बनाम "यह कैसे मान्य है")। यह विशिष्ट मामला यहां स्वच्छ संहिता पुस्तक में और विस्तृत रूप से दिया गया है : " वस्तुएं अपने डेटा को अमूर्तियों के पीछे छिपाती हैं और उस डेटा पर काम करने वाले कार्यों को उजागर करती हैं। डेटा संरचना उनके डेटा को उजागर करती है और कोई सार्थक कार्य नहीं करती है। " - ZipCodeएक "डेटा संरचना" होगी। और ZipCodeHelperएक "वस्तु '। किसी भी मामले में, मुझे लगता है कि हम सहमत हैं कि हमें ज़िपकोड निर्माता को वेब कनेक्शन पास नहीं करना चाहिए।

— आर। श्मिट

एक आदिम का उपयोग करना IMHO उन मामलों में उचित है जहां इस विशेष प्रकार के आधार पर कोई सत्यापन या अन्य तर्क नहीं है। => मैं असहमत हूं। यहां तक ​​कि अगर सभी मूल्य मान्य हैं, तो मैं अभी भी शब्दार्थ को भाषा का उपयोग करने के बजाय प्राथमिकताओं से अवगत कराना चाहूंगा। यदि एक फ़ंक्शन को एक आदिम प्रकार पर बुलाया जा सकता है जो अपने वर्तमान शब्दार्थ उपयोग के लिए निरर्थक है, तो यह एक आदिम प्रकार नहीं होना चाहिए, यह एक उचित प्रकार होना चाहिए जिसमें केवल समझदार कार्यों को परिभाषित किया गया हो। (एक उदाहरण के intरूप में, आईडी के रूप में उपयोग करने से एक आईडी को एक आईडी से गुणा करने की अनुमति मिलती है ...)

— Matthieu M.

@ R.Schmitz मुझे लगता है कि आप जो कोड बना रहे हैं उसके लिए ज़िप कोड एक खराब उदाहरण है। कुछ परिवर्तन जो अक्सर अलग Fooऔर FooValidatorवर्गों के लिए एक उम्मीदवार हो सकते हैं। हमारे पास एक ऐसा वर्ग हो सकता है ZipCodeजो प्रारूप को मान्य करता है और ZipCodeValidatorयह जाँचने के लिए कुछ वेब सेवा को हिट करता है कि ZipCodeवास्तव में स्वरूपित वर्तमान है। हम जानते हैं कि ज़िप कोड बदल जाते हैं। लेकिन व्यावहारिक रूप से, हमारे पास ZipCodeकुछ स्थानीय डेटाबेसों में , या किसी स्थानीय डेटाबेस में मान्य ज़िप कोड की सूची होने वाली है ।

— U में कोई

Answer 2

यदि आप कर सकते हैं:

new ZipCode("totally invalid zip code");

और ZipCode के लिए निर्माता करता है:

ZipCodeHelper.validate("totally invalid zip code");

फिर आपने एनकैप्सुलेशन को तोड़ दिया है, और ज़िपकोड क्लास के लिए एक बहुत मूर्खतापूर्ण निर्भरता जोड़ दी है। अगर कंस्ट्रक्टर कॉल नहीं करता है,ZipCodeHelper.validate(...) तो आपके पास वास्तव में इसे लागू किए बिना अपने स्वयं के द्वीप में अलग-अलग तर्क हैं। आप अमान्य ज़िप कोड बना सकते हैं।

validateविधि ज़िपकोड वर्ग पर एक स्थिर विधि होना चाहिए। अब ज़िप कोड कोड के साथ "मान्य" ज़िप कोड का ज्ञान एक साथ बंडल किया गया है। यह देखते हुए कि आपके कोड उदाहरण जावा की तरह दिखते हैं, ZipCode के निर्माता को अपवाद छोड़ देना चाहिए यदि कोई गलत प्रारूप दिया गया है:

public class ZipCode {
    private String zipCode;

    public ZipCode(string zipCode) {
        if (!validate(zipCode))
            throw new IllegalFormatException("Invalid zip code");

        this.zipCode = zipCode;
    }

    public static bool validate(String zipCode) {
        // logic to check format
    }

    @Override
    public String toString() {
        return zipCode;
    }
}

कंस्ट्रक्टर प्रारूप की जाँच करता है और एक अपवाद को फेंकता है, जिससे अमान्य ज़िप कोड बनने से रोका जा सकता है, और स्थिर validateविधि अन्य कोड के लिए उपलब्ध है, इसलिए प्रारूप को चेक करने का तर्क ज़िपकोड कोड में समझाया गया है।

ZipCode वर्ग के इस संस्करण में कोई "यो-यो" नहीं है। इसे सिर्फ उचित ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग कहा जाता है।

---

हम यहां अंतर्राष्ट्रीयकरण को भी नजरअंदाज करने जा रहे हैं, जिसके लिए किसी अन्य वर्ग की आवश्यकता हो सकती है जिसे ZipCodeFormat या पोस्टल सर्विस (जैसे PostalService.isValidPostalCode (...), PostalService.parsePostalCode (...), आदि) की आवश्यकता हो सकती है।

Comments

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

— कुछ गाय

@ R.Schmitz: ZipCode.validateविधि प्री-चेक है जो एक अपवाद को फेंकने वाले कंस्ट्रक्टर को लागू करने से पहले किया जा सकता है।

— ग्रेग बरगार्ड

@ R.Schmitz: यदि आप एक अपवाद के बारे में चिंतित हैं, तो निर्माण के लिए एक वैकल्पिक तरीका है ज़िपकोड निर्माणकर्ता को निजी बनाना, और एक सार्वजनिक स्थैतिक कारखाना फ़ंक्शन (Zipcode.create?) प्रदान करना जो पारित मापदंडों के सत्यापन को पूरा करता है? असफल होने पर अशक्त देता है, और अन्यथा एक ज़िपकोड ऑब्जेक्ट का निर्माण करता है और इसे वापस करता है। कॉल करने वाले को हमेशा अशक्त रिटर्न वैल्यू की जांच करनी होगी। दूसरी ओर, यदि आप आदत में हैं, उदाहरण के लिए, हमेशा एक ज़िपकोड का निर्माण करने से पहले (regex? Validate? आदि) को मान्य किया जाए, तो अपवाद व्यवहार में इतना अप्रिय नहीं हो सकता है।

— कुछ गाय

एक फैक्ट्री फ़ंक्शन जो एक वैकल्पिक <ZipCode> लौटाता है, वह भी एक संभावना है। फिर फोन करने वाले के पास फैक्ट्री फ़ंक्शन की संभावित विफलता को स्पष्ट रूप से संभालने के अलावा कोई विकल्प नहीं है। भले ही, किसी भी मामले में, त्रुटि को कहीं के पास खोजा जाएगा जहां इसे मूल समस्या से बहुत दूर क्लाइंट कोड द्वारा संभवत: बाद में बनाया गया था।

— कुछ गाय

आप ज़िपकोड को अनिश्चित काल के लिए मान्य नहीं कर सकते, इसलिए नहीं। ज़िपकोड / पोस्टकोड सत्यापन नियमों को देखने के लिए आपको वास्तव में देश की वस्तु चाहिए।

— जोशुआ

Answer 3

यदि आप इस प्रश्न के साथ बहुत कुश्ती करते हैं, तो शायद आप जिस भाषा का उपयोग करते हैं वह नौकरी के लिए सही उपकरण नहीं है? इस तरह के "डोमेन-टाइप प्राइमिटिव्स" को उदाहरण के लिए, एफ # में व्यक्त करना बहुत आसान है।

उदाहरण के लिए, आप लिख सकते हैं:

type ZipCode = ZipCode of string
type Town = Town of string

type Adress = {
  zipCode: ZipCode
  town: Town
  //etc
}

let adress1 = {
  zipCode = ZipCode "90210"
  town = Town "Beverly Hills"
}

let faultyAdress = {
  zipCode = "12345"  // <-Compiler error
  town = adress1.zipCode // <- Compiler error
}

यह सामान्य गलतियों से बचने के लिए वास्तव में उपयोगी है, जैसे विभिन्न संस्थाओं की आईडी की तुलना करना। और चूंकि ये टाइप की गई प्राइमिटिव्स सी # या जावा-क्लास की तुलना में बहुत अधिक हल्की हैं, आप वास्तव में उनका उपयोग करेंगे।

Comments

दिलचस्प है - अगर आप सत्यापन को लागू करना चाहते हैं तो यह कैसा लगेगा ZipCode?

— हल्क

@ हेलक आप ओ # में ओ-स्टाइल लिख सकते हैं और कक्षाओं में प्रकार बना सकते हैं। हालांकि, मैं कार्यात्मक शैली पसंद करता हूं, टाइप ज़िपकोड के प्रकार के साथ = स्ट्रिंग के निजी ज़िपकोड की घोषणा करता हूं और एक बनाएं फ़ंक्शन के साथ एक ज़िपकोड मॉड्यूल जोड़ता हूं। वहाँ कुछ उदाहरण यहां हैं: gist.github.com/swlaschin/54cfff886669ccab895a

— Guran

@ बेंट-ट्रैनबर्ग संपादन के लिए धन्यवाद। आप सही हैं, एक साधारण प्रकार का संक्षिप्त नाम संकलन समय सुरक्षा नहीं देता है।

— गुरान

यदि आपको मेरी पहली टिप्पणी मेल की गई थी, जिसे मैंने हटा दिया, तो इसका कारण यह था कि मैंने पहले आपके स्रोत को गलत समझा। मैंने इसे ध्यान से नहीं पढ़ा। जब मैंने इसे संकलित करने की कोशिश की, तो मुझे अंत में एहसास हुआ कि आप वास्तव में इसे प्रदर्शित करने की कोशिश कर रहे थे, इसलिए मैंने इसे ठीक करने के लिए संपादन करने का फैसला किया।

— बेंट ट्रानबर्ग

हाँ। मेरा मूल स्रोत वैध रूप से मान्य था, दुर्भाग्यवश उस उदाहरण को शामिल किया गया जिसे अमान्य माना गया था। रवींद्र! सिर्फ अपने आप टाइपिंग कोड के बजाय Wlaschin से जुड़ा हुआ हवलदार चाहिए :) fsharpforfunandprofit.com/posts/...

— Guran

Answer 4

उत्तर पूरी तरह से इस बात पर निर्भर करता है कि आप वास्तव में ज़िप कोड के साथ क्या करना चाहते हैं। यहां दो अत्यधिक संभावनाएं हैं:

(१) सभी पते एक ही देश में होने की गारंटी है। कोई अपवाद नहीं है। (जैसे कोई विदेशी ग्राहक, या कोई भी कर्मचारी जिसका निजी पता विदेश में नहीं है, जबकि वे एक विदेशी ग्राहक के लिए काम कर रहे हैं।) इस देश में ज़िप कोड हैं और उनसे कभी भी गंभीर समस्या नहीं होने की उम्मीद की जा सकती है (अर्थात उन्हें फ्री-फॉर्म इनपुट की आवश्यकता नहीं है। जैसे कि "वर्तमान में D4B 6N2, लेकिन यह हर 2 सप्ताह में बदल जाता है")। ज़िप कोड का उपयोग केवल पते के लिए नहीं किया जाता है, बल्कि भुगतान की जानकारी या इसी तरह के उद्देश्यों के सत्यापन के लिए किया जाता है। - इन परिस्थितियों में, एक ज़िप कोड क्लास बहुत मायने रखता है।

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

Answer 5

अन्य उत्तरों ने OO डोमेन मॉडलिंग और आपके मूल्य का प्रतिनिधित्व करने के लिए एक समृद्ध प्रकार का उपयोग करने के बारे में बात की है।

मैं असहमत नहीं हूं, विशेष रूप से आपके द्वारा पोस्ट किए गए उदाहरण कोड को देखते हुए।

लेकिन मुझे यह भी आश्चर्य है कि क्या वास्तव में आपके प्रश्न का शीर्षक उत्तर है।

निम्नलिखित परिदृश्य पर विचार करें (वास्तविक परियोजना से काम कर रहा हूं)

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

इस परिदृश्य में, SQL regex बाधा (या इसके ORM समतुल्य) के साथ सम्मिलित को मान्य करने से परे कुछ भी करने से संभवतः YAGNI विविधता का ओवरकिल हो जाता है।

Comments

आपके SQL रेगेक्स बाधा को एक योग्य प्रकार के रूप में देखा जा सकता है - आपके डेटाबेस में, ज़िप कोड "VarChar" के रूप में संग्रहीत नहीं है, लेकिन "VarChar इस नियम से विवश है"। कुछ DBMSes में, आप आसानी से उस प्रकार + बाधा को एक पुन: प्रयोज्य "डोमेन प्रकार" के रूप में नाम दे सकते हैं, और हम डेटा को सार्थक प्रकार देने की अनुशंसित जगह पर वापस आ गए हैं। मैं सिद्धांत रूप में आपके उत्तर से सहमत हूं, लेकिन यह मत सोचो कि उदाहरण से मेल खाता है; एक बेहतर उदाहरण होगा यदि आपका डेटा "रॉ सेंसर डेटा" है, और सबसे सार्थक प्रकार "बाइट सरणी" है, क्योंकि आपको पता नहीं है कि डेटा का क्या मतलब है।

— IMSoP

@IMSoP दिलचस्प बिंदु। मुझे यकीन नहीं है कि मैं सहमत हूँ: आप जावा में एक स्ट्रिंग ज़िप कोड (या किसी अन्य भाषा) को एक रेगेक्स के साथ मान्य कर सकते हैं लेकिन फिर भी एक अमीर प्रकार के बजाय एक स्ट्रिंग के रूप में इसके साथ काम कर रहे हैं। डोमेन लॉजिक के आधार पर, आगे हेरफेर की आवश्यकता हो सकती है (उदाहरण के लिए यह सुनिश्चित करना कि ज़िप कोड राज्य से मेल खाता है, ऐसा कुछ जो regex के साथ मान्य करना मुश्किल / असंभव होगा)।

— जारेड स्मिथ

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

— IMSoP

आप ऐसी चीज़ को मॉडल कर सकते हैं RegexValidatedString, जिसमें स्ट्रिंग ही होती है और रेगेक्स इसे मान्य करता था। लेकिन जब तक कि हर उदाहरण में एक अद्वितीय रेगेक्स (जो संभव नहीं है, लेकिन असंभव है) यह स्मृति का थोड़ा मूर्खतापूर्ण और बेकार लगता है (और संभवतः रेगेक्स संकलन समय)। तो आप या तो रेगेक्स को एक अलग तालिका में डालते हैं और इसे खोजने के लिए प्रत्येक उदाहरण में एक लुकअप कुंजी छोड़ देते हैं (जो कि अप्रत्यक्ष रूप से बदतर है) या आप इसे नियम साझा करने वाले प्रत्येक सामान्य प्रकार के मूल्य के लिए एक बार स्टोर करने का कोई तरीका ढूंढते हैं - - जैसे। एक डोमेन प्रकार, या समकक्ष विधि पर एक स्थिर क्षेत्र, जैसा कि IMSoP ने कहा है।

— मिरल

Answer 6

ZipCodeअमूर्त केवल मतलब सकता है अगर अपने Addressवर्ग भी एक नहीं था TownNameसंपत्ति। अन्यथा, आपके पास आधा अमूर्त है: ज़िप कोड शहर को नामित करता है, लेकिन जानकारी के इन दो संबंधित बिट्स विभिन्न वर्गों में पाए जाते हैं। यह काफी मतलब नहीं है।

हालाँकि, फिर भी, यह अभी भी आदिम जुनून का एक सही अनुप्रयोग (या समाधान नहीं) है; जैसा कि, मैं इसे समझता हूं, मुख्य रूप से दो चीजों पर केंद्रित है:

1. एक विधि के इनपुट (या यहां तक ​​कि आउटपुट) मूल्यों के रूप में आदिम का उपयोग करना, विशेष रूप से जब आदिम का एक संग्रह की आवश्यकता होती है।
2. कक्षाएं जो समय के साथ कभी-कभी पुनर्विचार के बिना अतिरिक्त गुण विकसित करती हैं, क्या इनमें से कुछ को अपने स्वयं के उपवर्ग में वर्गीकृत किया जाना चाहिए।

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

इस तरह से आप जानते हैं कि आपको किसी भी तरह से वश में करने की आवश्यकता नहीं है: इसे नीचे तोड़ना किसी भी Addressवर्ग के कार्यात्मक इरादे से अलग होगा । इसी तरह, आपको कक्षा Nameमें उपयोग किए जाने वाले उपवर्ग की आवश्यकता नहीं है Person, जब तक कि Name(बिना किसी संलग्न व्यक्ति के) आपके डोमेन में एक सार्थक अवधारणा नहीं है। यह (आमतौर पर) नहीं है। लोगों की पहचान के लिए नामों का उपयोग किया जाता है, आमतौर पर उनका कोई मूल्य नहीं होता है।

Comments

@ रिकड: उत्तर से: " जब तक नाम (बिना किसी संलग्न व्यक्ति के) आपके डोमेन में एक सार्थक अवधारणा है , तब तक आपको कक्षा Nameमें उपयोग होने वाले उपवर्ग की आवश्यकता नहीं है ।" Personजब आपके पास नामों के लिए कस्टम सत्यापन है, तो नाम आपके डोमेन में एक सार्थक अवधारणा बन गया है; जो मैंने उप-प्रकार का उपयोग करने के लिए एक वैध उपयोग के मामले के रूप में स्पष्ट रूप से उल्लेख किया है। दूसरे, ज़िपकोड सत्यापन के लिए, आप अतिरिक्त मान्यताओं का परिचय दे रहे हैं, जैसे ज़िप कोड किसी दिए गए देश के प्रारूप का पालन करने की आवश्यकता है। आप ऐसे विषय पर ब्रोकिंग कर रहे हैं जो ओपी के प्रश्न के इरादे से बहुत व्यापक है।

— Flater

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

— आर। श्मिट

@ ठीक वैसे ही मैं आपको झूठ की पूरी सूची को नहीं पढ़ने के लिए दोषी नहीं ठहराऊंगा, क्योंकि यह काफी लंबा है, लेकिन इसमें "पते में एक सड़क होगी", "एक पते के लिए एक शहर और एक देश दोनों की आवश्यकता होती है", "एक पता एक पोस्टकोड होगा "आदि, जो उद्धृत वाक्य के विपरीत है।

— आर। श्मिट

@GregBurghardt "ज़िप कोड संयुक्त राज्य डाक सेवा मानता है, और आप शहर का नाम ज़िप कोड से प्राप्त कर सकते हैं। शहरों में कई ज़िप कोड हो सकते हैं, लेकिन प्रत्येक ज़िप कोड केवल 1 शहर से जुड़ा होता है।" यह सामान्य रूप से सही नहीं है। मेरे पास एक ज़िपकोड है जो मुख्य रूप से पड़ोसी शहर के लिए उपयोग किया जाता है लेकिन मेरा निवास वहां नहीं है। जिपकोड हमेशा सरकारी सीमाओं के साथ संरेखित नहीं होते हैं। उदाहरण के लिए 42223 में TN और KY दोनों की काउंटियां हैं ।

— जिमीजैम

ऑस्ट्रिया में एक घाटी मौजूद है जो केवल जर्मनी ( en.wikipedia.org/wiki/Kleinwalsertal ) से सुलभ है । इस क्षेत्र के लिए एक विशेष संधि मौजूद है, जिसमें अन्य बातों के अलावा, यह भी शामिल है कि इस क्षेत्र में ऑस्ट्रियाई और जर्मन पोस्ट कोड दोनों हैं। इसलिए सामान्य तौर पर, आप यह भी नहीं मान सकते हैं कि एक पते में केवल एक ही वैध पोस्टल कोड है;)

— हल्क

Answer 7

लेख से:

आम तौर पर, यो-यो समस्या किसी भी स्थिति को संदर्भित कर सकती है, जहां किसी व्यक्ति को किसी अवधारणा को समझने के लिए सूचना के विभिन्न स्रोतों के बीच फ़्लिप करते रहना चाहिए।

स्रोत कोड को जितना लिखा जाता है, उससे कहीं अधिक बार पढ़ा जाता है। इस प्रकार, कई फाइलों के बीच स्विच करने की यो-यो समस्या एक चिंता का विषय है।

हालाँकि, नहीं , जब आप अन्योन्याश्रित मॉड्यूल या वर्गों (जो एक दूसरे के बीच आगे-पीछे कॉल करते हैं) के साथ काम करते समय यो-यो समस्या अधिक प्रासंगिक लगती है। वे पढ़ने के लिए एक विशेष प्रकार के दुःस्वप्न हैं, और संभावित रूप से यो-यो समस्या के संचयक के दिमाग में क्या था।

हालाँकि - हाँ , अमूर्तता की कई परतों से बचना ज़रूरी है!

सभी गैर-तुच्छ सार, कुछ हद तक टपका हुआ है। - लीक के सार का नियम।

उदाहरण के लिए, मैं मिमीमा के जवाब में की गई धारणा से असहमत हूं कि "आपको पता वर्ग को समझने के लिए ज़िपकोड कोड [(यात्रा)] के लिए यो-यो करने की आवश्यकता नहीं है"। मेरा अनुभव है कि आप ऐसा करते हैं - कम से कम पहली बार जब आप कोड पढ़ते हैं। हालांकि, जैसा कि अन्य ने नोट किया है, ऐसे समय होते हैं जब कोई ZipCodeवर्ग उपयुक्त होता है।

YAGNI (हां गोना नहीं है, यह की आवश्यकता है) लज़ान्या कोड (कोड भी कई परतों के साथ) से बचने के लिए पालन करने के लिए एक बेहतर स्वरूप है - जैसे प्रकार के रूप में संक्षेपण हैं, और कक्षाओं प्रोग्रामर वहाँ सहायता करने के लिए कर रहे हैं, और जब तक वे नहीं किया जाना चाहिए रहे हैं एक सहायता।

मैं व्यक्तिगत रूप से "कोड की पंक्तियों को बचाने" (और निश्चित रूप से संबंधित "सहेजें फ़ाइलें / मॉड्यूल / कक्षाएं", आदि) का लक्ष्य रखता हूं। मुझे विश्वास है कि कुछ ऐसे भी हैं जो मुझ पर "आदिम जुनूनी" का भाव लागू करेंगे - मुझे लगता है कि कोड के लिए अधिक महत्वपूर्ण है जो लेबल, पैटर्न और विरोधी पैटर्न के बारे में चिंता करना आसान है । किसी फ़ंक्शन, मॉड्यूल / फ़ाइल / क्लास को बनाते समय या किसी सामान्य स्थान पर फ़ंक्शन को रखने का सही विकल्प बहुत स्थितिजन्य है। मैं पुन: प्रयोज्य पुस्तकालय कोड के लिए 3-100 लाइन फ़ंक्शन, 80-500 लाइन फ़ाइलों, और "1, 2, n" के लिए मोटे तौर पर लक्ष्य रखता हूं ( एसएलओसी - टिप्पणियों या बॉयलरप्लेट शामिल नहीं है; मैं आमतौर पर कम से कम 1 अतिरिक्त एसएलओसी न्यूनतम प्रति पंक्ति चाहता हूं। बॉयलरप्लेट)।

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

तो - हाँ , कभी-कभी ZipCode एक अच्छा वर्ग होता है। हालांकि, नहीं , यो-यो समस्या कड़ाई से प्रासंगिक नहीं है।

Answer 8

यो-यो समस्या केवल तभी प्रासंगिक है जब आपको आगे और पीछे फ्लिप करना है। यह एक या दो चीजों (कभी-कभी दोनों) के कारण होता है:

1. बुरा नामकरण। ZipCode ठीक लगता है, ZoneImprovementPlanCode को अधिकांश लोगों द्वारा एक नज़र की आवश्यकता है (और कुछ जो प्रभावित नहीं होंगे)।
2. अनुचित युग्मन। आप कहें कि ज़िपकोड क्लास में एक एरिया कोड लुकअप है। आपको लगता है कि यह समझ में आता है क्योंकि यह आसान है, लेकिन यह वास्तव में ZipCode से संबंधित नहीं है, और इसमें इसे शामिल करने का मतलब है कि अब लोग नहीं जानते कि चीजों के लिए कहां जाना है।

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

Answer 9

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