जावा में स्ट्रिंग्स का उपयोग कभी न करें? [बन्द है]

73

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

public void bookTicket(
  String name,
  String firstName,
  String film,
  int count,
  String cinema);

public void bookTicket(
  Name name,
  FirstName firstName,
  Film film,
  Count count,
  Cinema cinema);

प्रोग्रामिंग ब्लॉग पढ़ने के अपने अनुभव में मैं इस निष्कर्ष पर पहुंचा हूं कि 90% बकवास है, लेकिन मैं सोच रहा हूं कि क्या यह एक वैध बिंदु है। किसी तरह यह मेरे लिए सही नहीं लगता है, लेकिन मैं बिल्कुल नहीं बता सकता कि प्रोग्रामिंग की शैली के साथ क्या है।

java coding-style semantics

— DPM
स्रोत

मूल विकी पर प्रासंगिक चर्चा: "वह क्या है?

— क्रिस्टोफर हम्मरस्ट्रॉम 15

5

अरे वाह, कि ब्लॉग पोस्ट मुझे शारीरिक रूप से बीमार महसूस किए गए

— रोब

5

मैंने कम से कम एक पुस्तक (जो कि कोड कम्पलीट का पहला संस्करण हो सकता है) पढ़ी है, जिसने समस्या वाले डोमेन से आपके सभी आदिम प्रकारों के नाम लिखने की सिफारिश की है। एक ही विचार।

— user16764

9

"कभी नहीं" के साथ शुरू होने वाला एक बयान "हमेशा" झूठा है!

— फ्लोरेंट्स त्सेलाई

1

वह आदमी एक CTO है ?!

— हाइजेलो

88

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

संपादित करें: मैंने ब्लॉग पोस्ट पढ़ी है और उसके पास मौलिक रूप से अच्छा विचार है। समस्या यह है कि उसने इसे बहुत दूर तक बढ़ा दिया है। की तरह कुछ String orderId है , वास्तव में बुरा है क्योंकि शायद "!"£$%^&*())ADAFVFनहीं एक वैध है orderId। इसका मतलब यह है कि Stringमान्य orderIds की तुलना में बहुत अधिक संभावित मूल्यों का प्रतिनिधित्व करता है । हालाँकि, जैसे कुछ के लिए name, तो आप संभवतः यह अनुमान नहीं लगा सकते हैं कि एक वैध नाम क्या हो सकता है या नहीं, और कोई भी Stringमान्य है name।

पहले उदाहरण में, आप केवल सही लोगों के लिए संभावित आदानों को कम कर रहे हैं (सही ढंग से)। दूसरे उदाहरण में, आपने संभावित वैध इनपुट्स को कम नहीं किया है।

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

— DeadMG
स्रोत

5

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

— मैल्कम

13

@ मैल्कम: लेकिन फिर आपके पास यह जानने का कोई तरीका नहीं है कि स्ट्रिंग्स को बार-बार मान्य करने के अलावा कौन से मान्य हैं।

— डेडएमजी

7

"[...] आप संभवतः यह अनुमान नहीं लगा सकते हैं कि क्या वैध नाम हो सकता है या नहीं भी हो सकता है, और कोई स्ट्रिंग एक वैध नाम है।" मुझे लगता है कि इस तकनीक की एक ताकत यह है कि यदि आपका पैरामीटर प्रकार का है Name, तो आप गलती से किसी अन्य असंबंधित स्ट्रिंग मान को पारित नहीं कर सकते हैं। जहाँ आप उम्मीद करते हैं Name, केवल एक Nameसंकलन होगा, और स्ट्रिंग "मैं आपको $ 5 का बकाया है" गलती से स्वीकार नहीं किया जा सकता है। (ध्यान दें कि यह किसी भी प्रकार के नाम सत्यापन से संबंधित नहीं है!)

— एंड्रेस एफ।

6

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

— दत्त

3

@DeadMG यह तर्कपूर्ण है, और कुछ नहीं जो हम टिप्पणियों में हल कर सकते हैं। मैं कहूंगा कि आदिम प्रकार के मूल्यों का गलत इस्तेमाल होता है, और अपने इंटरफेस को सख्त करना स्थिति को सुधारने का एक तरीका है।

