2011-06-22 15 views
11

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

अब कक्षा पदानुक्रम को डिजाइन करने के लिए 2 दृष्टिकोण हैं।
पहले एक है:

सिर्फ ठोस वर्ग IObject से प्राप्त करते हैं, और यह भी चुनें "क्षमता" करने के लिए अपने आधार वर्ग के रूप में इंटरफेस, संकेत मिलता है यह इस तरह के व्यवहार का समर्थन इंटरफ़ेस की तरह:, IHasColor
IHasTransformation

दूसरा एक है:

आधार वर्ग को व्यवस्थित करें, और ठोस में से एक उन लोगों से व्युत्पन्न वर्ग करते हैं: IObject, IColorObject, ITransfromationObject, IColorAndTransformationObject

मैं पहली बार एक (यह एक औपचारिक नाम है पसंद करते हैं?) क्योंकि यह अधिक लचीला है, और जैसा कि आप देख सकते हैं कि दूसरे में कक्षा संयोजन विस्फोट समस्या हो सकती है जब रंग, परिवर्तन ...

मैं आपके विचारों और सुझावों को जानना चाहता हूं।

धन्यवाद।

+0

पिछले उत्तर में से कोई एक क्यों हटा दिया गया है ??? –

+0

यह प्रश्न __not भाषा agnostic__ नहीं है, यदि आप थे, तो आप मिक्सिन्स का उपयोग करने जैसे अधिक सुरुचिपूर्ण विकल्पों पर विचार कर सकते हैं, जो आपके द्वारा वर्णित भाषा की प्रकृति (इंटरफेस का उपयोग करते हुए मैं सी # या जावा मानता हूं?) –

+0

@ पाब्लो फर्नांडीज मिक्सिन वह नाम है जो मुझे लगता है कि पहला समाधान –

उत्तर

8

कक्षाएं वस्तुओं की वास्तविक अवधारणा की वास्तविक अवधारणा को सारणी बनाती हैं।

ऑब्जेक्ट के लिए व्यवहार या क्षमताओं की वास्तविक अवधारणा को इंटरफेस करता है।

तो प्रश्न बन जाते हैं, क्या "रंग" वस्तु की संपत्ति है या क्या यह वस्तु की क्षमता है?

जब आप पदानुक्रम तैयार करते हैं तो आप दुनिया को एक संकुचित स्थान में बाधित कर रहे हैं। यदि आप ऑब्जेक्ट की संपत्ति के रूप में रंग लेते हैं तो आपको ऑब्जेक्ट्स, ऑब्जेक्ट्स, जिनके रंग हैं और जो नहीं हैं। क्या यह आपके "दुनिया" में फिट है?

यदि आप इसे एक क्षमता (इंटरफ़ेस) के रूप में मॉडल करते हैं तो आपके पास ऐसी ऑब्जेक्ट्स होंगी जो प्रदान करने में सक्षम हों, दुनिया को रंग दें, कहें।

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

मेरे लिए, को देखने के उस बिंदु से, क्या होगा समझ में होगा:

  • रंग वस्तु की एक संपत्ति है।असल में प्रत्येक ऑब्जेक्ट में रंग होना चाहिए, भले ही इसका पारदर्शी हो, भले ही उसका "कोई नहीं" हो, भले ही यह पता लगाना कि रंग के साथ कोई वस्तु = असली दुनिया में कोई मतलब नहीं है, फिर भी यह आपके लिए समझ में आ सकता है कार्यक्रम तर्क)।
  • परिवर्तन एक क्षमता है, यानी इंटरफ़ेस, ऑब्जेक्ट करने में सक्षम है, अन्य चीजों के साथ ऑब्जेक्ट करने में सक्षम हो सकता है या नहीं।
+0

बिल्कुल मेरा जवाब लिखते समय मैं क्या सोच रहा था लेकिन आपने कम और बेहतर शब्दों का उपयोग किया :) – grapkulec

+0

बहुत स्पष्ट रूप से डाल! – Mrchief

+0

धन्यवाद, मुझे लगता है कि इस बारे में सोचने का दूसरा तरीका यह है: जब हम पदानुक्रम में आईए और आईबी में वस्तुओं को वर्गीकृत करते हैं, तो यह महत्वपूर्ण है कि ऐसी कोई वस्तु न हो जिसमें आईए और आईबी दोनों गुण हों, या फिर हीरा विरासत होगी , और संयोजन विस्फोट (यदि बहुत सारे आईसी, आईडी हैं ..), इस मामले में अन्य वर्गों की क्षमता प्रदान करने के लिए एक व्यवहार इंटरफ़ेस के रूप में होना बेहतर है, जो अधिक लचीला है, है ना? –

