उपयोगकर्ता इंटरफ़ेस से कक्षाएं काटना

Question

जब यह लिखने के लिए आता है तो सबसे अच्छा अभ्यास क्या है जो उपयोगकर्ता इंटरफ़ेस के बारे में जानना हो सकता है। यह जानने के लिए कि क्या कोई वर्ग खुद को खींचना नहीं चाहता है क्योंकि उपयोगकर्ता इंटरफ़ेस (कंसोल, जीयूआई, आदि) पर निर्भर करता है?

कई प्रोग्रामिंग पुस्तकों में मैं "आकृति" उदाहरण के पार आया हूं जो विरासत को दर्शाता है। बेस क्लास आकार में एक ड्रा () विधि होती है जो प्रत्येक आकार जैसे कि एक सर्कल और स्क्वायर ओवरराइड होती है। यह बहुरूपता के लिए अनुमति देता है। लेकिन ड्रा () विधि बहुत ज्यादा निर्भर नहीं है कि उपयोगकर्ता इंटरफ़ेस क्या है? अगर हम यह क्लास Win Forms के लिए कहते हैं, तो हम इसे कंसोल ऐप या वेब ऐप के लिए दोबारा इस्तेमाल नहीं कर सकते। क्या ये सही है?

सवाल का कारण यह है कि मैं खुद को हमेशा अटक जाता हूं और कक्षाओं को सामान्य करने के तरीके पर लटका देता हूं ताकि वे सबसे उपयोगी हों। यह वास्तव में मेरे खिलाफ काम कर रहा है और मैं सोच रहा हूं कि क्या मैं "बहुत कठिन कोशिश कर रहा हूं"।

Comments

आप डिकॉयल क्यों करना चाहते हैं? क्योंकि आपने सुना कि ऐसा करना सही था या आपके पास अन्य कारण हैं?

— सॉयलेंटग्रे 19

पूरे "वर्ग को यह जानना चाहिए कि कैसे खुद को आकर्षित करना है" सिर्फ एक भयानक, प्राचीन उदाहरण है जो मैं चाहता हूं कि वह गायब हो जाएगा। विशेष रूप से खेल प्रोग्रामर के ढेर =) पर

— पैट्रिक ह्यूजेस

@ क्या मैं वास्तव में स्कूल के बाहर बहुत अनुभवी नहीं हूँ। मैंने किताबें पढ़ी हैं और मैं वास्तव में डिजाइन पैटर्न और सर्वोत्तम प्रथाओं के बारे में नई चीजें सीखना और पढ़ना पसंद करता हूं। तो हां, आप कह सकते हैं कि मैंने सुना है कि डिकॉउलिंग अच्छी है, लेकिन यह भी समझ में आता है। मैं कोड लिखना चाहता हूं जिसे मैं एक डेस्कटॉप WinForms ऐप के लिए उपयोग कर सकता हूं, उदाहरण के लिए, फिर उस कोड को ले लो और किसी वेबसाइट या यहां तक ​​कि चांदी के ऐप के लिए जितना संभव हो उतना पुन: उपयोग करें।

— पीट

@ पे - यह एक अच्छा जवाब है।

— सोयलेंटग्रे जूल 27'11

@Prick: निष्पक्ष होने के लिए, यदि आप एक Shapeवर्ग लिख रहे हैं , तो आप शायद ग्राफिक्स स्टैक खुद लिख रहे हैं, ग्राफिक्स स्टैक के लिए क्लाइंट नहीं लिख रहे हैं।

— केन ब्लूम

Answer 1

जब यह लिखने के लिए आता है तो सबसे अच्छा अभ्यास क्या है जो उपयोगकर्ता इंटरफ़ेस के बारे में जानना हो सकता है। यह जानने के लिए कि क्या कोई वर्ग खुद को खींचना नहीं चाहता है क्योंकि उपयोगकर्ता इंटरफ़ेस (कंसोल, जीयूआई, आदि) पर निर्भर करता है?

यह वर्ग और उपयोग के मामले पर निर्भर करता है। आवश्यक रूप से स्वयं को आकर्षित करने का तरीका जानने वाला एक दृश्य तत्व एकल जिम्मेदारी सिद्धांत का उल्लंघन नहीं है।