— एंड्रेस एफ।

46

वो तो बस पागल है :)

सामान्य ज्ञान का उपयोग करें
इंजीनियर पर मत!
इसे छोटा सरल रखें!
आप अरेंट गॉन नीड इट (यागनी)

— Makach
स्रोत

2

मेरी भी यही राय है, लेकिन बात यह है कि मुझे यह सुझाव "कोड कम्प्लीट" में याद है। बेशक उस पुस्तक में सब कुछ निर्विवाद नहीं है, लेकिन कम से कम यह मुझे एक विचार को खारिज करने से पहले दो बार सोचता है।

— DPM

8

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

— Andres F.

12

सामान्य ज्ञान कुछ भी लेकिन आम है।

— कज़ ड्रैगन

1

+1, इसमें मैं यह जोड़ूंगा कि जब कोई भाषा नामित मापदंडों का समर्थन करती है, और IDE अच्छा है, तो C # और VS2010 के मामले में ऐसा है, तो किसी को पागल पैटर्न के साथ भाषा में सुविधाओं की कमी के लिए क्षतिपूर्ति करने की आवश्यकता नहीं है। । X नामक वर्ग और Y नामक किसी वर्ग की आवश्यकता नहीं है, यदि कोई भी लिख सकता है var p = new Point(x: 10, y:20);, तो ऐसा नहीं है कि सिनेमा स्ट्रिंग से भिन्न है। मैं समझ सकता हूं कि क्या किसी को भौतिक मात्रा, जैसे कि दबाव, तापमान, ऊर्जा से निपटना है, जहां इकाइयां अलग हैं और कुछ नकारात्मक नहीं हो सकते। ब्लॉग के लेखक को कार्यात्मक प्रयास करने की आवश्यकता है।

— अय्यूब

1

+1 के लिए "ओवर-इंजीनियर मत बनो!"

— इवान

23

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

— केविन क्लाइन
स्रोत

2

क्या डाउनर टिप्पणी कर सकता है?

— केविन क्लाइन

स्थैतिक टाइपिंग के लिए हम जो उच्च मूल्य चुका रहे हैं, वह क्या है?

— रिचर्ड टिंगल

@RichardTingle: कोड को फिर से जोड़ने और हर कोड परिवर्तन के लिए JVM को पुनरारंभ करने का समय। जब आप स्रोत-संगत लेकिन द्विआधारी-असंगत परिवर्तन करते हैं और खोई हुई चीजों को पुन: संकलित करने की आवश्यकता होती है, तो आपको "मिसिंगमेथोडएक्ससेप्शन" नहीं मिलता है।

— केविन क्लाइन

मैंने जावा अनुप्रयोगों के साथ एक समस्या का कभी अनुभव नहीं किया है (निरंतर संकलन के साथ यह आमतौर पर पहले से ही मेरे द्वारा चलाए जा रहे समय से संकलित है), लेकिन यह वेब वार्स के साथ एक उचित बिंदु है जिसके लिए पुन: नियोजन थोड़ा धीमा लगता है

— रिचर्ड टिंगल

16

यह मत करो; यह सामान को पूरा करेगा और आपको इसकी आवश्यकता नहीं होगी

... जवाब है कि मैंने 2 साल पहले यहां लिखा होगा। अब, हालांकि, मुझे यकीन नहीं है; वास्तव में, हाल के महीनों में मैंने इस प्रारूप में पुराने कोड को माइग्रेट करना शुरू कर दिया है, इसलिए नहीं कि मेरे पास करने के लिए बेहतर कुछ भी नहीं है, क्योंकि मुझे नई सुविधाओं को लागू करने या मौजूदा लोगों को बदलने के लिए वास्तव में इसकी आवश्यकता है। मैं समझता हूं कि अन्य लोगों ने यहां उस कोड को देखा है, लेकिन मुझे लगता है कि यह एक ऐसी चीज है जो गंभीर विचार के योग्य है।

लाभ

