कल्पना कीजिए कि आपको किसी और के कोड का उपयोग करना होगा जिसे नीचे दिखाया गया है:
class Messy {
String concat(String param, String str) { /* ... */ }
boolean contains(String param, String s) { /* ... */ }
boolean isEmpty(String param) { /* ... */ }
boolean matches(String param, String regex) { /* ... */ }
boolean startsWith(String param, String prefix) { /* ... */ }
}
अब आप कल्पना कीजिए कि आपका कोड जो इस पर निर्भर करता है वह निम्न जैसा दिखता है:
String process(String param) {
Messy messy = new Messy();
if (messy.contains(param, "whatever")) {
return messy.concat(param, "-contains");
}
if (messy.isEmpty(param)) {
return messy.concat(param, "-empty");
}
if (messy.matches(param, "[whatever]")) {
return messy.concat(param, "-matches");
}
if (messy.startsWith(param, "whatever")) {
return messy.concat(param, "-startsWith");
}
return messy.concat(param, "-whatever");
// WTF do I really need to repeat bloody "param" 9 times above?
}
... और यह कि आप उपयोग करना आसान बनाना चाहते हैं, विशेष रूप से, उन मापदंडों के दोहराए जाने वाले उपयोग से छुटकारा पाने के लिए जिन्हें बस आपके आवेदन की आवश्यकता नहीं है।
ठीक है, इसलिए आप भ्रष्टाचार विरोधी परत का निर्माण शुरू करते हैं।
पहली बात यह सुनिश्चित करना है कि आपका "मुख्य कोड" Messyसीधे संदर्भित नहीं करता है । उदाहरण के लिए, आप निर्भरता प्रबंधन को इस तरह से व्यवस्थित करते हैं कि एक्सेस करने का प्रयास करने में Messyविफल रहता है।
दूसरा, आप एक समर्पित "लेयर" मॉड्यूल बनाते हैं जो केवल एक ही एक्सेस है Messyऔर इसे आपके "मुख्य कोड" में इस तरह से एक्सपोज़ करता है जो आपके लिए बेहतर समझ में आता है।
परत कोड निम्नलिखित की तरह दिखेगा:
class Reasonable { // anti-corruption layer
String param;
Messy messy = new Messy();
Reasonable(String param) {
this.param = param;
}
String concat(String str) { return messy.concat(param, str); }
boolean contains(String s) { return messy.contains(param, s); }
boolean isEmpty() { return messy.isEmpty(param); }
boolean matches(String regex) { return messy.matches(param, regex); }
boolean startsWith(String prefix) { return messy.startsWith(param, prefix); }
}
नतीजतन, आपका "मुख्य कोड" इसके बजाय, इसके बारे में Messyउपयोग Reasonableकरने के साथ गड़बड़ नहीं करता है:
String process(String param) {
Reasonable reasonable = new Reasonable(param);
// single use of "param" above and voila, you're free
if (reasonable.contains("whatever")) {
return reasonable.concat("-contains");
}
if (reasonable.isEmpty()) {
return reasonable.concat("-empty");
}
if (reasonable.matches("[whatever]")) {
return reasonable.concat("-matches");
}
if (reasonable.startsWith("whatever")) {
return reasonable.concat("-startsWith");
}
return reasonable.concat("-whatever");
}
ध्यान दें कि अभी भी कुछ गड़बड़ है, Messyलेकिन यह अब अंदर से काफी गहरा छिपा हुआ है Reasonable, जिससे आपका "मुख्य कोड" यथोचित रूप से स्वच्छ और भ्रष्टाचार से मुक्त हो जाता है जो कि Messyसामान के प्रत्यक्ष उपयोग द्वारा लाया जाएगा ।
उपरोक्त उदाहरण इस बात पर आधारित है कि C2 विकी पर एंटीकरप्शन लेयर को कैसे समझाया गया है:
यदि आपके एप्लिकेशन को डेटाबेस या किसी अन्य एप्लिकेशन से निपटने की आवश्यकता है, जिसका मॉडल आपके स्वयं के आवेदन के भीतर वांछित मॉडल के लिए अवांछनीय या अनुपयुक्त है, तो उस मॉडल और आपके / से अनुवाद करने के लिए एक एंटीकोरप्लेंयर का उपयोग करें।
नोट उदाहरण जानबूझकर संक्षिप्त रखने के लिए जानबूझकर सरल और घनीभूत किया जाता है।
यदि आपके पास एंटी-करप्शन लेयर के पीछे एक बड़ा मेस-ऑफ-एपीआई है, तो एक ही दृष्टिकोण लागू होता है: पहला, सुनिश्चित करें कि आपका "मुख्य कोड" सीधे भ्रष्ट सामग्री तक नहीं पहुंचता है और दूसरा, इसे इस तरह से एक्सपोज़ करें जो अधिक है आपके उपयोग के संदर्भ में सुविधाजनक है।
जब ऊपर की एक सरलीकृत उदाहरण से परे आपकी परत को "स्केलिंग" किया जाता है, तो ध्यान रखें कि आपके एपीआई को सुविधाजनक बनाना आवश्यक रूप से एक तुच्छ कार्य नहीं है। अपनी परत को सही तरीके से डिजाइन करने के प्रयास का निवेश करें, इकाई परीक्षणों आदि के साथ इसके इच्छित उपयोग को सत्यापित करें ।
दूसरे शब्दों में, सुनिश्चित करें कि आपका एपीआई वास्तव में एक छुपाता है पर एक सुधार है, सुनिश्चित करें कि आप भ्रष्टाचार की एक और परत का परिचय नहीं देते हैं।
पूर्णता के लिए, इस और संबंधित पैटर्न एडेप्टर और मुखौटा के बीच सूक्ष्म लेकिन महत्वपूर्ण अंतर पर ध्यान दें । जैसा कि इसके नाम से संकेत मिलता है, एंटीकरप्शन परत मानती है कि अंतर्निहित एपीआई में गुणवत्ता के मुद्दे हैं ("दूषित है") और उल्लिखित मुद्दों की सुरक्षा प्रदान करने का इरादा रखता है।
आप इसे इस तरह से सोच सकते हैं: यदि आप सही ठहरा सकते हैं कि लाइब्रेरी डिजाइनर इसके Reasonableबजाय अपनी कार्यक्षमता को उजागर करना बेहतर Messyहोगा, तो इसका मतलब होगा कि आप एंटीकोर्पोरशन लेयर पर काम कर रहे हैं, अपना काम कर रहे हैं , अपनी डिज़ाइन की गलतियों को ठीक कर रहे हैं ।
जैसा कि विरोध किया गया है, एडेप्टर और फेसेड अंतर्निहित डिजाइन की गुणवत्ता पर धारणा नहीं बनाते हैं। इन्हें एपीआई पर लागू किया जा सकता है जिसे अच्छी तरह से शुरू करने के लिए डिज़ाइन किया गया है, बस इसे अपनी विशिष्ट आवश्यकताओं के लिए अनुकूल बनाना चाहिए।
वास्तव में, यह अनुमान लगाने के लिए और भी अधिक उत्पादक हो सकता है कि एडेप्टर और फैकेड जैसे पैटर्न अंतर्निहित कोड को अच्छी तरह से डिजाइन करने की उम्मीद करते हैं। आप इसे इस तरह से सोच सकते हैं: विशेष रूप से उपयोग के मामले के लिए अच्छी तरह से डिज़ाइन किए गए कोड को बहुत मुश्किल नहीं होना चाहिए। यदि यह पता चलता है कि आपके एडेप्टर का डिज़ाइन अपेक्षा से अधिक प्रयास करता है, तो यह संकेत कर सकता है कि अंतर्निहित कोड, ठीक है, किसी तरह "दूषित" है। उस स्थिति में, आप कार्य को अलग-अलग चरणों में विभाजित करने पर विचार कर सकते हैं: पहला, अंतर्निहित API को ठीक से संरचित तरीके से पेश करने के लिए एक एंटीकोर्सोशन लेयर स्थापित करें और उसके बाद, उस प्रोटेक्शन लेयर पर अपने एडेप्टर / मोहरे को डिज़ाइन करें।