कई प्रोग्रामिंग पुस्तकों में मैं "आकृति" उदाहरण के पार आया हूं जो विरासत को दर्शाता है। बेस क्लास आकार में एक ड्रा () विधि होती है जो प्रत्येक आकार जैसे कि एक सर्कल और स्क्वायर ओवरराइड होती है। यह बहुरूपता के लिए अनुमति देता है। लेकिन ड्रा () विधि बहुत ज्यादा निर्भर नहीं है कि उपयोगकर्ता इंटरफ़ेस क्या है?

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

अगर हम यह क्लास Win Forms के लिए कहते हैं, तो हम इसे कंसोल ऐप या वेब ऐप के लिए दोबारा इस्तेमाल नहीं कर सकते। क्या ये सही है?

खैर, यह सच है। यदि आप Windows प्रपत्र के लिए एक UserControl (सामान्य रूप से एक वर्ग नहीं) लिखते हैं, तो आप इसे कंसोल के साथ उपयोग नहीं कर पाएंगे। लेकिन यह कोई समस्या नहीं है। आप किसी भी तरह के प्रेजेंटेशन के साथ काम करने के लिए विंडोज फॉर्म के लिए यूजरकंट्रोल की उम्मीद क्यों करेंगे? UserControl को एक काम करना चाहिए और इसे अच्छी तरह से करना चाहिए। यह परिभाषा द्वारा प्रस्तुति के एक निश्चित रूप से जुड़ा हुआ है। अंत में, उपयोगकर्ता को कुछ ठोस की जरूरत है न कि अमूर्त की। यह केवल चौखटे के लिए आंशिक रूप से सही हो सकता है, लेकिन अंत-उपयोगकर्ता अनुप्रयोगों के लिए, यह है।

हालांकि, इसके पीछे के तर्क को विघटित किया जाना चाहिए, इसलिए आप इसे अन्य प्रस्तुति प्रौद्योगिकियों के साथ फिर से उपयोग कर सकते हैं। अपने आवेदन के लिए रूढ़िवादिता को बनाए रखने के लिए जहां आवश्यक हो, इंटरफेस का परिचय दें। सामान्य नियम यह है: ठोस चीजों को अन्य ठोस चीजों के साथ विनिमेय होना चाहिए।

सवाल का कारण यह है कि मैं खुद को हमेशा अटक जाता हूं और कक्षाओं को सामान्य करने के तरीके पर लटका देता हूं ताकि वे सबसे उपयोगी हों। यह वास्तव में मेरे खिलाफ काम कर रहा है और मैं सोच रहा हूं कि क्या मैं "बहुत कठिन कोशिश कर रहा हूं"।

तुम्हें पता है, चरम प्रोग्रामर उनके YAGNI रवैये के शौकीन हैं । उदारतापूर्वक सब कुछ लिखने की कोशिश मत करो और सब कुछ सामान्य उद्देश्य बनाने के लिए बहुत कठिन प्रयास न करें। इसे ओवरेंजिरिंग कहा जाता है और अंततः पूरी तरह से जटिल कोड हो जाएगा। प्रत्येक घटक को एक कार्य दें और सुनिश्चित करें कि यह इसे अच्छी तरह से करता है। जहां आवश्यक हो, वहां अमूर्तता में रखें, जहां आप चीजों को बदलने की उम्मीद करते हैं (उदाहरण के लिए ड्राइंग संदर्भ के लिए इंटरफ़ेस, जैसे ऊपर कहा गया है)।

सामान्य तौर पर, व्यावसायिक अनुप्रयोगों को लिखते समय, आपको हमेशा चीजों को कम करने की कोशिश करनी चाहिए। एमवीसी और एमवीवीएम तर्क को प्रस्तुति से अलग करने के लिए महान हैं, इसलिए आप इसे वेब प्रस्तुति या कंसोल एप्लिकेशन के लिए पुन: उपयोग कर सकते हैं। ध्यान रखें कि अंत में, कुछ चीजों को ठोस करना होगा। आपके उपयोगकर्ता अमूर्तता के साथ काम नहीं कर सकते, उन्हें कुछ ठोस करने की आवश्यकता है। सार केवल आपके लिए प्रोग्रामर हैं, कोड को एक्स्टेंसिबल और मेंटेन रखने के लिए प्रोग्रामर। आपको अपने कोड के लचीले होने की आवश्यकता के बारे में सोचने की ज़रूरत है। आखिरकार सभी अमूर्तियों को किसी ठोस चीज को जन्म देना पड़ता है।

