संचालन के अनुक्रम के लिए सर्वश्रेष्ठ ओओपी डिज़ाइन पैटर्न

Question

मैं एक एप्लिकेशन पर काम कर रहा हूं, जिसका एक मॉड्यूल निम्नलिखित वित्तीय संचालन क्रमिक रूप से करता है:

जब उपयोगकर्ता एक निश्चित राशि के लिए अपने बैंक खाते में स्थानांतरित करने का अनुरोध करता है:

1. जांचें कि क्या अब कोई लेनदेन हो सकता है? (लेन-देन केवल एक निश्चित समय अवधि के दौरान किया जा सकता है)
2. जांचें कि क्या उपयोगकर्ता ने एक न्यूनतम राशि वापस लेने का अनुरोध किया है
3. जांचें कि उपयोगकर्ता के पास कोई डिफ़ॉल्ट खाता है या नहीं

उपरोक्त सभी कार्यों का परिणाम लॉग होना चाहिए।

यदि उपरोक्त सभी स्थिति संतुष्ट हो जाती है, तो लेनदेन किया जाता है। भविष्य में, कुछ अतिरिक्त जाँचें हो सकती हैं।

उपरोक्त मामले के लिए कौन सी वस्तु उन्मुख डिजाइन पैटर्न सबसे उपयुक्त होना चाहिए?

Comments

किसी समस्या को हल करने के लिए डिज़ाइन पैटर्न की तलाश कभी न करें। सही समाधान संवाद करने के लिए डिज़ाइन पैटर्न का उपयोग करें। programmers.stackexchange.com/questions/70877/… SOLID सिद्धांतों का पालन करें और आप बहुत गलत नहीं होंगे।

— पीडीआर

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

— जॉनी डीई

यहां एक अच्छा लक्षण वर्णन है कि एक पैटर्न क्या है: "वे [पैटर्न] काम करने के लिए ठोस, और अनुकूलनीय समाधान प्रदान करते हैं, जो सॉफ्टवेयर विकास के दौरान कुछ स्थितियों में, संगठनात्मक से प्रोग्रामिंग संदर्भों तक बार-बार उत्पन्न होते हैं।" [पोस 5, पी। 30] इसलिए इस दृष्टिकोण से, यह पूरी तरह से स्पष्ट है कि एक अनुकूलनीय समाधान के रूप में एक पैटर्न की तलाश एक उदार दृष्टिकोण है।

— जॉनी डीई

क्या आप सादे पुरानी प्रक्रियात्मक प्रोग्रामिंग का वर्णन करने के लिए एक वस्तु उन्मुख निर्माण के लिए पूछ रहे हैं?

— मौविसील

KISS सिद्धांत का पालन करें। अब तक आपकी समस्या का समाधान "3" के साथ किया जा सकता है। केवल शांत होने के लिए एक डिज़ाइन पैटर्न का उपयोग करने की कोशिश न करें। हर बार जब आप एक अतिरिक्त कक्षा लिखते हैं, तो हमेशा सोचें: क्या मुझे वास्तव में इसकी आवश्यकता है?

— इवर

Answer 1

ऐसा लगता है कि आप जो देख रहे हैं, वह एक जिम्मेदारी की श्रृंखला है । इस मामले में आपके पास निम्न वर्ग हो सकते हैं:

• TransactionValidatorBase सार आधार वर्ग
• TransactionTimeValidator
• TransactionAmountValidator
• TransactionAccountValidator

हालांकि आपके द्वारा निर्दिष्ट कई नियमों को लागू करने के लिए एक साथ जंजीर है।

फुटर रीडिंग

• OODesign.com पर CoR
• JavaWorld पर सीओआर के बाद

Comments

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

— एमी ब्लेंकशिप

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

— एंडीज स्मिथ

Answer 2

यदि आपके कदमों का अनुक्रम ज्यादातर सत्यापन कर्तव्यों को पूरा कर रहा है (जैसा कि यह आपको दिखता है), इनपुट को म्यूट किए बिना, मुझे लगता है कि वास्तव में "चेन ऑफ रिस्पॉन्सिबिलिटी" पैटर्न होगा, जैसा कि @pswg द्वारा उनके जवाब में बताया गया है

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

