2009-12-04 12 views
16

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

मैं इंटरफेस आधारित प्रोग्रामिंग में आया क्योंकि मैं पढ़ रहा था कि एपीआई कितनी अच्छी तरह डिज़ाइन की गई है और इसके बारे में और जानना चाहेंगे। अभी मैं स्पष्ट नहीं हूं कि इंटरफ़ेस के आस-पास एक एपीआई डिज़ाइन करने के बारे में सही तरीके से कैसे जाना है।

किसी भी जानकारी की बहुत सराहना की जाती है।

+0

यह एक डुप्लिकेट है। उदाहरण के लिए, प्रश्न 1413543 (http://stackoverflow.com/questions/1413543) देखें। – jason

+0

आप हेड फर्स्ट डिज़ाइन पैटर्न बुक करना चाहते हैं। हालांकि जावा में उदाहरण लिखे गए हैं, यह एक अच्छी शुरुआत है। – kragan

+1

@ जेसन: एक इंटरफ़ेस के लिए प्रोग्रामिंग आवश्यक इंटरफ़ेस आधारित प्रोग्रामिंग के बराबर नहीं है। इंटरफ़ेस का उपयोग करने के बजाय "इंटरफ़ेस आधारित प्रोग्रामिंग" के लिए और भी कुछ है, यह आमतौर पर एक वास्तुशिल्प निर्णय के रूप में अधिक है। –

उत्तर

24

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

इसका मतलब है कि:

  • आप वास्तविक निर्भरता को लागू करने से पहले अपने कोड लिख सकते हैं
  • आप वास्तव में आसानी से मजाक के माध्यम से परीक्षण कर सकते हैं (जो बदसूरत हो जाता है नकली कक्षाएं, बिना)
  • यह स्पष्ट है कार्यान्वयन के बजाय एपीआई के संदर्भ में आप क्या निर्भर करते हैं (यानी आपके पास लूसर युग्मन है)
+0

क्या कोई अच्छी किताब है जो सी # में प्रोग्रामिंग की "शैली" बताती है? – koumides

+1

@koumides: विशेष रूप से नहीं, लेकिन बहुत सारे लेख खोजने के लिए "नियंत्रण में उलझन" और "निर्भरता इंजेक्शन" की खोज करें। –

9

"Practical API Design" by Jaroslav Tulach का अध्याय 6 शीर्षक "इंटरफेस के खिलाफ कोड, नहीं क्रियान्वयन "। यह बताता है कि, एक विशिष्ट कार्यान्वयन के बजाय एक इंटरफ़ेस के खिलाफ कोडिंग करके, आप सिस्टम में मॉड्यूल (या घटक) को डीक्यूल कर सकते हैं और इसलिए सिस्टम की गुणवत्ता बढ़ा सकते हैं।

OOSC2 में बर्ट्रेंड मेयर स्पष्ट रूप से बताता है कि सिस्टम को "बंद करना" और इसे अधिक मॉड्यूलर बनाने से इसकी गुणवत्ता बढ़ जाती है।

3

यदि आप इंटरफेस के लिए Google हैं, तो आपको उपयोगी जानकारी मिल सकती है कि उपयोगी इंटरफ़ेस कितने उपयोगी हो सकते हैं।

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

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

यह विधि किसी भी नई प्रोग्रामिंग प्रोजेक्ट के लिए काफी मानक है और हर कोई इसे मंजूरी देगी।

2

यह ऐसा कुछ है जिसे मैं सी # विकास में भारी उपयोग करने की अनुशंसा नहीं करता हूं।

Interface-based programming मूल रूप से इंटरफेस के लिए प्रोग्रामिंग है। आप उन इंटरफेस को विकसित करते हैं जिन्हें आप अनुबंधों का उपयोग करने जा रहे हैं, और इंटरफेस के वास्तविक कार्यान्वयन इन अनुबंधों के पीछे छिपा हुआ है।

यह .NET से पहले बहुत आम था, क्योंकि विंडोज़ में पुन: प्रयोज्य घटकों को प्राप्त करने का सबसे अच्छा तरीका COM के माध्यम से था, जो हर जगह इंटरफेस के माध्यम से काम करता था। हालांकि, दिया गया।एनईटी की एक रनटाइम (सीएलआर) के साथ कई भाषाओं का समर्थन करने की क्षमता, साथ ही मूल कोड की तुलना में संस्करण के लिए यह बेहतर समर्थन है, जब आप सी # में प्रोग्रामिंग कर रहे हैं तो इंटरफ़ेस आधारित प्रोग्रामिंग की उपयोगिता नाटकीय रूप से कम हो जाती है (जब तक कि आप COM घटक बनाने की कोशिश कर रहे हैं, इस मामले में, आप अभी भी अपने सी # कक्षाओं से अप्रत्यक्ष रूप से COM इंटरफेस बना रहे होंगे)।

+0

डाउनवॉटर के लिए: मैं यह सुझाव नहीं दे रहा हूं कि इंटरफेस, अपने और अपने आप में, खराब हैं - बल्कि, इंटरफेस के आस-पास अपने पूरे एपीआई को डिजाइन करने की उपयोगिता, जो अक्सर "इंटरफेस आधारित प्रोग्रामिंग" का जिक्र करती है, जरूरी नहीं है सी # डेवलपर्स के लिए मान्य है क्योंकि यह COM दिनों में था। –

+0

कंक्रीट कक्षाओं (विशेष रूप से सीलबंद वाले बिना किसी वर्चुअल विधियों वाले) से इंटरफेस के खिलाफ मॉकिंग इतना आसान है। इसके अलावा मुझे अभी भी विश्वास है कि यह स्पष्ट करता है कि आप वास्तव में किस पर निर्भर करते हैं ... –

+0

@ जोन स्कीट: सच। नकली या गैर-वर्चुअल कक्षाओं की तुलना में इंटरफेस के खिलाफ मॉकिंग आसान हो सकती है, लेकिन अमूर्त वर्गों को आसानी से मजाक किया जा सकता है, और यदि आप सी # (जिसे प्रश्न में टैग किया गया था) का उपयोग कर रहे हैं तो संस्करण के कुछ फायदे हैं। –

3

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

YourInterface foo = CreateYourInterface(); 
foo.DoWork(); 
foo.DoMoreWork(); 

CreateYourInterface() YourInterface का ठोस कार्यान्वयन वापस करेगा।

YourInterface foo = CreateYourInterface(); 
+0

आपने वहां कोड की एक पंक्ति बदल दी है? कौनसा? शायद आप स्पष्टीकरण दे सकते हैं? – DOK

+0

YourInterface foo = CreateYourInterface() वह पंक्ति है जिसका मैं जिक्र कर रहा था। मैं बस यह इंगित कर रहा था कि अगर आपने फू को एक अलग ऑब्जेक्ट सौंपा है जो इंटरफ़ेस को भी कार्यान्वित करता है तो आपको उसी कोड के साथ अलग-अलग कार्यक्षमता मिल जाएगी। –

8

अगर इन बहुत लोकप्रिय विचार विमर्श मदद देखें::

What is the best analogy to help non-oop developers grok interface based programming?

Why would I want to use Interfaces?

When are interfaces needed?

When should one use interfaces? यह आपको एक लाइन बदलकर ऐप्स की कार्यप्रणाली बदलने की अनुमति देता

What is the purpose of interfaces?

Good Case For Interfaces

What does it mean to “program to an interface”?

0

इंटरफ़ेस आधारित प्रोग्रामिंग कार्यक्षमता के कार्यान्वयन decoupling और कैसे आप कार्यक्षमता का उपयोग के बारे में सोचा जा सकता है।

आप एक इंटरफेस
interface ICallSomeone { public bool DialNumber(string number); }

को परिभाषित करने और आप अपने कार्यान्वयन लिखने

public class callsomeone: ICallSomeone {
public bool DialNumber(string number) {
//dial number, return results }}

आप कार्यान्वयन के बारे में देखभाल के बिना इंटरफ़ेस का उपयोग। यदि आप कार्यान्वयन को बदलते हैं, तो कुछ भी परवाह नहीं करता क्योंकि यह केवल इंटरफ़ेस का उपयोग करता है।

0

एक बहुत ही सार दृश्य से, इंटरफ़ेस आधारित प्रोग्रामिंग एक प्लम्बर (पाइप जोड़ों और पाइप) द्वारा इस्तेमाल किया घटकों के लिए समान है।

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

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

सॉफ़्टवेयर घटकों के साथ पाइप और जोड़ों बदलें और समानताएं आश्चर्यजनक सरल हैं।

संबंधित मुद्दे