संपादित करें: यदि आप आर्किटेक्चर और डिज़ाइन तकनीकों के बारे में अधिक पढ़ना चाहते हैं जो सर्वोत्तम अभ्यास प्रदान कर सकते हैं, तो मैं आपको @Catchops उत्तर पढ़ने और विकिपीडिया पर SOLID प्रथाओं के बारे में पढ़ने का सुझाव देता हूं ।

इसके अलावा, शुरुआत के लिए, मैं हमेशा निम्नलिखित पुस्तक की सिफारिश करता हूं: हेड फर्स्ट डिजाइन पैटर्न । यह आपको अमूर्त तकनीकों / ओओपी डिज़ाइन प्रथाओं को समझने में मदद करेगा, जो कि गोफ बुक की तुलना में अधिक है (जो उत्कृष्ट है, यह सिर्फ शुरुआती के अनुरूप नहीं है)।

Comments

अच्छा जवाब है, लेकिन चरम प्रोग्रामर 'अमूर्त में नहीं डालते हैं जहां हम चीजों को बदलने की उम्मीद करते हैं'। हम अमूर्त में डालते हैं जहां चीजें बदल रही हैं, कोड को ऊपर उठाने के लिए।

— केविन क्लाइन

जब तक आप एक एपीआई के साथ एक सार्वजनिक रूप से उपलब्ध पुस्तकालय डिजाइन कर रहे हैं, जो पिछले व्यवहार और इंटरफेस के अनुरूप करने की आवश्यकता है, जब तक @kevin की रूपरेखा।

— मैग्नस वोल्फेल्ट

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

— केविन क्लाइन

Answer 2

आप निश्चित रूप से सही हैं। और नहीं, आप "ठीक कोशिश कर रहे हैं" :)

एकल जिम्मेदारी सिद्धांत के बारे में पढ़ें

कक्षा के आपके आंतरिक कामकाज और उपयोगकर्ता को यह जानकारी जिस तरह से प्रस्तुत की जानी चाहिए वह दो जिम्मेदारियां हैं।

वर्गों के पतन से डरो मत। शायद ही कभी समस्या बहुत अधिक अमूर्त और अवनत होती है :)

दो बहुत ही प्रासंगिक पैटर्न वेब अनुप्रयोगों के लिए मॉडल-व्यू-नियंत्रक और सिल्वरलाइट / डब्ल्यूपीएफ के लिए मॉडल व्यू व्यूकोड हैं ।

Comments

+1 आप एमवीसी का उपयोग न करने वाले वेब एप्लिकेशन के लिए भी कर सकते हैं, कम से कम यह आपको उन शब्दों को सोचने में मदद करता है जो जिम्मेदारियों को स्पष्ट रखते हैं।

— पैट्रिक ह्यूजेस

एमवीवीएम एमवीसी को सिलिमर है। MVC ज्यादातर वेब एप्लिकेशन जैसे स्टेटलेस एप्लिकेशन के लिए है।

— बोरिस यानकोव

-1 मेरे अनुभव में सबसे आम समस्याओं में से एक समय से पहले सामान्यीकरण और सामान्य तौर पर ओवर-इंजीनियरिंग है।

— डायटबुद्ध

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

— बोरिस यांकोव

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

— फ्रैंक हिलमैन

Answer 3

मैं MVVM का बहुत उपयोग करता हूं और मेरी राय में, एक बिजनेस ऑब्जेक्ट क्लास को उपयोगकर्ता इंटरफ़ेस के बारे में कुछ भी जानने की आवश्यकता नहीं होनी चाहिए। सुनिश्चित करें कि उन्हें SelectedItemया IsChecked, या IsVisible, आदि जानने की आवश्यकता हो सकती है , लेकिन उन मूल्यों को किसी विशेष यूआई में टाई करने की आवश्यकता नहीं है और वर्ग पर सामान्य गुण हो सकते हैं।

यदि आपको कोड के पीछे इंटरफ़ेस में कुछ करने की आवश्यकता है, जैसे फोकस सेट करना, एनीमेशन चलाना, हॉट कीज़ संभालना आदि, तो कोड यूआई के कोड-पीछे का हिस्सा होना चाहिए, न कि आपके व्यावसायिक तर्क वर्ग।

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