1

मुझे लगता है कि आप कक्षाओं को छोड़कर इंटरफ़ेस में सीधे कूदते हैं। क्या यह आपके लिए ऐप की आवश्यकता है। एक "IObject" इंटरफ़ेस है? हो सकता है कि आपके वर्ग पदानुक्रम के लिए "कोब्जेक्ट" रूट क्लास आपकी मदद कर सके।

ऐसा लगता है कि विजेता नंबर 1 समाधान है, आपके पास "MyObject" हो सकता है, चाहे इंटरफ़ेस या प्रत्यक्ष श्रेणी का कार्यान्वयन हो। बाद में आप अपनी कक्षा पदानुक्रम में अतिरिक्त कक्षाएं या इंटरफेस जोड़ सकते हैं, जैसा आपको चाहिए।

कई अनुप्रयोगों (कुछ मेरा, कुछ अन्य) देखने के बाद, मुझे लगता है कि "मेरा कस्टम एप्लिकेशन क्लास पदानुक्रम रूट ऑब्जेक्ट" या "मेरा कस्टम एप्लिकेशन क्लास पदानुक्रम रूट इंटरफेस" डिज़ाइन पैटर्न होना चाहिए।

1

मैं अपनी परियोजना में कक्षा पदानुक्रम पर काम कर रहा हूं और मूल रूप से मेरे पास आपके प्रश्न में वर्णित समान स्थिति है।

मान लें कि मेरे पास बेस टाइप ऑब्जेक्ट है जो मेरे टूलकिट में अन्य सभी वर्गों की पूर्ण जड़ है। तो स्वाभाविक रूप से सब कुछ सीधे या इसके उप-वर्गों से प्राप्त होता है। एक सामान्य कार्यक्षमता है कि प्रत्येक ऑब्जेक्ट-व्युत्पन्न वर्ग को प्रदान करना होता है लेकिन कुछ पत्ते वर्गों के प्रभाव में दूसरों की तुलना में थोड़ा अलग होता है। उदाहरण के लिए प्रत्येक ऑब्जेक्ट में आकार और स्थिति होती है जिसे गुण या विधियों जैसे स्थिति = नए बिंदु (10, 10), चौड़ाई = 15, आदि के साथ बदला जा सकता है लेकिन ऐसे वर्ग हैं जिन्हें किसी संपत्ति की सेटिंग को अनदेखा करना चाहिए या स्वयं के अनुसार इसे संशोधित करना चाहिए आंतरिक राज्य पैरेंट विंडो के बाईं ओर डॉक किए गए नियंत्रण के बारे में सोचें। आप अपनी पसंद की ऊँचाई संपत्ति सेट कर सकते हैं लेकिन इसे आम तौर पर अनदेखा कर दिया जाएगा क्योंकि यह संपत्ति वास्तव में मूल कंटेनर नियंत्रण की ऊंचाई पर निर्भर करती है (या यह क्लाइंट एरिया ऊंचाई या उस तरह की sth) है।

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

तो हम खुश हैं लेकिन अब हमें ऑब्जेक्ट की आवश्यकता है जो क्लिक या होवर जैसे माउस ईवेंट पर प्रतिक्रिया करे। इसलिए हम सार ऑब्जेक्ट क्लास से MouseAwareObject प्राप्त करते हैं और ईवेंट और सामान लागू करते हैं।

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

और आखिरी चीज जो दिमाग में आती है वह है IDockable और IMouseAware इंटरफेस बनाने और उन्हें कार्यक्षमता को परिभाषित करने और उन्हें केवल उन वस्तुओं के लिए जोड़ें जो ठोस व्यवहार/कार्यान्वयन प्रदान करने की आवश्यकता है।

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

सभी प्रभावित वर्गों में इंटरफेस को लागू करने की असुविधा होती है लेकिन आप हमेशा कुछ "एडेप्टर" को लागू कर सकते हैं और केवल उन्हें कॉल अग्रेषित कर सकते हैं। इस तरह आपके पास डुप्लीकेट कार्यान्वयन नहीं है (कुछ विस्तार के लिए) और कार्य के अहसास के बीच decoupling है (आकार का मतलब विभिन्न वर्गों के लिए अलग-अलग चीजों का मतलब हो सकता है) और ग्राहक कोड की अपेक्षा।

शायद यह आपके प्रश्न के लिए आदर्श उत्तर नहीं है लेकिन शायद यह आपको अपने समाधान के लिए संकेत देगा।

+0

धन्यवाद, grapkulec –

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