लाभ के बीच मुख्य कोड को संशोधित करने और विस्तारित करने की क्षमता है । यदि तुम प्रयोग करते हो

class Point {
    int x,y;
    // other point operations
}

इसके बजाय केवल दो पूर्णांकों को पास करने के बजाय - जो कुछ ऐसा है, दुर्भाग्य से, कई इंटरफेस करते हैं - फिर बाद में एक और आयाम जोड़ना आसान हो जाता है। या करने के लिए प्रकार बदलें double। यदि आप इसका उपयोग करते हैं List<Author> authorsया List<Person> authorsइसके बजाय List<String> authorsबाद में एक लेखक का प्रतिनिधित्व करने के लिए अधिक जानकारी जोड़ने के लिए बहुत आसान हो जाता है। इसे इस तरह से लिखना यह महसूस करता है कि मैं स्पष्ट कह रहा हूं, लेकिन व्यवहार में मैं कई बार खुद इस तरह से तार का उपयोग करने का दोषी हूं, खासकर उन मामलों में जहां यह शुरू में स्पष्ट नहीं था, फिर मुझे इससे अधिक की आवश्यकता होगी एक स्ट्रिंग।

मैं वर्तमान में कुछ स्ट्रिंग सूची को रिफैक्ट करने की कोशिश कर रहा हूं जो मेरे पूरे कोड में इंटरवेट की गई है क्योंकि मुझे वहां अधिक जानकारी की आवश्यकता है, और मुझे दर्द महसूस होता है। "

इसके अलावा, मैं ब्लॉग के लेखक से सहमत हूं कि यह अधिक अर्थ संबंधी जानकारी देता है , जिससे पाठक को समझने में आसानी होती है। जबकि मापदंडों को अक्सर सार्थक नाम दिए जाते हैं और प्रलेखन की एक समर्पित रेखा मिलती है, यह अक्सर फ़ील्ड या स्थानीय लोगों के साथ ऐसा नहीं होता है।

अंतिम लाभ स्पष्ट कारणों के लिए, प्रकार की सुरक्षा है, लेकिन मेरी नजर में यह एक मामूली बात है।

कमियां

लिखने में अधिक समय लगता है । एक छोटा वर्ग लिखना तेज और आसान है, लेकिन सरल नहीं है, खासकर यदि आपको इन वर्गों की बहुत आवश्यकता है। यदि आप कुछ नए रैपर क्लास को लिखने के लिए हर 3 मिनट में खुद को रोक पाते हैं, तो यह आपकी एकाग्रता के लिए एक वास्तविक बाधा भी हो सकती है। हालाँकि, मुझे लगता है कि इस प्रयास की अवस्था आम तौर पर किसी भी कोड को लिखने के पहले चरण में होगी; मैं आमतौर पर एक बहुत अच्छा विचार प्राप्त कर सकता हूं कि संस्थाओं को शामिल होने की क्या आवश्यकता है।

इसमें बहुत अधिक निरर्थक बसने वाले (या निर्माण) और गेटर्स शामिल हो सकते हैं । ब्लॉग लेखक new Point(x(10), y(10))इसके बजाय वास्तव में बदसूरत उदाहरण देता है new Point(10, 10), और मैं यह जोड़ना चाहूंगा कि उपयोग में भी Math.max(p.x.get(), p.y.get())इसके बजाय सामान शामिल हो सकता है Math.max(p.x, p.y)। और लंबे कोड को अक्सर पढ़ने के लिए कठिन माना जाता है, और बस इतना ही। लेकिन सभी ईमानदारी में, मुझे लगता है कि बहुत सारी कोड ऑब्जेक्ट्स को इधर-उधर ले जाती है, और केवल चुनिंदा तरीके ही इसे बनाते हैं, और इसके कम विवरण तक पहुँच की भी कम आवश्यकता होती है (जो वैसे भी OOPy नहीं है)।

विवादास्पद