Answer 4

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

ठीक है ... आप यह देखने में सही हैं कि यदि आप एक iPhone पर एक सर्कल बनाना चाहते हैं, तो यह एक पीसी पर चलने वाली खिड़कियों पर ड्राइंग करने से अलग होगा। आपके पास (इस मामले में) एक ठोस वर्ग है जो iPhone पर एक अच्छी तरह से खींचता है, और दूसरा जो पीसी पर एक अच्छी तरह से खींचता है। यह वह जगह है जहाँ मूल OO वंशानुक्रम है कि उन सभी आकृतियों के उदाहरण टूट जाते हैं। आप इसे अकेले विरासत के साथ नहीं कर सकते।

यही वह जगह है जहाँ इंटरफेस आते हैं - गैंग ऑफ़ फोर बुक स्टेट्स (MUST READ) - हमेशा वंशानुक्रम पर कार्यान्वयन का पक्ष लेते हैं। दूसरे शब्दों में, एक आर्किटेक्चर को एक साथ जोड़ने के लिए इंटरफेस का उपयोग करें जो हार्ड कोडित निर्भरता पर भरोसा किए बिना कई तरह से विभिन्न कार्य कर सकते हैं।

मैंने SOLID सिद्धांतों के लिए रेफरी को देखा है । वे महान हैं। 'एस' एकल जिम्मेदारी सिद्धांत है। लेकिन, 'D' डिपेंडेंसी इनवर्जन के लिए है। कंट्रोल ऑफ पैटर्न (डिपेंडेंसी इंजेक्शन) का उपयोग यहां किया जा सकता है। यह बहुत शक्तिशाली है और इसका उपयोग इस सवाल का जवाब देने के लिए किया जा सकता है कि एक सिस्टम को कैसे आर्किटेक्ट किया जाए जो एक iPhone के साथ-साथ पीसी के लिए एक सर्कल बना सके।

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

यह एक ऐसे प्रश्न का त्वरित उच्च-स्तरीय उत्तर है जो अधिक विस्तृत उत्तर के योग्य है। मैं आपको इन पैटर्नों में और देखने के लिए प्रोत्साहित करता हूं। इन पेटेंटों के कुछ और ठोस क्रियान्वयन को MVC और MVVM के नाम से जाना जा सकता है।

सौभाग्य!

Comments

मुझे यह बहुत पसंद है जब कोई व्यक्ति टिप्पणी के बिना कुछ नहीं देता है, तो (व्यंग्य, बेशक)। मेरे द्वारा कहे गए सिद्धांत सत्य हैं - क्या नीचे वाले कृपया खड़े होकर कहेंगे कि क्यों।

— कैच

Answer 5

जब यह लिखने के लिए आता है तो सबसे अच्छा अभ्यास क्या है जो उपयोगकर्ता इंटरफ़ेस के बारे में जानना हो सकता है।

यह जानने के लिए कि क्या कोई वर्ग खुद को खींचना नहीं चाहता है क्योंकि उपयोगकर्ता इंटरफ़ेस (कंसोल, जीयूआई, आदि) पर निर्भर करता है?

इस मामले में आप अभी भी एमवीसी / एमवीवीएम का उपयोग कर सकते हैं और सामान्य इंटरफ़ेस का उपयोग करके विभिन्न यूआई कार्यान्वयनों को इंजेक्ट कर सकते हैं:

public interface IAgnosticChartDrawing
{
   public void Draw(ChartProperties chartProperties);
   event EventHandler ChartPanned;
}

public class GuiChartDrawer : UserControl, IAgnosticChartDrawing
{
    public void Draw(ChartProperties chartProperties)
    {
        //GDI, GTK or something else...
    }

    //Implement event based on mouse actions
}

public class ConsoleChartDrawer : IAgnosticChartDrawing
{
    public void Draw(ChartProperties chartProperties)
    {
        //'Draw' using characters and symbols...
    }

    //Implement event based on keyboard actions
}

IAgnosticChartDrawing guiView = new GuiChartDrawer();
IAgnosticChartDrawing conView = new ConsoleChartDrawer();

Model model = new FinancialModel();

