क्या कोई डिज़ाइन पैटर्न है जो डिस्काउंट मॉडल पर लागू होगा?

Question

क्या डिस्काउंट मॉडल लागू करने के लिए कोई ज्ञात डिज़ाइन पैटर्न हैं?

डिस्काउंट मॉडल से मेरा मतलब निम्नलिखित है:

1. यदि कोई ग्राहक उत्पाद X, उत्पाद Y और उत्पाद Z खरीदता है तो उसे 10% या $ 100 की छूट मिलती है।

2. यदि कोई ग्राहक उत्पाद X की 100 यूनिट खरीदता है, तो उसे 15% या $ 500 की छूट मिलती है

3. यदि कोई ग्राहक पिछले वर्ष में $ 100K से अधिक लाया है, तो उसे फ्लैट 20% की छूट मिलती है

4. यदि किसी ग्राहक ने उत्पाद X की 2 इकाइयाँ खरीदी हैं, तो उसे उत्पाद X (या उत्पाद Y) की 1 इकाई मुफ्त मिलती है।

5. ...

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

Comments

IIRC मैंने उन सभी ट्यूटोरियल्स को देखा है, जिनमें छूट से संबंधित उदाहरण हैं (कई हैं) रणनीति पैटर्न का सुझाव देते हैं

— gnat

@Kanini क्या यह वास्तविक दुनिया की समस्या है? ऐसे मामले में यह प्रणाली वास्तविक समय में है या स्थगित-समय है? क्या ये नियम नियम-इंजन या डेटाबेस मान के रूप में प्रस्तुत किए गए हैं? क्या प्राथमिकता के आधार पर छूट श्रेणीबद्ध की खोज है? अधिकांश मामलों में रणनीति पैटर्न काम करेगा लेकिन इसे बनाने के लिए आपके नियमों को

— स्पष्ट

इसके अलावा यदि कोई व्यक्ति उत्पाद X, एक उत्पाद Y, और एक उत्पाद Z की 2 इकाइयाँ खरीदता है, तो क्या उसे 10% और अतिरिक्त उत्पाद X दोनों मिलेंगे?

— उबरमेन्श

@ कुछ ट्यूटोरियल के कुछ लिंक पर क्लिक करें।

— user16764

Answer 1

यदि समस्या यह है कि आपको कई छूटों को लागू करने की जरूरत है, तो दी गई परिस्थितियों में, आप चेन ऑफ रिस्पॉन्सिबिलिटी पैटर्न पर विचार कर सकते हैं ।

संक्षेप में, आप उस जानकारी को पास करते हैं जिसे आप पहले प्रोसेसर में संसाधित करना चाहते हैं, और यह वहां से तय करता है कि परिणाम वापस करने से पहले इसे आगे के प्रोसेसर पर पारित किया जाए या नहीं।

इस तरह से आप कभी भी कॉलिंग कोड को बदले बिना प्रोसेसर की संरचना और अनुक्रम को बदल सकते हैं।

Comments

जिम्मेदारी की श्रृंखला एक और अच्छा है। एक रणनीति के साथ भी युग्मित किया जा सकता है। ऐसे मामले में जहां केवल एक छूट लागू की जा सकती है, प्रत्येक रणनीति दूसरे के साथ जंजीर होती है। प्रत्येक श्रृंखला अपनी छूट की गणना करती है (यदि ग्राहक पात्र है), इसकी तुलना पिछले छूट से करता है, और ग्राहक, आदेश, और छूट डेटा को अगली श्रृंखला में भेजता है। +1।

— थॉमस ओवेन्स

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

— डॉक्टर ब्राउन

Answer 2

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

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

Comments

यह वास्तव में नहीं है कि राज्य पैटर्न क्या करने का इरादा है, यह है?

— पीडीआर

@pdr मैं यह नहीं देखता कि क्यों नहीं। लेकिन यह आपके कार्यान्वयन पर निर्भर करता है। यदि आपका ग्राहक ऑब्जेक्ट ग्राहक-निर्भर छूट को ट्रैक करता है, तो ग्राहक को छूट के लिए पात्रता वापस करने के लिए एक ऑपरेशन हो सकता है। जैसा कि ग्राहक चीजों को खरीदता है, विशेषताएँ बदल जाती हैं और इस पद्धति का कार्यान्वयन राज्य पैटर्न के माध्यम से बदल जाता है।

— थॉमस ओवेन्स

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

— पीडीआर

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

— jfrankcarr

@jfrankcarr मेरे दिमाग में, यह नहीं होगा। मैं उन आइटमों के सेट के लिए मानों को पॉप्युलेट करता हूँ, जिनसे छूट मिलती है, प्रतिशत बंद हो जाते हैं, और आगे किसी प्रकार के कॉन्फ़िगरेशन से। मेरे राज्य मशीन के संक्रमण और मेरे सज्जाकारों और रणनीतियों की विशेषताओं का गतिशील रूप से निर्माण।

— थॉमस ओवेन्स

Answer 3

खैर, मैं एक जोड़ी मॉडल को "प्रीकंडिशन" और "डिस्काउंट" के रूप में डिजाइन करूंगा, जहां "प्रीकंडिशन" विधियों के साथ एक वर्ग है

  bool IsFulfilled(Customer c);

या और

  bool IsFulfilled(Customer c, Order o);

