यदि आप घटकों के बीच कम युग्मन बनाना चाहते हैं तो आप संकेत का उपयोग करते हैं। उदाहरण Larman यूएमएल और पैटर्न लागू करने में सुझाव देता है एक वर्ग करकलक्यूलेटर एडाप्टर है। संभावित एडाप्टर के आंतरिक कार्यों को जानने से ग्राहकों को ढालने के लिए, वह उन्हें एक संकेत के साथ छुपाता है, केवल आवश्यक API को उजागर करता है। यह संकेतक adaptees के साथ अत्यधिक मिल जाएगा, लेकिन केवल ग्राहकों के साथ मिलकर।
PersistentStorage
शुद्ध निर्माण से वास्तव में एक Indirecton (Larman किताब में ऐसा कहा गया है) में यह कम युग्मन प्रदान करता है। Pure Fabrication
इससे परे चला जाता है हालांकि इसमें यह ऑब्जेक्ट बनाता है जो आपके डोमेन मॉडल का हिस्सा नहीं हैं।
उदाहरण लार्मन एक डोमेन क्लास Sale
देता है। चूंकि Sale
में सभी डेटा सहेजने के लिए है, तो यह बिक्री के लिए तर्क रखने के लिए एक उम्मीदवार होगा (सूचना विशेषज्ञ)। हालांकि, दृढ़ता तर्क बिक्री की अवधारणा से संबंधित नहीं है, इसलिए कक्षा असंगत हो जाएगी। साथ ही, किसी विशेष डीबी एपीआई को बिक्री को जोड़कर, आप पुन: उपयोग (बचाव के लिए संकेत) सीमित करते हैं। और क्योंकि बचत एक सामान्य गतिविधि है, इसलिए आप ऑब्जेक्ट्स में भी कोड डुप्लिकेट करेंगे जिन्हें सहेजने की भी आवश्यकता है। इससे बचने के लिए, आप कुछ (शुद्ध फैब्रिकेशन) बनाते हैं, जिसका अर्थ है कि आप ऐसा कुछ बनाते हैं जो डोमेन मॉडल का हिस्सा न हो (यहां: PersistentStorage
), लेकिन फिर भी आपके एप्लिकेशन में एक आवश्यक गतिविधि कैप्चर करता है।
इस तरह, शुद्ध फैब्रिकेशन यह एक विशेषज्ञता है या इंद्रधनुष का एक रूप है।
मैं जोड़ता हूं कि * शुद्ध फैब्रिकेशंस * परिभाषा के अनुसार ** अत्यंत समेकित ** है। आप उन्हें बनाते हैं क्योंकि आपके पास ऐसी ज़िम्मेदारी है जिसे आसानी से असाइन नहीं किया जा सकता है (* इंडिकेशन * के माध्यम से) किसी अन्य वर्ग में। लार्मन का मतलब है "हताश होना" :-) तो, उस जिम्मेदारी को लेने के लिए एक नई कक्षा बनाकर, वह वर्ग बहुत ही मिलनसार होगा क्योंकि यह केवल एक चीज कर रहा है। – Fuhrmanator