SampleController controllerGUI = new SampleController(model, guiView);
SampleController controllerConsole = new SampleController(model, conView);

इस प्रकार आप नए प्रकार के GUI जोड़ने में सक्षम होने के साथ-साथ अपने नियंत्रक और मॉडल तर्क का पुनः उपयोग कर पाएंगे।

Answer 6

वहाँ करने के लिए विभिन्न पैटर्न हैं: MVP, MVC, MVVM, आदि ...

पढ़ने के लिए मार्टिन फाउलर (बड़ा नाम) का एक अच्छा लेख है जीयूआई आर्किटेक्चर: http://www.martinfowler.com/eaaDev/uiArchs.html

एमवीपी का अभी तक उल्लेख नहीं किया गया है लेकिन यह निश्चित रूप से उद्धृत होने के लायक है: इस पर एक नज़र डालें।

यह Google वेब टूलकिट के डेवलपर्स द्वारा उपयोग किया जाने वाला पैटर्न है, यह वास्तव में साफ-सुथरा है।

आप वास्तविक कोड, वास्तविक उदाहरण और तर्क देख सकते हैं कि यह दृष्टिकोण यहाँ क्यों उपयोगी है:

http://code.google.com/webtoolkit/articles/mvp-architecture.html

http://code.google.com/webtoolkit/articles/mvp-architecture-2.html

इस या इसी तरह के दृष्टिकोणों का पालन करने के फायदों में से एक जो कि यहां पर जोर नहीं दिया गया है वह है परीक्षण क्षमता! बहुत सारे मामलों में मैं कहूंगा कि मुख्य लाभ है!

Comments

लिंक के लिए +1। मैं MVDN के बारे में MSDN पर एक समान लेख पढ़ रहा था और वे Google लेख थोड़े अलग पैटर्न पर बेहतर हैं।

— पीट

Answer 7

यह उन जगहों में से एक है जहां ओओपी अमूर्तता में एक अच्छा काम करने में विफल रहता है। OOP बहुरूपता एक एकल चर ('यह') पर गतिशील प्रेषण का उपयोग करता है। यदि बहुरूपता आकार में निहित थी, तो आप रेंडरर (कंसोल, जीयूआई आदि) पर बहुरूपी-सहयोगी प्रेषण नहीं कर सकते।

एक प्रोग्रामिंग सिस्टम पर विचार करें जो दो या अधिक चर पर प्रेषण कर सकता है:

poly_draw(Shape s, Renderer r)

और यह भी मान लें कि सिस्टम आपको आकृति के प्रकारों और रेंडरर प्रकारों के विभिन्न संयोजनों के लिए पॉली_ड्राइव को व्यक्त करने का एक तरीका दे सकता है। फिर आकृतियों और रेंडरर्स के वर्गीकरण के साथ आना आसान होगा? प्रकार चेकर किसी तरह से आपको यह पता लगाने में मदद करेगा कि क्या आकार और रेंडरर संयोजन हैं जिन्हें आपने लागू करने से चूक दिया होगा।

अधिकांश ओओपी भाषाएं ऊपर की तरह कुछ का समर्थन नहीं करती हैं (कुछ करते हैं, लेकिन वे मुख्यधारा नहीं हैं)। मेरा सुझाव है कि आप वर्कअराउंड के लिए विज़िटर पैटर्न पर एक नज़र डालें ।

Answer 8

... उपयोगकर्ता इंटरफ़ेस क्या है, इस पर बहुत ज्यादा निर्भरता नहीं है? अगर हम यह क्लास Win Forms के लिए कहते हैं, तो हम इसे कंसोल ऐप या वेब ऐप के लिए दोबारा इस्तेमाल नहीं कर सकते। क्या ये सही है?

ऊपर से मुझे सही लगता है। मेरी समझ के अनुसार, कोई यह कह सकता है कि एमवीसी डिज़ाइन पैटर्न के संदर्भ में नियंत्रक और दृश्य के बीच अपेक्षाकृत तंग युग्मन है । इसका मतलब यह भी है कि डेस्कटॉप-कंसोल-वेबएप के बीच स्विच करने के लिए एक नियंत्रक और दृश्य दोनों को एक जोड़ी के रूप में बदलना होगा - केवल मॉडल अपरिवर्तित रहता है।

