😎 🍾 🥈 पेश है ग्रीन-फॉरेस्ट फ्रेमवर्क 👩🏽‍🤝‍👩🏻 🥅 🗼

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

कट के तहत हम सीखे गए एप्लिकेशन कोड को सरल बनाने के लिए इसका उपयोग कैसे करें।

सबसे पहले, इस समस्या पर विचार करें कि ग्रीन-फॉरेस्ट को हल करने का इरादा है।

समस्या

बहुत बार, एक बड़ी परियोजना की वास्तुकला इस प्रकार है:

प्रस्तुति परत
व्यवसाय की परत
डेटा लेयर

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

public interface UserService { User createUser(Object someData); void activateUser(long id); User updateUser(User updatedUser); void blockUser(long id); void unblockUser(long id); }

जैसे-जैसे एप्लिकेशन बढ़ता है, समान सेवाओं में विधियों की संख्या बढ़ती है, जिसका अर्थ है कि कार्यान्वयन वर्ग का थोक बढ़ता है:

 public class UserServiceImpl implements UserService { //  1-   public User createUser(Object someData) { //  10-15  } // 16-   public void activateUser(long id) { //  10-15  } // .. //  1000-   public void unblockUser(long id) { //  10-15  } }

नतीजतन, कक्षाएं दिखाई देती हैं जिनमें दर्जनों विधियां और कोड की 1000 लाइनें शामिल हैं। ऐसी कक्षाओं में कोड ढूंढना और उन्हें बनाए रखना कठिन और मुश्किल हो जाता है।

क्लासिक समाधान

स्पष्ट समाधान एक बड़ी सेवा को कई छोटे लोगों में विभाजित करना है:

 public interface UserBasicService { User createUser(Object someData); void activateUser(long id); User updateUser(User updatedUser); } public interface UserModerationService { void blockUser(long id); void unblockUser(long id); }

हालांकि, सादगी के अलावा, इस दृष्टिकोण के कई नुकसान हैं:

वर्दी जुदाई की कठिनाई : सेवा को समान भागों में विभाजित करना मुश्किल है। एक नई सेवा में 3 विधियाँ शेष हैं, 10 अन्य में।

पृथक्करण की अस्पष्टता : किसी विशेष पद्धति को स्थानांतरित करने के लिए कौन सी सहायक सेवा निर्धारित करना कठिन हो सकता है। नतीजतन, तरीके तार्किक नहीं हैं और एपीआई को समझना अधिक कठिन है।

लक्षणों का उन्मूलन, लेकिन कारण नहीं: वास्तव में, हमने समस्या का समाधान नहीं किया, क्योंकि नई सेवाओं में तरीकों के विकास के साथ, वे भारी-रेखा के 1000-लाइन कार्यान्वयन के जोखिम को भी चलाते हैं।

आइए एक नए तरीके से बोझिल सेवा की समस्या को हल करने का प्रयास करें।

परमाणु कार्यों के माध्यम से समाधान

चूँकि हमारी सेवा के कई समानों में सरल विभाजन समस्या का पूर्ण समाधान प्रदान नहीं करता है, हम खुद से पूछेंगे कि क्या हम इसे और अधिक परमाणु संस्थाओं में विभाजित कर सकते हैं? बेशक हम कर सकते हैं! आखिरकार, किसी भी सेवा का लक्ष्य इसकी विधियां हैं, जिसका अर्थ है कि कई अलग-अलग तरीकों को बनाने से, हमें ऊपर की कमियों से छुटकारा मिलेगा:

असमान और अस्पष्ट अलगाव की कोई समस्या नहीं है : कई तरीकों को समान रूप से और विशिष्ट रूप से परिभाषा से विभाजित किया जाता है।

विकास समस्या हल हो गई है: जब नए तरीके दिखाई देते हैं, तो हम बस पुराने के आकार को बढ़ाए बिना नई कक्षाएं बनाते हैं।

हरित-वन में समाधान का कार्यान्वयन

ग्रीन-फ़ॉरेस्ट फ़्रेमवर्क एक्शन-हैंडलर आर्किटेक्चर का उपयोग करता है, जो चित्र द्वारा चित्रित किया गया है:

इस सर्किट के घटकों पर विचार करें:

कार्य

एक्शन क्लास एक परमाणु "विधि" का प्रतिनिधित्व करता है जिसे "कहा जा सकता है"। वर्ग के अंदर इनपुट और आउटपुट डेटा होता है:
```
 // Action     - String   - Integer public class SomeAction extends Action<String, Integer>{ public SomeAction(String input) { super(input); } } 
```

हैंडलर

हैंडलर वर्ग में इस क्रिया प्रकार के लिए एक विशिष्ट कार्यान्वयन शामिल है:

 @Mapping(SomeAction.class) public class SomeHandler extends Handler<SomeAction>{ @Inject SomeService service; public void invoke(SomeAction action) throws Exception { String input = action.getInput(); Integer result = service.doSomeWork(input); action.setOutput(result); } }

ढांचा

इंजन फ्रेमवर्क ऑब्जेक्ट एक्शन और हैंडलर ऑब्जेक्ट्स के बीच एक लिंक प्रदान करता है:
```
 //  Engine Engine engine = new Engine(); //  engine.putHandler(SomeHandler.class); //  Integer result = engine.invoke(new SomeAction("some data")); 
```

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

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

सबसे पहले, हम ActionService सेवा इंटरफ़ेस से UserService वारिस करेंगे:

 import com.gf.service.ActionService; public interface UserService extends ActionService { //    -    ActionService }

आगे, हम कई एक्शन क्लास बनाएंगे:

 import com.gf.Action; public class CreateUser extends Action<Object, User> { public CreateUser(Object someData){ this(someData); } } public class ActivateUser extends Action<Long, Void> { public ActivateUser(Long id){ this(id); } } /*  .  : UpdateUser.java BlockUser.java UnblockUser.java ... */

यह इन वर्गों के लिए हैंडलर बनाने के लिए बना हुआ है। उदाहरण के लिए:

 @Mapping(CreateUser.class) public class CreateUserHandler extends Handler<CreateUser>{ public void invoke(CreateUser action) throws Exception { Object input = action.getInput(); User user = ... action.setOutput(user); } }

UserServiceImpl के अंतिम प्रकार के कार्यान्वयन का एक उदाहरण:

 import com.gf.Action; import com.gf.core.Engine; public class UserServiceImpl implements UserService { Engine engine; public UserServiceImpl(){ engine = new Engine(); // Handler     engine.scanAndPut("some.package"); } public <I, O> O invoke(Action<I, O> action) { return engine.invoke(action); } public <I, O> O invokeUnwrap(Action<I, O> action) throws Exception { return engine.invokeUnwrap(action); } }

नतीजतन, हमने बड़े उपयोगकर्ता सेवा इंटरफ़ेस को कई एक्शन कक्षाओं में विभाजित किया, और उपयोगकर्ता हैंड सर्विस को कई हैंडलर कक्षाओं में लागू किया।

निष्कर्ष और संदर्भ

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

अपने काम का आनंद लें, सहकर्मियों!

संदर्भ:
हरित-वन की रूपरेखा
प्रलेखन

पेश है ग्रीन-फॉरेस्ट फ्रेमवर्क