बदलते परिवेश में Enums का उपयोग करने के बारे में कुछ शब्द

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

जावा में Enums का विवरण

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

• कंपाइलर सही प्रकार की जाँच की गारंटी देता है
• सभी संभव गणना मूल्यों पर पुनरावृति की सुविधा
• वे स्विच ब्लॉक में कम जगह लेते हैं (कोई वर्ग नाम आवश्यक नहीं)
• आदि

हालांकि, के साथ तुलना में, कहते हैं, सी ++, जावा में enums पूर्ण ऑब्जेक्ट हैं, जो डेवलपर को बहुत अधिक लचीलापन देता है।

• सबसे पहले, सभी गणना java.lang.Enum वर्ग से विरासत में मिली हैं, जिसमें कई सुविधाजनक तरीके हैं, अर्थात्:
  
  नाम () - एक स्ट्रिंग के रूप में स्थिरांक का नाम
  
  - क्रमिक () - स्थिरांक का क्रम (उस क्रम से मेल खाता है जिसमें स्थिरांक घोषित होते हैं)
  
  - valueOf () - एक स्टैटिक तरीका जो आपको क्लास और नाम से एन्यूमरेशन ऑब्जेक्ट प्राप्त करने की अनुमति देता है
  
  
• इसके अलावा, जैसा कि पहले ही घोषित किया जा चुका है, एन्यूमरेशन क्लास के पास java.lang.Class.getEnumConstants () एन्यूमरेशन क्लास की विधि कहकर सभी संभव गणना मूल्यों को प्राप्त करने का अवसर है।
  
  
• एन्यूमरेशन क्लास में, कंस्ट्रक्टर (केवल निजी), फ़ील्ड्स और तरीकों को निर्दिष्ट करना संभव है
  
  
• गणना किसी भी इंटरफ़ेस को लागू कर सकती है
  
  
• इसके अलावा, गणना में विधियां अमूर्त हो सकती हैं, और स्थिरांक के विशिष्ट उदाहरण इस तरह के तरीकों को निर्धारित कर सकते हैं (जैसे, वैसे, और पहले से परिभाषित लोगों को फिर से परिभाषित करें)
  
  

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

सादगी शक्ति है!

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



इसका उद्देश्य मुश्किल विस्तार उन्मुख स्थितियों में जीवन को सरल बनाना है, जैसे:

• एक ही गणना वर्ग का उपयोग करते हुए कई शिथिल युग्मित मॉड्यूल की उपस्थिति
• गणन स्थिरांक की संरचना को बदलने के लिए पूर्ववर्ती का उपयोग
• इस गणना का उपयोग करके स्विच ब्लॉकों में कोड दोहराव का अस्तित्व

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

बदलते परिवेश में गणना का उपयोग करना

अब, वास्तव में, उस मुद्दे के सार पर आगे बढ़ते हैं, जिस पर मैं विचार करना चाहता था।



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



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



इस मामले में, आप निम्न कार्य कर सकते हैं:

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

इस प्रकार, एक दृष्टिकोण प्राप्त किया जाता है जो निम्नलिखित प्लसस और minuses द्वारा विशेषता है:

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

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

उदाहरण का उपयोग करें

उदाहरण के लिए, हमारे पास कक्षाओं का निम्नलिखित सेट है (विभिन्न मॉड्यूल में):

 पब्लिक एनुम डॉक्यूमेंटस्टैटस {
	 नया (0),
	 DRAFT (1),
	 प्रकाशित (2),
	 ARCHIVED (3);

	 निजी डॉक्यूमेंटस्टैटस (int statusCode) {
		 this.statusCode = statusCode;
	 }

	 सार्वजनिक int getStatusCode () {
		 स्टेटसकोड वापस करें;
	 }

	 निजी इंट स्टेटसकोड;
 }

 // वेब
 पब्लिक क्लास डॉक्यूमेंटवर्क्सफ्लोरोप्रोसेसर {
	 ...

	 सार्वजनिक सूची <ऑपरेशन> getAvailableOperations (DocumentStatus स्थिति) {
		 सूची <ऑपरेशन> संचालन;

		 स्विच (स्थिति) {
		 मामला नया:
			 संचालन = ...;
			 तोड़;
		 मामला DRAFT:
			 संचालन = ...;
			 तोड़;
		 मामला प्रकाशित:
			 संचालन = ...;
			 तोड़;
		 मामला ARCHIVED:
			 संचालन = ...;
			 तोड़;
		 }

		 वापसी के संचालन;
	 }

	 सार्वजनिक शून्य doOperation (DocumentStatus स्थिति, ऑपरेशन सेशन) APIException को फेंकता है {
		 स्विच (स्थिति) {
		 मामला नया:
			 // ऑपरेशन मापदंडों का एक सेट
			 तोड़;
		 मामला DRAFT:
			 // ऑपरेशन मापदंडों का एक और सेट
			 तोड़;
		 मामला प्रकाशित:
			 // ऑपरेशन मापदंडों का तीसरा सेट
			 तोड़;
		 मामला ARCHIVED:
			 // आदि।
			 तोड़;
		 }
	 }
 }


 // अनुसूचित कार्य
 पब्लिक क्लास ReportGenerationProcessor {
	 ...

	 सार्वजनिक शून्य जेनरेटपोर्ट (रिपोर्ट रिपोर्ट) {
		 DocumentStatus स्थिति = report.getDocument ()। GetStatus ();
		 रिपोर्टपार्म्स परमेस;

		 स्विच (स्थिति) {
		 मामला नया:
		 मामला DRAFT:
			 // params = रिपोर्ट में प्रदर्शित तत्वों के लिए कुछ चयन मानदंड
			 तोड़;
		 मामला प्रकाशित:
			 // params = रिपोर्ट में प्रदर्शित तत्वों के लिए अन्य चयन मानदंड
			 तोड़;
		 मामला ARCHIVED:
			 // आदि।
			 तोड़;
		 }

		 // रिपोर्ट जनरेशन
	 }
 }