... मुझे लगता है कि मैं हमेशा अटक रहा हूं और कक्षाओं को सामान्य करने के तरीके पर लटका हूं ताकि वे सबसे उपयोगी हों।

अच्छी तरह से ऊपर मेरे वर्तमान ले यह है कि यह दृश्य-नियंत्रक युग्मन जिसके बारे में हम बात कर रहे हैं वह ठीक है और इससे भी अधिक, यह आधुनिक डिजाइन में बहुत फैशनेबल है।

हालाँकि, एक या दो साल पहले मैंने भी इस बारे में असुरक्षित महसूस किया था। मैंने पैटर्न और ओओ डिज़ाइन पर सन फोरम में चर्चा का अध्ययन करने के बाद अपना मन बदल दिया है।

यदि आप रुचि रखते हैं, तो इस मंच को स्वयं आज़माएँ - यह अब Oracle ( लिंक ) में स्थानांतरित हो गया है । यदि आप वहां पहुंचते हैं , तो पिंगिंग पुरुष सैश की कोशिश करें - फिर, इन मुश्किल मामलों पर उनका स्पष्टीकरण मेरे लिए सबसे उपयोगी निकला। मैं यह नहीं बता सकता कि क्या वह अभी भी भाग लेता है - खुद मैं काफी समय से वहां नहीं था

Answer 9

लेकिन ड्रा () विधि बहुत ज्यादा निर्भर नहीं है कि उपयोगकर्ता इंटरफ़ेस क्या है?

व्यावहारिक रूप से, आपके सिस्टम में कुछ कोड को यह जानना आवश्यक है कि किसी चीज़ को कैसे आकर्षित किया जाए, Rectangleयदि वह उपयोगकर्ता-अंत की आवश्यकता है। और यह कुछ बिंदुओं पर उबलने वाला है, जो वास्तव में निम्न स्तर की चीजें जैसे कि पिक्सेल को व्यवस्थित करना या कंसोल में कुछ प्रदर्शित करना है।

एक युग्मन दृष्टिकोण से मेरे लिए सवाल यह है कि इस प्रकार की जानकारी पर क्या / क्या निर्भर करना चाहिए, और किस हद तक विस्तार (कितना सार, उदा)?

एट्रिब्यूटिंग ड्रॉइंग / रेंडरिंग कैपेबिलिटीज

क्योंकि यदि उच्च-स्तरीय ड्राइंग कोड केवल कुछ बहुत सार पर निर्भर करता है, तो वह एब्सट्रैक्शन उन सभी प्लेटफार्मों पर काम करने में सक्षम हो सकता है (जो ठोस कार्यान्वयन के प्रतिस्थापन के माध्यम से) आप लक्ष्य करने का इरादा रखते हैं। एक आकस्मिक उदाहरण के रूप में, कुछ बहुत ही अमूर्त IDrawerइंटरफ़ेस कंसोल और GUI API दोनों में प्लॉट शेप जैसी चीजों को करने में सक्षम हो सकते हैं (कंसोल कार्यान्वयन ASCII कला के साथ कुछ 80xN "छवि" जैसे कंसोल का इलाज कर सकता है)। बेशक यह एक विपरीत उदाहरण है क्योंकि आमतौर पर आप जो करना चाहते हैं वह एक इमेज / फ्रेम बफर की तरह कंसोल आउटपुट का इलाज करता है; आमतौर पर अधिकांश उपयोगकर्ता-एंड को कॉनसोल में अधिक टेक्स्ट-आधारित इंटरैक्शन के लिए कॉल की आवश्यकता होती है।

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

लेकिन कहते हैं कि आप एक Playstation पोर्टेबल, iPhone, एक XBox एक, और शक्तिशाली गेमिंग पीसी के बीच भिन्न होने वाले गैरी विवरण को दूर करने की कोशिश कर रहे हैं, जबकि आपकी जरूरतों को हर एक पर सबसे अत्याधुनिक 3 डी प्रतिपादन / छायांकन तकनीकों का उपयोग करना है। । उस मामले में जब एक अंतर्निहित इंटरफ़ेस के साथ आने के लिए रेंडरिंग डिटेल्स को अमूर्त करने की कोशिश की जाती है, जब अंतर्निहित हार्डवेयर क्षमताएं और API अलग-अलग होते हैं, इसलिए बेतहाशा समय के डिजाइन और फिर से डिजाइन करने के परिणामस्वरूप लगभग निश्चित हो जाता है, अप्रत्याशित डिजाइन परिवर्तनों की पुनरावृत्ति की एक उच्च संभावना। खोजों, और इसी तरह एक न्यूनतम-आम भाजक समाधान जो अंतर्निहित हार्डवेयर की पूर्ण विशिष्टता और शक्ति का दोहन करने में विफल रहता है।