यहां इसके बारे में दो लेख दिए गए हैं: पैटर्न के बारे में अधिक सैद्धांतिक चर्चा
मार्टिन फॉलर द्वारा पाइपलाइन संग्रह

Answer 3

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

• रन-टाइम पर (1,2,3) चेकों के विभिन्न संयोजनों को बनाना आवश्यक है?
• क्या उन्हें अपने कार्यों को करने के लिए समान चर की आवश्यकता है या वे बहुत अलग हैं?
• त्रुटि संदेश कितना सटीक होना चाहिए?
• विफलता के मामले में उपयोगकर्ता (1) सेंट कदम से हमेशा पीछे हटते हैं?
• कैसे संभाला है?
• क्या प्रत्येक विधि अनुरोध में कुछ जोड़ती है या केवल मान्य करती है? (डिफ़ॉल्ट ऐक्ट आईडी कहिए?)

एक आंत भावना के आधार पर मैं उन्हें त्रुटि कोड के लिए पैरामीटर के साथ एक सादे तरीकों के रूप में कोडित करूंगा।

public void DoTransaction(IErrorAgregator error, TransactionRequest request)
{
    if(!IsTransactionInCertainTimePeriod(request, error)) return;
    if(!IsTransactionAmountInUserBounds(request, error)) return;
    if(!UserHaveDefaultAccount(request, error)) return;
    bankingTransactor.PerformTransaction(request);
}

यह "ITransactionValidationStragegy" इंटरफ़ेस में DoTransaction डालने और एक परत सुपर-प्रकार बनाने के लिए एक अच्छा विचार हो सकता है जिसमें सत्यापन बॉयलरप्लेट कोड होगा।

हालाँकि, इस डिज़ाइन में मैं मान रहा हूँ कि सत्यापन तर्क संकलन समय पर निर्धारित किया गया है।

Answer 4

जबकि पैटर्न पहले से ही यहां बताए गए हैं, मैं आपको यह सोचने के लिए सुझाव दूंगा कि आप अपने आवेदन में उसी का उपयोग कैसे करना चाहेंगे, जो आपके द्वारा उपयोग किए जा रहे फ्रेमवर्क के आधार पर हो।

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

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

Answer 5

मेरी समझ के अनुसार जो कुछ भी आवश्यक है उसे नीचे दिए गए कमांड पैटर्न में फिट किया जा सकता है। वर्ग डिजाइन नीचे के अनुसार किया जा सकता है।

interface Transaction{
void performAction();
}

class Banking{

void moneyValidation(){
//Validate Here
}

void timeValidation(){
//validate Here
}
}

class TimeValidation implements Transaction{

public Banking bank;

public TimeValidation (Banking bnk){
bank=bnk;
}

void performAction(){
bnk.timeValidation();
}


class MoneyValidation Implements Transaction{

public Banking bank;

public MoneyValidation(Banking bnk;){
bank=bnk;
}

void performAction(){
bnk.moneyValidation();
}
}


class Control{

private List val_list=new ArrayList();

void storeValidation(Transaction trans){
val_list.add(trans);
trans.performAction(val_list.getFirstAndRemove());
}
}

//Same for other validation classes

आपके ग्राहक वर्ग में निम्नलिखित कोड स्निपेट होंगे:

Banking bnk = new Banking();
MoneyValidation m_val = new MoneyValidation (bnk);
TimeValidation t_val = new TimeValidation (bnk);
Control ctrl = new Control();
ctrl.storeValidation(m_val);
ctrl.storeValidation(t_val);

यह मेरी समझ के अनुसार है, ऊपर दिए गए परिदृश्य के साथ।

Comments

यह बुरा है क्योंकि जब धन सत्यापन विफल हो जाता है, तो समय व्यर्थ हो जाता है, लेकिन इसे वैसे भी किया जाएगा

— Ewoks