मैं कहूंगा कि यह कोड की पठनीयता के साथ मदद करता है या नहीं यह बहस का मुद्दा है। हां, अधिक अर्थ संबंधी जानकारी, लेकिन लंबे समय तक कोड। हां, प्रत्येक स्थानीय की भूमिका को समझना आसान है, लेकिन यह समझना कठिन है कि आप इसके साथ क्या कर सकते हैं जब तक आप जाकर इसके प्रलेखन को नहीं पढ़ते।

सोचा के अधिकांश अन्य प्रोग्रामिंग स्कूलों के साथ, मुझे लगता है कि यह एक को चरम पर ले जाने के लिए अस्वस्थ है। मैं अपने आप को कभी भी x और y को अलग करते हुए नहीं देखता हूँ। मुझे लगता Countहै कि जब एक intपर्याप्त होना आवश्यक नहीं है । मैं unsigned intसी में उपयोग को नापसंद करता हूं - जबकि सैद्धांतिक रूप से अच्छा है, यह सिर्फ आपको पर्याप्त जानकारी नहीं देता है, और यह आपके कोड को बाद में उस जादुई -1 का समर्थन करने के लिए प्रतिबंधित करता है। कभी-कभी आपको सादगी की आवश्यकता होती है।

मुझे लगता है कि ब्लॉग पोस्ट चरम पक्ष पर एक सा है। लेकिन कुल मिलाकर, मैंने दर्दनाक अनुभव से सीखा है कि इसके पीछे मूल विचार सही सामान से बना है।

मेरे पास ओवर-इंजीनियर कोड के लिए एक गहरा विरोध है। मैं वास्तव में करते हैं। लेकिन सही इस्तेमाल किया, मुझे नहीं लगता कि यह ओवर-इंजीनियरिंग है।

— बलूत
स्रोत

5

हालाँकि यह एक तरह का ओवरकिल है, मैं अक्सर सोचता हूँ कि मैंने जो भी सामान देखा है, उसकी जगह अंडर-इंजीनियर है।

यह सिर्फ "सुरक्षा" नहीं है, जावा के बारे में वास्तव में अच्छी चीजों में से एक यह है कि यह आपको याद रखने में मदद करता है / पता लगाता है कि किसी भी लाइब्रेरी पद्धति को कॉल की जरूरत / अपेक्षाएं क्या हैं।

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

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

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

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

मैं वास्तव में एक अच्छी तरह से लिखा जावा परियोजना को देखने के लिए दिलचस्पी लेता हूं जो वास्तव में बहुत अधिक कक्षाएं परिभाषित थीं (जहां यह प्रोग्राम को कठिन बना देता है), मुझे लगता है कि बहुत अधिक कक्षाएं होना संभव नहीं है।

— बिल के
स्रोत

3

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

public void bookTicket(
  String name,
  String firstName,
  String film,
  int count,
  String cinema);

