सूचना फैलाने वाली वस्तु सीमाएँ

Question

कई बार मेरी व्यावसायिक वस्तुओं में ऐसी परिस्थितियाँ होती हैं, जहाँ जानकारी के लिए वस्तुगत सीमाओं को भी पार करना पड़ता है। OO करते समय, हम चाहते हैं कि जानकारी एक वस्तु में हो और जितना संभव हो उस जानकारी से निपटने वाले सभी कोड उस वस्तु में होने चाहिए। हालांकि, व्यावसायिक नियम मुझे परेशान करने वाले इस सिद्धांत का पालन नहीं करते हैं।

एक उदाहरण के रूप में मान लें कि हमारे पास एक ऑर्डर है जिसमें कई ऑर्डरइमेट्स हैं जो एक इन्वेंट्री इटेम को संदर्भित करता है जिसकी कीमत है। मैं Order.GetTotal () का आदेश देता हूं, जो OrderItem.GetPrice () का परिणाम बताता है, जो InventoryItem.GetPrice () द्वारा एक मात्रा को गुणा करता है। अब तक सब ठीक है।

लेकिन फिर हमें पता चलता है कि कुछ वस्तुओं को एक सौदे के लिए दो के साथ बेचा जाता है। हम इसे OrderItem.GetPrice () InventoryItem.GetPrice (मात्रा) की तरह कुछ कर सकते हैं और InventoryItem को इससे निपटने दे सकते हैं।

हालांकि, तब हमें पता चलता है कि दो-के लिए एक सौदा केवल एक विशेष समय अवधि के लिए रहता है। इस समय अवधि को आदेश की तारीख पर आधारित होना चाहिए। अब हम OrderItem.GetPrice () को InventoryItem.GetPrice (quatity, order.GetDate ()) में बदलते हैं।

लेकिन तब हमें अलग-अलग कीमतों का समर्थन करने की आवश्यकता होती है, जो इस बात पर निर्भर करता है कि ग्राहक कितने समय से सिस्टम में है: InventoryItem.GetPrice (मात्रा, order.GetDate (), order.GetCustomer ())

लेकिन फिर यह पता चला है कि दो-के-लिए एक सौदे में न केवल एक ही इन्वेंट्री आइटम के कई खरीदने के लिए लागू होता है, बल्कि एक इन्वेंटरीचोरीरी में किसी भी आइटम के लिए कई। इस बिंदु पर हम अपने हाथों को फेंक देते हैं और बस इन्वेंटरी इटेम को ऑर्डर आइटम देते हैं और इसे एक्सेसर्स के माध्यम से ऑब्जेक्ट रेफरेंस ग्राफ पर यात्रा करने की अनुमति देते हैं ताकि इसकी जरूरत की जानकारी मिल सके: InventoryItem.GetPrice (यह)

टीएल; डीआर मैं वस्तुओं में कम युग्मन रखना चाहता हूं, लेकिन व्यावसायिक नियम मुझे विशेष रूप से निर्णय लेने के लिए जगह-जगह से जानकारी प्राप्त करने के लिए मजबूर करते हैं।

क्या इससे निपटने की अच्छी तकनीकें हैं? क्या दूसरों को भी यही समस्या है?

Comments

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

— क्रिस

@ क्रिस, हाँ, मूल्य निर्धारण तर्क को विभाजित करना शायद एक अच्छा विचार है। मेरी समस्या यह है कि इस तरह के ऑब्जेक्ट को ऑर्डर संबंधित सभी वस्तुओं के साथ कसकर जोड़ा जाएगा। वह हिस्सा जो मुझे परेशान करता है और वह हिस्सा जिसे मैं सोच रहा हूं कि क्या मैं बच सकता हूं।

— विंस्टन इवर्ट

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

— क्रिस

Answer 1

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

क्या यह एक सही समाधान है, नहीं। हमारे पास अभी भी अन्य वर्गों के बारे में बहुत अधिक जानने का एक वर्ग है, लेकिन कम से कम हम उस चीज़ को स्थानांतरित कर चुके हैं जो व्यावसायिक वस्तुओं और व्यावसायिक तर्क वर्ग से बाहर है।

Comments

जब संदेह में एक और वर्ग जोड़ें।

— क्रिस

Answer 2

आप की तरह लगता है एक अलग डिस्काउंट वस्तु (या उनमें से एक सूची) है कि सभी सामान का ट्रैक रखता है की जरूरत है, और फिर कुछ की तरह है, आदेश के लिए छूट (रों) लागू Order.getTotal(Discount)या Discount.applyTo(Order)या इसी तरह की।

Comments

मैं देख सकता हूं कि कोड को डिस्काउंट में कहां रखा जाए, फिर इन्वेंटरी ऑब्जेक्ट में बेहतर होगा। लेकिन ऐसा लगता है कि डिस्काउंट ऑब्जेक्ट को अभी भी सभी विभिन्न वस्तुओं से जानकारी प्राप्त करनी होगी। ताकि, कम से कम जहाँ तक मैं देख पा रहा हूँ, समस्या का समाधान न हो।

— विंस्टन एवर्ट