और डिस्काउंट की एक विधि है void ApplyTo(Customer c)। यह आपको किसी भी प्रकार की छूट के साथ किसी भी प्रकार के पूर्व शर्त को संयोजित करने की क्षमता देता है (मुझे लगता है कि यह "पुल पैटर्न" का एक रूप है)।

यदि आपके पास निश्चित संख्या में पूर्व शर्त हैं, तो आप विशिष्ट उपप्रकार (रणनीति पैटर्न) का निर्माण करके समस्या को हल कर सकते हैं। हालाँकि, जब आपके पूर्व शर्त को बहुत जटिल होने की अनुमति दी जाती है, तो AND, OR और NOT जैसे तार्किक कथनों के साथ, आप शर्तों के लिए कुछ प्रकार के नियम दुभाषिया को बेहतर तरीके से लागू कर सकते हैं। नियम एक सरल "डोमेन विशिष्ट भाषा" में लिखा एक सादा पाठ स्ट्रिंग हो सकता है।

वही "डिस्काउंट" वर्ग के लिए जाता है, आप या तो विभिन्न प्रकार के छूटों के लिए कुछ उपप्रकार ले सकते हैं, या सामान्य दृष्टिकोण जहां छूट नियमों को पाठ रूप में दिया जाता है, कुछ दुभाषिया द्वारा विकसित किया जाता है।

Comments

मेरे अंतर्ज्ञान से यह पता चलता है कि वह सवाल के संदर्भ में क्या देख रहा है

— उबेरमेंस

Answer 4

• शायद एक IDiscount इंटरफ़ेस की ज़रूरत है क्योंकि सभी अलग-अलग छूट एक ही चीज़ हैं, और हम उनके साथ सामान्य रूप से सामान्य छूट के रूप में व्यवहार करना चाहेंगे।

• "इस ग्राहक के आदेश" वर्ग को शायद छूट के संग्रह की आवश्यकता है। सूची? हैश? लिंक्ड सूची? परवाह नहीं, फिर भी। छूट खरीद पर लागू होती है, ग्राहक पर नहीं!

• ग्राहक, शॉपिंग कार्ट, इतिहास इत्यादि से अलग-अलग डिस्काउंट का उदाहरण रखें। यह बहुत कुछ बदल जाएगा - जैसा कि @jfrankcarr ने बताया है।

• संभवतः प्रत्येक छूट के लिए एक अलग वर्ग एल्गोरिथम और प्रत्येक छूट के लिए पैरामीटर बेतहाशा और अप्रत्याशित रूप से भिन्न होते हैं।

• मैं बहुत सारे इवेंट हैंडलिंग को खरीदारी कार्ट में परिवर्तन के जवाब की गणना के रूप में देखता हूं, और इसके विपरीत।

डिजाइन पैटर्न आवेदन

• मैं देखता हूं ए strategy pattern। IDiscount विभिन्न डिस्काउंट एल्गोरिदम को लागू करने के लिए इंटरफ़ेस है।

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

• मैं देख सकता हूं Chain of Responsibility। यह पारस्परिक रूप से factoryविचार के लिए अनन्य नहीं है। छूट संग्रह को पुनरावृत्त करने के बजाय, प्रत्येक छूट अगले आदमी को बुलाती है। "ग्राहक का आदेश" वर्ग इस मामले में छूट का संग्रह नहीं रखता है।

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

मान्यताओं

• छूट वर्तमान शॉपिंग कार्ट और / या खरीद इतिहास पर आधारित है
• शून्य या अधिक छूट लागू हो सकती है। कोई विशेष रूप से अनन्य छूट नहीं है
• उचित गणना उस आदेश पर निर्भर नहीं है जिसमें छूट लागू की जाती है।

क्या बदलता है, क्या वही रहता है?

• छूट बहुत अलग है। प्रत्येक नियम बनाने के लिए अलग-अलग संख्या और तरह के पैरामीटर।

• क्वालीफाइंग छूट के लिए तर्क शॉपिंग कार्ट में बदलाव के रूप में बदलते हैं।

• उपलब्ध छूट की संख्या में परिवर्तन होता है

• यह छूट ग्राहक को खरीदारी की कार्ट में बदलाव के रूप में बदलाव के लिए योग्य बनाती है।

• खरीदारी का इतिहास इस खरीद के संदर्भ में नहीं बदलता है

• कुल लागत गतिशील रूप से खरीद लाइनों और छूट लागू के एक समारोह के रूप में बदल जाती है।

• प्रारंभिक आवेदन के बाद छूट का आउटपुट बदल सकता है, उदाहरण के लिए खरीद मात्रा में परिवर्तन।

Comments

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

— le0diaz

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

— राडार

Answer 5

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

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

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

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

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

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

Answer 6

क्या कोई बिंदु है जो पूछ रहा है कि क्या इसके लिए एक उपयोगी पैटर्न है? किस प्रकार के पैटर्न की आवश्यकता है - संरचनात्मक या व्यवहारिक?

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

cart.calculateDiscount(productVector);

आपको इससे ज्यादा कुछ नहीं चाहिए!

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

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

पुनश्च: इसके बारे में सोचें - जब फ़ायरवॉल पैकेटों को संसाधित करता है और पास करता है या पैकेट को अस्वीकार करता है (या इसे संशोधित करता है) - डिजाइन पैटर्न क्या उपयोग करता है? उत्तर उपरोक्त वर्णित किसी का नहीं है!

Comments

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

— le0diaz