टिकटों की बुकिंग करने वाले वास्तविक संरक्षक को निर्दिष्ट करने के लिए दो मापदंडों की आवश्यकता होती है, हो सकता है कि आपके पास समान नाम (जैसे रीमेक) के साथ दो अलग-अलग फिल्में हों, आपके पास अलग-अलग नामों (जैसे अनुवाद) के साथ एक ही फिल्म हो सकती है। फिल्म थिएटर की एक निश्चित श्रृंखला विभिन्न शाखा कार्यालयों हो सकता है, तो आप कैसे एक स्ट्रिंग में और एक सुसंगत तरीके से कि से निपटने के लिए जा रहे हैं (उदाहरण के लिए प्रयोग कर रहे हैं $chain ($city)या $chain in $cityया यहाँ तक कि कुछ और और कैसे आप यकीन है कि यह है बनाने जा रहे हैं लगातार उपयोग किया जाता है। सबसे खराब वास्तव में आपके संरक्षक को दो मापदंडों के माध्यम से निर्दिष्ट कर रहा है, यह तथ्य कि पहले नाम और उपनाम दोनों प्रदान किए गए हैं, एक वैध ग्राहक की गारंटी नहीं देता है (और आप दो John Doeएस को अलग नहीं कर सकते हैं )।

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

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

प्रस्तावित विकल्प बेहतर है:

public void bookTicket(
  Name name,
  FirstName firstName,
  Film film,
  Count count,
  Cinema cinema);

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

इसके लायक क्या है, मैं वास्तव में कुछ लिखूंगा

public Ticket bookTicket(
  Person patron,
  Film film,
  int numberOfTickets,
  Cinema cinema);

लंबी कहानी छोटी: आपको निरर्थक चर नहीं होना चाहिए; केवल एक बार आप वास्तव में एक वस्तु को उस मूल्य के साथ निर्दिष्ट करेंगे जो वास्तविक वस्तु का निर्धारण नहीं करता है, जब आप या तो एक क्वेरी (जैसे public Collection<Film> findFilmsWithTitle(String title)) चलाते हैं या जब आप एक साथ एक सबूत की अवधारणा डाल रहे हैं। अपने प्रकार के सिस्टम को साफ रखें, इसलिए एक ऐसे प्रकार का उपयोग न करें जो बहुत सामान्य हो (जैसे कि क द्वारा दर्शाई गई मूवी String) या बहुत अधिक प्रतिबंधात्मक / विशिष्ट / आकस्मिक (जैसे के Countबजाय int)। एक प्रकार का प्रयोग करें जो जब भी संभव हो और व्यवहार्य रूप से आपकी वस्तु को विशिष्ट और स्पष्ट रूप से परिभाषित करता है।

संपादित करें : एक छोटा सारांश भी। छोटे अनुप्रयोगों के लिए (जैसे अवधारणाओं का प्रमाण): एक जटिल डिजाइन के साथ परेशान क्यों? बस का उपयोग करें Stringया intइसके साथ मिलता है।

बड़े अनुप्रयोगों के लिए: क्या यह वास्तव में संभावना है कि आपके पास बहुत सारी कक्षाएं हैं जिनमें एक बुनियादी डेटा प्रकार के साथ एक एकल फ़ील्ड शामिल है? यदि आपके पास ऐसी छोटी कक्षाएं हैं, तो आपके पास "सामान्य" वस्तुएं हैं, वहां कुछ खास नहीं चल रहा है।

मैं स्ट्रैप्स को एन्कैप्स करने के विचार को महसूस करता हूं, ... बस एक डिजाइन है जो अधूरा है: छोटे अनुप्रयोगों के लिए अत्यधिक जटिल, बड़े अनुप्रयोगों के लिए पर्याप्त नहीं।

— एगोन
स्रोत

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

— DPM

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

— इगन

2

मेरे लिए ऐसा करना C # में क्षेत्रों का उपयोग करने के समान है। आम तौर पर अगर आपको लगता है कि आपके कोड को पठनीय बनाने के लिए यह आवश्यक है तो आपको बड़ी समस्याएं हैं जिन्हें आपको अपना समय बिताना चाहिए।

— टॉम स्क्वायर्स
स्रोत

2

कारण के बजाय लक्षणों के उपचार को लागू करने के लिए +1।

— अय्यूब

2

मैं कहूंगा कि यह एक भाषा में एक बहुत अच्छा विचार है जिसमें एक दृढ़ता से टाइप किए गए प्रकार की सुविधा है।

जावा में आपके पास ऐसा नहीं है इसलिए इन चीजों के लिए पूरी नई कक्षा बनाने का मतलब है कि लागत शायद लाभ को कम कर देती है। आप अपने वैरिएबल / पैरामीटर नामकरण के बारे में सावधान रहकर भी 80% लाभ प्राप्त कर सकते हैं।

— जे।
स्रोत

0

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

और इसके "गुडनेस" में वृद्धि होती है जब उदाहरण के लिए। सभी नामों पर प्रतिबंध।

लेकिन जब कुछ एप्लिकेशन (लाइब्रेरी नहीं) का निर्माण करते हैं, तो इसे हमेशा रिफैक्ट करना संभव है। इसलिए मैं इसके बिना शुरू करने का प्रस्ताव करता हूं।

— user470365
स्रोत

0

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

— thSoft
स्रोत

@downvoter: क्या आप कृपया स्पष्टीकरण दे सकते हैं?

— thSoft