डिपेंडेंसी फ्लो टुवर्ड्स स्टेबल बनाना, "इजी" डिज़ाइन्स

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

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

मुश्किल पर निर्भर करता है आसान, आसान पर नहीं निर्भर करता है मुश्किल

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

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

• मैं "स्थिरता / अस्थिरता" का उपयोग अंकल बॉब के अभिवाही / अपवाही कपलिंग मेट्रिक से थोड़े अलग अर्थों में कर रहा हूं जो कि परिवर्तन की कठिनाई को अधिक से अधिक माप रहा है जहां तक ​​मैं समझ सकता हूं। मैं "परिवर्तन की आवश्यकता की संभावना" के बारे में अधिक बात कर रहा हूं, हालांकि उसकी स्थिरता मीट्रिक वहां उपयोगी है। जब "परिवर्तन की संभावना" "परिवर्तन में आसानी" के लिए आनुपातिक होती है (उदा: परिवर्तन की आवश्यकता के लिए सबसे अधिक संभावना अंकल बॉब की मैट्रिक से अस्थिरता और साहसी कपलिंग है), तो इस तरह के किसी भी संभावित परिवर्तन सस्ते और गैर-घुसपैठ करने के लिए होते हैं , किसी भी केंद्रीय डिजाइन को छूने के बिना केवल एक कार्यान्वयन की आवश्यकता होती है।

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

एकल जिम्मेदारी सिद्धांत

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

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

डेवलपर गर्व

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

Comments

मुझे लगता है कि "उन चीजों से दूर निर्भरता को दूर करना जो कि डिजाइन करना मुश्किल है" के विचार को समझ नहीं सकते हैं, क्या आप केवल विरासत के बारे में बात कर रहे हैं? पीएसपी / ओपनजीएल के उदाहरण का उपयोग करते हुए, आप एक बनाने के बजाय इसका मतलब है OpenGLBillboard, आप OpenGLRendererकिसी भी प्रकार का ड्रॉ करना जानते हैं IBillBoard? लेकिन क्या ऐसा होगा कि तर्क को सौंपने से IBillBoard, या इसमें IBillBoardसशर्त के साथ विशाल स्विच या प्रकार होंगे? यही कारण है कि मुझे समझ में आना मुश्किल है, क्योंकि यह बिल्कुल भी नहीं लगता है!

— स्टीव चामिलार्ड

@SteveChamaillard, अंतर, कहते हैं, PSP (सीमित हार्डवेयर) को पुराने स्कूल स्क्रैंडर पारदर्शिता और रेंडरिंग मूल्यांकन के एक अलग क्रम का उपयोग करके वॉल्यूम प्राइमरी को संभालना चाहिए: digitalrune.github.io/DigitalRune.Documentation/media/… । जब आपके पास एक केंद्रीय RendererPspहोता है जो आपके गेम दृश्य के उच्च-स्तरीय अमूर्तता को जानता है, तो यह सभी जादू और बैकफ्लिप्स कर सकता है, जिसे इस तरह की चीजों को प्रस्तुत करने की आवश्यकता होती है जो PSP पर आश्वस्त दिखती है ....

— ड्रैगन एनर्जी

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

— ड्रैगन एनर्जी

ठीक है, मुझे लगता है कि मुझे यह मिल गया है। मूल रूप से आप कह रहे हैं कि इस तरह की चिंताएं (यानी हार्डवेयर) इतनी उच्च स्तर की हैं कि निम्न स्तर की वस्तुएं बनाना जैसे कि BillBoardउन पर निर्भर करना वास्तव में कठिन होगा? जबकि एक IRendererउच्च स्तर पहले से ही है और बहुत कम परेशानी के साथ इन चिंताओं पर निर्भर कर सकता है?

— स्टीव चामिलार्ड ने

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

— ड्रैगन एनर्जी