यह देखा जा सकता है कि मॉड्यूल कमजोर रूप से परस्पर जुड़े हुए हैं।

मान लीजिए, ग्राहक के अनुरोध पर, हमारे पास एक नई दस्तावेज़ स्थिति है - पुष्टि (VERIFY) के लिए भेजा गया।

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

इस कोड को निम्न रूप में परिवर्तित करने का प्रस्ताव है:

 सार्वजनिक इंटरफ़ेस IReportGeneratorProcessor {
	 सार्वजनिक रिपोर्टपार्म्स getReportParams ();
 }

 सार्वजनिक इंटरफ़ेस IDocumentWorklfowProcessor {
	 सार्वजनिक सूची <ऑपरेशन> getAvailableOperations ();

	 सार्वजनिक शून्य doOperation (ऑपरेशन ऑप) APIException फेंकता है;
 }

 पब्लिक एनुम डॉक्यूमेंटस्टैटस {
	 // यहां, नए के बजाय, आप कारखाने या यहां तक ​​कि आलसी आरंभिक तरीकों का उपयोग कर सकते हैं
	 नया (0, नया NewDocReportGeneratorProcessor (), नया NewDocWorklfowProcessor ()),
	 DRAFT (1, नया DraftDocReportGeneratorProcessor (), नया DraftDocWorklfowProcessor ())
	 प्रकाशित (2, ...),
	 ARCHIVED (3, ...);

	 निजी डॉक्यूमेंटस्टैटस (int statusCode, IReportGeneratorProcessor रिपोर्टप्रकाश,
			 IDocumentWorklfowProcessor docProc) {
		 this.statusCode = statusCode;
		 this.reportProc = reportProc;
		 this.docProc = docProc;
	 }

	 सार्वजनिक int getStatusCode () {
		 स्टेटसकोड वापस करें;
	 }

	 सार्वजनिक IReportGeneratorProcessor getReportGeneratorProcessor () {
		 वापसी रिपोर्टप्रकाश;
	 }

	 सार्वजनिक IDocumentWorklfowProcessor getDocumentWorklfowProcessor () {
		 वापसी docProc;
	 }

	 निजी इंट स्टेटसकोड;
	 निजी IReportGeneratorProcessor रिपोर्टप्रकाश;
	 निजी IDocumentWorklfowProcessor docProc;
 }

 // वेब
 पब्लिक क्लास डॉक्यूमेंटवर्क्सफ्लोरोप्रोसेसर {
	 ...

	 सार्वजनिक सूची <ऑपरेशन> getAvailableOperations (DocumentStatus स्थिति) {
		 वापसी की स्थिति। विजेटडाक्यूमरवॉक शेल्फप्रोसेसर ()। getAvailableOperations ();
	 }

	 सार्वजनिक शून्य doOperation (DocumentStatus स्थिति, ऑपरेशन सेशन) APIException को फेंकता है {
		 status.getDocumentWorklfowProcessor ()। doOperation (op);
	 }
 }


 // अनुसूचित कार्य
 पब्लिक क्लास ReportGenerationProcessor {
	 ...

	 सार्वजनिक शून्य जेनरेटपोर्ट (रिपोर्ट रिपोर्ट) {
		 DocumentStatus स्थिति = report.getDocument ()। GetStatus ();
		 ReportParams params = status.getReportGeneratorProcessor ()। GetReportParams ();

		 // रिपोर्ट जनरेशन
	 }
 }

यह देखा जा सकता है कि ग्राहक कोड बहुत कम और अधिक समझने योग्य हो गया है।

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

	 सार्वजनिक IDocumentWorklfowProcessor getDocumentWorklfowProcessor () {
		 वापसी (docProc! = null)  docProc: DEFAULT_WORKFLOW_PROCESSOR;
	 }

पीएस मैं इस दृष्टिकोण की वैधता पर टिप्पणियों के लिए हब्रोसैक्विटी से प्रतीक्षा करता हूं। यदि आपको पर्याप्त वोट मिलते हैं, तो मैं IntelliJ IDEA, Eclipse और NetBeans के लिए इस प्लगइन को लागू करने के लिए तैयार हूं।



युपीडी। खंड "सरलता शक्ति है!" इस दृष्टिकोण के ढांचे के भीतर अपनी जगह दिखाने के लिए संबंधित पोस्ट के जवाब में जोड़ा गया था।



UPD 2. लोकप्रिय मांग से, उन्होंने एक उदाहरण जोड़ा। पोस्ट की शुरुआत में मैंने इस समाधान की प्रयोज्यता का एक संक्षिप्त विवरण भी जोड़ा।