मुझे जावा एप्लिकेशन कैसे बनाना चाहिए, मैं अपनी कक्षा कहां रखूं?

मुझे अपने वर्गों को संकुल में तोड़ना पसंद है जो एक-दूसरे से संबंधित हैं।

उदाहरण के लिए: डेटाबेस से संबंधित कॉल के लिए मॉडल

View Classes that deal with what you see

Control Core functionality classes

Util Any misc. classes that are used (typically static functions)

आदि।

कक्षा के नाम हमेशा वर्णनात्मक और आत्म-व्याख्यात्मक होना चाहिए। यदि आपके वर्गों के लिए ज़िम्मेदारी के कई डोमेन हैं तो उन्हें शायद दोबारा प्रतिक्रिया दी जानी चाहिए।

इसी तरह आप पैकेज के लिए। उन्हें जिम्मेदारी के डोमेन द्वारा समूहीकृत किया जाना चाहिए। प्रत्येक डोमेन में इसका अपना अपवाद होता है।

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

समूह से संबंधित कार्यक्षमता को एक साथ पैकेज का उपयोग करें।

आमतौर पर आपके पैकेज पेड़ का शीर्ष विशिष्टता की गारंटी के लिए आपके डोमेन नाम को उलट दिया जाता है ( com.domain.subdomain ), और फिर आमतौर पर आपके एप्लिकेशन के लिए एक पैकेज होगा। फिर संबंधित क्षेत्र से उप-विभाजित करें, इसलिए आपका FileStorageStrategy कह सकता है, com.domain.subdomain.myapp.storage , और फिर विशिष्ट कार्यान्वयन / उप-वर्ग / com.domain.subdomain.myapp.storage.file और com.domain.subdomain.myapp.storage.database में जो भी हो। ये नाम बहुत लंबा हो सकते हैं, लेकिन आयात उन्हें फ़ाइलों के शीर्ष पर रखता है और आईडीई भी इसे प्रबंधित करने में सहायता कर सकते हैं।

अपवाद आमतौर पर उसी पैकेज में जाते हैं जो उन्हें फेंकने वाले वर्गों के रूप में जाते हैं, इसलिए यदि आपने कहा था, FileStorageException यह उसी कोड में FileStorageStrategy के रूप में जाएगा। इसी प्रकार एक इंटरफ़ेस परिभाषित स्थिरांक एक ही पैकेज में होंगे।

वास्तव में ऐसा कोई मानक नहीं है, केवल सामान्य ज्ञान का उपयोग करें, और यदि यह सब बहुत गन्दा हो जाता है, तो रिफैक्टर!

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

मैं संगठित स्रोतों का एक बड़ा प्रशंसक हूं, इसलिए मैं हमेशा निम्नलिखित निर्देशिका संरचना बना देता हूं:

/src - for your packages & classes
/test - for unit tests
/docs - for documentation, generated and manually edited
/lib - 3rd party libraries
/etc - unrelated stuff
/bin (or /classes) - compiled classes, output of your compile
/dist - for distribution packages, hopefully auto generated by a build system

में / src मैं डिफ़ॉल्ट जावा पैटर्न का उपयोग कर रहा हूं: आपके डोमेन (org.yourdomain.yourprojectname) से शुरू होने वाले पैकेज नाम और कक्षा के साथ बनाए जा रहे ओओपी पहलू को प्रतिबिंबित करने वाले वर्ग नाम (अन्य टिप्पणीकार देखें)। सामान्य पैकेज नाम जैसे उपयोग , मॉडल , देखें , ईवेंट उपयोगी भी हैं।

मैं डोमेन कक्षाओं के उसी पैकेज में सत्र कॉन्स्टेंट या ServiceConstants जैसे किसी विशिष्ट विषय के लिए स्थिरांक डालता हूं।

एक चीज मैंने अतीत में की है - अगर मैं कक्षा का विस्तार कर रहा हूं तो मैं कोशिश करूंगा और उनके सम्मेलनों का पालन करूंगा। उदाहरण के लिए, स्प्रिंग फ्रेमवर्क के साथ काम करते समय, मेरे पास com.mydomain.myapp.web.servlet.mvc नामक पैकेज में मेरी एमवीसी कंट्रोलर कक्षाएं होंगी अगर मैं कुछ विस्तार नहीं कर रहा हूं तो मैं बस इतना आसान हूं। डोमेन ऑब्जेक्ट्स के लिए com.mydomain.domain (हालांकि यदि आपके पास डोमेन ऑब्जेक्ट्स का एक टन है तो यह पैकेज थोड़ा अनावश्यक हो सकता है)। डोमेन विशिष्ट स्थिरांक के लिए, मैं वास्तव में उन्हें सबसे संबंधित वर्ग में सार्वजनिक स्थिरांक के रूप में डालता हूं। उदाहरण के लिए, यदि मेरे पास "सदस्य" वर्ग है और अधिकतम सदस्य नाम लंबाई स्थिर है, तो मैंने इसे सदस्य वर्ग में रखा है। कुछ दुकानें अलग-अलग कॉन्स्टेंट कक्षा बनाती हैं लेकिन मुझे असंबद्ध संख्याओं और तारों को एक वर्ग में लंपने में मूल्य नहीं दिखता है। मैंने कुछ अन्य दुकानों को अलग-अलग कॉन्स्टेंट कक्षाओं को बनाकर इस समस्या को हल करने का प्रयास किया है, लेकिन यह समय की बर्बादी की तरह लगता है और नतीजा बहुत भ्रमित है। इस सेटअप का उपयोग करके, कई डेवलपर्स के साथ एक बड़ी परियोजना पूरी जगह पर स्थिरांक डुप्लिकेट कर रही है।

