हम कभी-कभी जावा

Question

में कक्षाओं से व्यवहार को अलग क्यों करते हैं, यह एक बहुत ही बुनियादी सवाल है, लेकिन मैं जावा डिज़ाइनिंग में नया हूं, कृपया क्षमा करें। :)

मैं जानना चाहता हूं कि कक्षाओं से वर्ग व्यवहार को अलग करने के लिए हमें किन परिस्थितियों की आवश्यकता है।

उदा।

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

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

पुनश्च: इस बारे में जानकारी के लिए कोई लिंक भी बहुत उपयोगी हो जाएगा :)

ठनक

Answer 1

सबसे आसान चीज़ संभव है। आप हमेशा अपना कोड अधिक सामान्यीकृत कर सकते हैं और एक अच्छा मौका है कि आपको इसे भी नहीं करना पड़ेगा।

YAGNI सिद्धांत हर बार जब आप एक निर्णय करने की जरूरत को लागू करें। Extreme Programming wiki भी एक अच्छी पढ़ाई है।

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

फ़ाइल से पढ़ना, उदाहरण के लिए, लग रहा है एक स्पष्ट उम्मीदवार एक अलग लोडर वर्ग के लिए निकालने के लिए की तरह। दूसरी तरफ यदि आपके पास एक्सएमएल या जेएसओएन जैसे इनपुट के रूप में एक बहुत ही सामान्य प्रारूप है तो आप केवल स्थिर विधि List<Employee> Employee.loadFromFile(string fileName) बना सकते हैं और कोड की कुछ पंक्तियों में रीडिंग तर्क लागू कर सकते हैं। यह अभी काफी अच्छा है: सरल, छोटा और ठीक काम करता है।

Real Ultimate Programming Power आप के साथ हो सकता है!

Answer 2

अच्छा वस्तु उन्मुख डिजाइन अधिवक्ताओं कि प्रत्येक वर्ग Single Responsibility Principle का पालन करना।

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

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

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

Answer 3

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

डेटा और व्यापार तर्क को एक साथ रखकर, यह एक डोमेन ऑब्जेक्ट बन जाता है। जेएसएफ 2 में प्रचारित प्रबंधित बीन उपयोग का सबसे सरल रूप डोमेन मॉडल का उपयोग करता है जिससे "कार्रवाई" फ़ॉर्म डेटा के साथ मिलकर जुड़ा हुआ है।

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

Answer 4

आप DTO (जैसे संक्षिप्त नाम सुझाते हैं) का उपयोग करते हैं, जब आप सबसे हल्के वजन के तरीके के माध्यम से डेटा को स्थानांतरित करना चाहते हैं, जैसे तार से सेवा के लिए।

Answer 5

रिकॉर्ड

इसके लिए

क्लासिक अमीर डोमेन वस्तु बनाम कमजोर डोमेन वस्तु।

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

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

रिच बो -------> बी एस ----------> खून की कमी बो।