मुझे लगता है कि डिस्काउंट ऑब्जेक्ट एक अच्छा विचार है, लेकिन मैं इसे एक पर्यवेक्षक पैटर्न ( en.wikipedia.org/wiki/Observer_pattern ) लागू करूंगा, पैटर्न के विषय (ओं) के रूप में छूट के साथ

— ब्लैकमेल

Answer 3

अन्य वर्गों से डेटा एक्सेस करना पूरी तरह से ठीक है। हालाँकि, आप चाहते हैं कि यह एक दिशात्मक संबंध हो। उदाहरण के लिए, मान लें कि ClassOrder CallItem को एक्सेस करता है। आदर्श रूप से, क्लास इटेम को क्लासऑर्डर तक नहीं पहुंचना चाहिए। मुझे लगता है कि आप अपने ऑर्डर क्लास में गायब हैं, कुछ प्रकार के व्यावसायिक तर्क हैं जो किसी वर्ग को वॉलेट जैसे सुझाए गए या नहीं कर सकते हैं।

संपादित करें: विंस्टन की टिप्पणी का जवाब

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

मैं एक आईडी द्वारा इन्वेंट्री आइटम का उल्लेख करूंगा। प्रत्येक आदेश में इन्वेंट्री आईडी और इसी मात्रा की एक सूची होगी।

तब मैं कुछ इस तरह से आदेश के कुल की गणना करेगा।
Inventory.GetCost (आइटम, CUSTOMERNAME, तारीख)

तो आप अन्य सहायक समारोह की तरह हो सकता है:

Inventory.ItemsLefts (int itemID)
Inventory.AddItem (int itemID, int मात्रा)
Inventory.RemoveItem (int itemID, int मात्रा)
Inventory.AddBusinessRule (...
Inventory.DeleteBusinessRule (...)

Comments

यह ठीक से संबंधित वर्गों से डेटा के लिए पूछने के लिए ठीक है। समस्या तब पैदा होती है जब मैं अप्रत्यक्ष रूप से संबंधित कक्षाओं से डेटा एक्सेस कर रहा हूं। आदेश वर्ग में उस तर्क को लागू करने के लिए आदेश वर्ग को सीधे वस्तु वस्तु (जिसमें आवश्यक मूल्य निर्धारण डेटा शामिल है) के साथ सौदा करना होगा। यह वह हिस्सा है जो मुझे परेशान करता है क्योंकि यह कक्षाओं के लिए कपलिंग ऑर्डर है जो (आदर्श रूप से) इसके बारे में कुछ नहीं पता होगा।

— विंस्टन इवर्ट

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

— विंस्टन एवर्ट

मुझे इस बात से कोई मतलब नहीं है कि आप क्यों चाहते हैं कि इन्वेंट्री को आईडी नंबरों का उपयोग करके संदर्भित किया जाए, फिर ऑब्जेक्ट रेफरेंस। यह मेरे लिए बेहतर लगता है कि वस्तु संदर्भों और मात्राओं का ध्यान रखें और फिर आइटम आईडी और संदर्भ।

— विंस्टन इवर्ट

मैं वास्तव में यह सुझाव नहीं दे रहा हूं। मुझे लगता है कि आपके पास ऑर्डर आइटम के लिए अभी भी एक वर्ग या संरचना होनी चाहिए। मुझे नहीं लगता कि व्यक्तिगत इन्वेंट्री आइटम वस्तुओं की कीमत मुख्य रूप से अंदर होनी चाहिए क्योंकि मुझे यकीन नहीं है कि आप इसे किसी तरह के डेटाबेस से पूछेंगे। ऑर्डर या इन्वेंट्री आइटम कड़ाई से एक आइटम वर्ग होगा जिसमें एक आइटम पहचानकर्ता और एक मात्रा होगी। आदेश में इन वस्तुओं की एक सूची होगी।

— पेमदास

मैं वास्तव में निश्चित नहीं हूं कि आप दूसरी टिप्पणी में क्या पूछ रहे हैं। प्रत्येक वस्तु को वस्तु नहीं बनना है। मुझे वास्तव में यकीन नहीं है कि आप किसी प्रकार के आईडी के बिना किसी विशिष्ट आइटम का पता कैसे लगा पाएंगे।

— पेमदास

Answer 4

इस बारे में अधिक सोचने के बाद, मैं अपनी वैकल्पिक रणनीति लेकर आया हूं।

एक मूल्य वर्ग को परिभाषित करें। Inventory.GetPrice()एक मूल्य वस्तु देता है

Price OrderItem::GetPrice()
{
    return inventory.GetPrice().quantity(quantity);
}

Currency OrderItem::GetTotal()
{
    Price price = empty_price();
    for(item in order_items)
    {
         price = price.combine( item.GetPrice() )
    }
    price = price.date(date).customer(customer);
    return price.GetActualPrice();
}

अब मूल्य वर्ग (और संभवत: कुछ संबंधित वर्ग) मूल्य निर्धारण के तर्क को उलझा देते हैं और इसके बारे में चिंता करने की जरूरत नहीं है। मूल्य ऑर्डर / ऑर्डर इटेम के बारे में कुछ भी नहीं जानता है, इसके बजाय बस इसमें दी गई जानकारी है।