यूनिट परीक्षणों के लिए मुझे बहुत मदद मिली, एक myApp / src / और myApp / test_src / निर्देशिका भी थी। इस तरह, मैं एक ही पैकेज में यूनिट परीक्षणों को कक्षाओं के परीक्षण के रूप में रख सकता हूं, और फिर भी जब मैं अपनी उत्पादन स्थापना तैयार करता हूं तो परीक्षण परीक्षणों को आसानी से बाहर कर सकता हूं।

संक्षिप्त उत्तर: परतों में लंबवत कटा हुआ प्रत्येक मॉड्यूल के साथ मॉड्यूल के आधार पर अपने सिस्टम आर्किटेक्चर को खींचना, उदाहरण के लिए, मॉडल, दृढ़ता)। फिर com.mycompany.myapp.somemodule.somelayer जैसी संरचना का उपयोग करें, उदा। com.mycompany.myapp.client.view या com.mycompany.myapp.server.model ।

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

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

• com.mycompany.myapp.view
• com.mycompany.myapp.model
• com.mycompany.myapp.services
• com.mycompany.myapp.rules
• com.mycompany.myapp.persistence (or 'dao' for data access layer)
• com.mycompany.myapp.util (beware of this being used as if it were 'misc')

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

मैं वास्तव में मेवेन की मानक निर्देशिका लेआउट ।

मेरे लिए महत्वपूर्ण विचारों में से एक है दो स्रोत जड़ों - एक उत्पादन कोड के लिए और एक परीक्षण कोड के लिए:

MyProject/src/main/java/com/acme/Widget.java
MyProject/src/test/java/com/acme/WidgetTest.ava

(यहां, दोनों स्रोत / मुख्य / जावा और src / test / java स्रोत जड़ों हैं)।

लाभ:

• आपके परीक्षणों में परीक्षण के तहत आपके वर्गों के लिए पैकेज (या "डिफ़ॉल्ट") स्तर तक पहुंच है।
• स्रोत स्रोत के रूप में src / test / java को छोड़कर आप केवल अपने उत्पादन स्रोतों को JAR में आसानी से पैकेज कर सकते हैं।

कक्षा प्लेसमेंट और पैकेज के बारे में अंगूठे का एक नियम:

Generally speaking, well structured projects will be free of circular dependencies. Learn when they are bad (and when they are not), and consider a tool like JDepend or SonarJ that will help you eliminate them.

जहां मैं काम कर रहा हूं, हम मेवेन 2 का उपयोग कर रहे हैं और हमारे पास हमारी परियोजनाओं के लिए एक बहुत अच्छा आर्केटाइप है। लक्ष्य चिंताओं का एक अच्छा अलगाव प्राप्त करना था, इस प्रकार हमने कई मॉड्यूल (प्रत्येक एप्लिकेशन 'परत' के लिए एक) का उपयोग करके एक परियोजना संरचना को परिभाषित किया:   - आम: अन्य परतों द्वारा उपयोग किया जाने वाला सामान्य कोड (उदा।, i18n)   - संस्थाएं: डोमेन इकाइयां   - भंडार: इस मॉड्यूल में दास इंटरफेस और कार्यान्वयन शामिल हैं   - सेवाएं-intf: सेवाओं के लिए इंटरफेस (उदाहरण के लिए, उपयोगकर्ता सेवा, ...)   - सेवाएं-impl: सेवाओं के कार्यान्वयन (उदाहरण के लिए, UserServiceImpl)   - वेब: वेब सामग्री के बारे में सबकुछ (उदा।, सीएसएस, जेएसपीएस, जेएसएफ पेज, ...)   - डब्ल्यूएस: वेब सेवाएं

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

प्रत्येक मॉड्यूल का अपना मूल पैकेज होता है, उदाहरण के लिए यदि एप्लिकेशन पैकेज "com.foo.bar" है, तो हमारे पास है:

com.foo.bar.common
com.foo.bar.entities
com.foo.bar.repositories
com.foo.bar.services
com.foo.bar.services.impl
...

प्रत्येक मॉड्यूल मानक मैवेन परियोजना संरचना का सम्मान करता है:

   src\
   ..main\java
     ...\resources
   ..test\java
     ...\resources

किसी दिए गए परत के लिए यूनिट परीक्षण आसानी से \ src \ test के अंतर्गत अपना स्थान ढूंढते हैं ... डोमेन विशिष्टता वाली प्रत्येक चीज यह इकाई मॉड्यूल में है। अब FileStorageStrategy की तरह कुछ रिपोजिटरी मॉड्यूल में जाना चाहिए, क्योंकि हमें यह जानने की आवश्यकता नहीं है कि कार्यान्वयन क्या है। सेवा परत में, हम केवल भंडार इंटरफ़ेस को जानते हैं, हमें परवाह नहीं है कि विशिष्ट कार्यान्वयन क्या है (चिंताओं को अलग करना)।

इस दृष्टिकोण के कई फायदे हैं:

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

मुझे पता है कि यह आपके सभी सवालों का जवाब नहीं देता है, लेकिन मुझे लगता है कि यह आपको सही रास्ते पर डाल सकता है और दूसरों के लिए उपयोगी साबित हो सकता है।