आप एक अमूर्त परियोजना विवरण से वास्तविक कोड में कैसे जाते हैं?

Question

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

लेकिन अब प्रोफेसर ने इंटरफेस और अमूर्त वर्गों को मिश्रण में फेंक दिया है। बौद्धिक रूप से, मैं पहचान सकता हूं कि वे कैसे काम करते हैं, लेकिन मैं अपने अंगूठे को वर्तमान परियोजना के साथ इन नए उपकरणों का उपयोग करने के तरीके को समझ रहा हूं (एक वेब सर्वर अनुकरण)।

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

Answer 1

तो अंग्रेजी कोड (या जो भी आपकी भाषा है) कंप्यूटर कोड पर जाने के लिए सबसे अच्छे कदमों का उपयोग किया जाता है?

अनुभव वह है जो आपको यह कैसे सिखाता है। यह स्वाभाविक रूप से अभी तक आ रही है, तो है नहीं (! और अगर ऐसा नहीं होता है बुरा न मानें, क्योंकि यह एक लंबा समय लगता है), वहाँ कुछ सवाल आप खुद से पूछ सकते हैं:

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

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

यह निश्चित रूप से हिमशैल की नोक है। इस विचार प्रक्रिया के बारे में अधिक जानकारी के लिए, एरिक इवांस की उत्कृष्ट पुस्तक, Domain-Driven Design देखें।

आप कैसे तय करते हैं कि इंटरफ़ेस कहां और कब बनाना है, या एक अमूर्त वर्ग का उपयोग करें?

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

• हैं, तो एक अंतरफलक का उपयोग करें। उदाहरण के लिए, यदि Steerable इंटरफ़ेस में Steer(Vector bearing) विधि है, तो कई अलग-अलग चीजें हो सकती हैं जिन्हें स्टीयर किया जा सकता है: Boat एस, Airplane एस, CargoShip एस, Car एस, et cetera। ये पूरी तरह से असंबंधित चीजें हैं। लेकिन वे सभी स्टीयर होने में सक्षम होने के सामान्य इंटरफेस को साझा करते हैं।

• सामान्य रूप से, एक सार आधार वर्ग के बजाय इंटरफेस का पक्ष लेने का प्रयास करें। इस तरह आप एक एकल कार्यान्वयन को परिभाषित कर सकते हैं जो एन इंटरफेस लागू करता है। जावा के मामले में, आपके पास केवल एक सार आधार वर्ग हो सकता है, इसलिए जब आप कहते हैं कि एक वर्ग दूसरे से प्राप्त होता है तो आप एक विशेष विरासत पदानुक्रम में बंद हो जाते हैं।

• जब भी आपको बेस क्लास से कार्यान्वयन की आवश्यकता नहीं होती है, तो निश्चित रूप से एक सार आधार वर्ग पर एक इंटरफेस का पक्ष लेते हैं। यदि आप ऐसी भाषा में परिचालन कर रहे हैं जहां विरासत लागू नहीं होती है तो यह भी आसान होगा। उदाहरण के लिए, सी # में, आपके पास बेस क्लास से struct प्राप्त नहीं हो सकता है।

Answer 2

सामान्य में ...

1. अन्य लोगों के कोड का एक बहुत पढ़ें। ओपन सोर्स प्रोजेक्ट्स इसके लिए बहुत अच्छे हैं। हालांकि उनके लाइसेंस का सम्मान करें।
2. आप इसे कभी भी सही नहीं पाएंगे। यह एक पुनरावृत्ति प्रक्रिया है। निराश न हों अगर आपको यह सही नहीं लगता है।
3. अभ्यास। अभ्यास। अभ्यास।
4. अक्सर अनुसंधान। अधिक से अधिक चुनौतीपूर्ण परियोजनाओं/डिज़ाइनों का सामना करना जारी रखें। यहां तक ​​कि अगर आसपास के आसान हैं।

अच्छे डिजाइन के लिए कोई जादू बुलेट या एल्गोरिदम नहीं है।

आजकल मैं एक ऐसे डिजाइन के साथ कूदता हूं जो मेरा मानना ​​है कि वह सभ्य है और उससे काम करता है।

जब समय सही है, तो मैं समझूंगा कि परिणाम को बाद में इसके बजाय जल्द ही पुन: संसाधित (पुनः लिखना) होगा।

इस परियोजना को अपना सर्वश्रेष्ठ शॉट दें, अपनी गलतियों के लिए नजर रखें और अपने परिणामों को वापस लेने के बाद चीजें कैसे की जानी चाहिए।

ऐसा करना जारी रखें, और आप ठीक होंगे।

Answer 3

आपको वास्तव में क्या करना चाहिए code from the top-down, not from the bottom-up है। अपने मुख्य कार्य को स्पष्ट रूप से और संक्षेप में लिखें क्योंकि आप उन एपीआई का उपयोग कर सकते हैं जिन्हें आपने अभी तक नहीं बनाया है जैसे कि वे पहले से मौजूद हैं। फिर, आप उन एपीआई को समान रूप से लागू कर सकते हैं, जब तक कि आपके पास ऐसे कार्य न हों जो केवल कुछ पंक्तियां हों। यदि आप नीचे-नीचे से कोड करते हैं, तो संभवतः आप पूरी तरह से सामान की एक बहुत सारी चीज़ें तैयार करेंगे जो आपको वास्तव में नहीं चाहिए।

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

आपको इस संबंध में सहायक होने के लिए Google Techtalk "How to Design a Good API and Why it Matters" भी मिल सकता है। आप अपने कुछ software design observations पढ़ने में रुचि भी ले सकते हैं।

Answer 4

इसके अलावा, आने वाले भविष्य के लिए, आप असली दुनिया परिदृश्यों को संरेखित करने के लिए domain driven design पर मूल बातें पढ़ने के लिए पाइपलाइन में रख सकते हैं - यह वास्तविक कक्षाओं के लिए मैपिंग आवश्यकताओं के लिए ठोस आधार प्रदान करता है।