प्रक्रियात्मक प्रोग्रामिंग युग के डिजाइन पैटर्न क्या थे? [बन्द है]

Question

इसी तरह: 20 साल पहले प्रोग्रामिंग कैसे किया गया था?

OOP आजकल काफी फैशनेबल है, इसकी जड़ें 1960 के दशक में सिमूला 67 में थीं , और बाद में स्मॉलटाक और C ++ ने इसे लोकप्रिय बना दिया । हमारे पास DRY, SOLID, ऑब्जेक्ट-ओरिएंटेड दुनिया में डिज़ाइन पैटर्न के बारे में कई किताबें हैं।

लेकिन OOP प्रतिमान व्यापक अपनाने से पहले प्रोग्रामिंग में मुख्य सिद्धांत क्या थे? और प्रमुख डिजाइन पैटर्न क्या थे?

Comments

OOP वास्तव में थोड़ा पुराना है: en.wikipedia.org/wiki/Smalltalk देखें । इसके अलावा, DRY OOP के लिए अद्वितीय नहीं है; सिद्धांत सभी प्रोग्रामिंग प्रतिमानों में हो सकता है (और होना चाहिए), हालांकि उनके पास अलग-अलग उत्तर हैं कि इसे कैसे प्राप्त किया जाए।

— तदमर्स

ओओपी ज्यादातर सिमुला से आता है

— चार्ल्स सल्विया

OOP C ++ में इसकी जड़ें हैं ??? इन दिनों बच्चे ...:

— एंड्रेस एफ।

सौभाग्य से, वह सब जो बेकार की मार्केटिंग करता है, यह सब प्रचार शब्द हमारे उद्योग में एक अपेक्षाकृत नई बात है। पुराने दिनों में हम सिर्फ प्रोग्राम करते थे, बिना किसी बकवास के।

— एसके-तर्क

@AndresF।, अपने प्रश्न में सीधे इसे संपादित करने के लिए स्वतंत्र महसूस करें।

— वोरैक

Answer 1

जावा सीखने से पहले मैं एक कोबोल डेवलपर था। मैंने 35 से अधिक वर्षों के लिए विकसित किया है।

प्रक्रियात्मक भाषाओं के दिनों में, अधिकांश प्रसंस्करण बैच में किया गया था। इतिहास में काफी दूर वापस जाओ, और यहां तक ​​कि कार्यक्रम संकलन भी बैच में पंच कार्ड के डेक के साथ किया गया था।

किलियन फोथ के दावे के विपरीत , हमारे पास 1970 और 1980 के दशक में डिजाइन पैटर्न थे। कोबोल में एक बहु-फ़ाइल मिलान / मर्ज करने का एक निश्चित तरीका था। कोबोल में मास्टर (टेप) फ़ाइल में लेनदेन को जोड़ने का एक निश्चित तरीका था। कोबोल में रिपोर्ट पीढ़ी को कोड करने का एक निश्चित तरीका था। यही कारण है कि आईबीएम की रिपोर्ट राइटर को कोबोल की बहुत सारी दुकानों में वास्तव में कर्षण नहीं मिला।

डीआरवाई सिद्धांत का प्रारंभिक अनुप्रयोग था। बहुत सारे पैराग्राफ बनाएं ताकि आप खुद को न दोहराएं। 1970 में संरचित कोडिंग तकनीक विकसित की गई और कोबोल ने 1985 में भाषा में संरचित शब्द (क्रिया) जोड़े।

आम तौर पर, जब हमने एक नया कोबोल कार्यक्रम लिखा, तो हमने एक पुराने कोबोल कार्यक्रम की नकल की और निर्दोष लोगों की सुरक्षा के लिए नामों को बदल दिया। हमने लगभग एक कोबोल कार्यक्रम को कागज़ की एक खाली शीट या एक रिक्त स्क्रीन से कोडित नहीं किया। यह एक बड़ा डिज़ाइन पैटर्न है जब आप पूरे कार्यक्रमों को कॉपी और पेस्ट कर सकते हैं।

कई कोबोल डिजाइन पैटर्न थे कि उन्हें जानने के लिए एक कोबोल प्रोग्रामर के लिए कई साल लग गए। यही कारण है कि कोबोल प्रोग्रामर आज, अधिकांश भाग के लिए, अभी भी 1985 सिंटैक्स का उपयोग कर रहे हैं।

Comments

+1। मेरे पास कोबोल, पास्कल के साथ एक ही अनुभव था और जब एक विक -20 पर खुद को बेसिक सिखा रहा था। कई चीजें थीं जो मैंने पुन: उपयोग की और चारों ओर नकल की।

— JohnP

BONSOP के बारे में कैसे, जो आज भी इस्तेमाल किया जाता है;)

— dbasnett

"कॉपी / पेस्ट / चेंज" को "डिज़ाइन पैटर्न" कहना (कम से कम जैसा कि हम आज शब्द का उपयोग करते हैं) - शायद यह "कोडिंग पैटर्न" का अधिक है?

— इजाकाता

@ इज़कट: यह वास्तव में एक कोडिंग पैटर्न नहीं है, क्योंकि आप अधिकांश कोडिंग से बच रहे हैं। एक "टेम्पलेट पैटर्न" के बारे में कैसे? आप सही कह रहे हैं कि कॉपी / पेस्ट / परिवर्तन आज के मानकों से अच्छा डिज़ाइन नहीं है। इसके बाद, हमारे पास यह सबसे अच्छा था।

— गिल्बर्ट ले ब्लांक

एक डिज़ाइन पैटर्न वही है जैसा कि उसने C & P कोबोल के साथ किया है, एक सिंगलटन को हमेशा उसी तरह कोडित किया जाता है - आप अब आपके लिए बॉयलरप्लेट को थूकने के लिए कुछ IDE भी प्राप्त कर सकते हैं। यह कटौती और पेस्ट से काफी अलग नहीं है।

— gbjbaanb

Answer 2

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

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

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

Comments

एक डिज़ाइन पैटर्न सिर्फ नाम है बेक और कनिंघम के साथ आया कोड की एक पैटर्न की अवधारणा को औपचारिक रूप से दोहराया जाता है। उन्होंने 1987 में ऐसा किया। फाउलर ने 2002 में अपनी पुस्तक प्रकाशित की और उन्हें लोकप्रिय बनाया।

— gbjbaanb

@ जीबीजैनब, मैंने सोचा था कि डिजाइन पैटर्न कम से कम कई दशक पीछे

— चले जाएंगे

@Vorac ये सॉफ्टवेयर के लिए नहीं थे

— gnat

Answer 3

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

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

Comments

हाँ, जो मैंने 25 साल पहले सीखा था

— बाइनरी वॉरियर

Answer 4

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

आप पुराने Win32 कोड में इसे बहुत कुछ देख सकते हैं, आप एक HANDLE में पास होंगे, जो कि विंडोज के कर्नेल में आवंटित कुछ राज्य का प्रतिनिधित्व करने वाला एक अपारदर्शी प्रकार होगा। आप इसे उस डेटा पर काम करने वाले कार्यों के लिए पहले पैरामीटर के रूप में आवंटित किए गए एक स्ट्रक्चर को पॉइंटर पास करके खुद कर सकते हैं।

Comments

यह काफी दिलचस्प है। मैं अन्य उदाहरणों की भी तलाश कर रहा हूं। उदाहरण के लिए, किसी ने "डेटा संरचनाओं के आसपास तर्क का निर्माण किया, न कि दूसरे तरीके के आसपास"?

— वोरैक

समान तरीके से आप अब करते हैं, सिवाय आपके तरीके विशेष भाषा समर्थन के बजाय कन्वेंशन, निहितार्थ या प्रलेखन द्वारा आपके डेटा संरचनाओं से जुड़े निशुल्क कार्य हैं।

— बेकार

इसकी तरह कैसे जावास्क्रिप्ट OO करता है, केवल JS के साथ फंक्शन पॉइंटर्स उस संरचना का हिस्सा हो सकते हैं जिसे आप पास करते हैं। वास्तव में कुछ भी नहीं बदलता है, हम सिर्फ उन पर

— आपत्ति

Answer 5

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

Answer 6

एक "परिमित राज्य मशीन" को एक पैटर्न के रूप में गिना जा सकता है, और एफएसएम को पूर्व-ओओ भाषाओं का उपयोग करके (संचार प्रोटोकॉल के लिए) लिखा गया था।

इसके अलावा "बीच हैंडलर" और टीएसआर लोकप्रिय डॉस पर इस्तेमाल किए जाते थे।

Answer 7

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

(आज हम "रैवियोली कोड" पीड़ित हैं, जिसमें कोड असंबंधित, कसकर पैक की गई कक्षाओं का एक गुच्छा जैसा है, बहुत कुछ रैवियोली की प्लेट की तरह है। हालांकि, कुछ OO विशेषज्ञ उचित रूप से पूछते हैं, "लेकिन ऐसा नहीं है कि OO माना जाता है। हमशक्ल?")

"सिंगल पॉइंट ऑफ एक्जिट" आज केवल एक निराशाजनक रिफैक्टिंग रोडबंप है। बहुत से देवता हैं जिनसे मैं बात भी नहीं करता, और जब मैं समझाता हूं तो वे बहुत खुश होते हैं। लेकिन पुराने दिनों में इसका मतलब कोड कोड से अचानक और स्पेगेटी कोड में कूदना नहीं था। तर्क के अंत में आगे बढ़ें, फिर शालीनता से बाहर निकलें।

मेरी मेमोरी तरीका, वापस जाने का तरीका, मुझे याद है कि प्रक्रियाओं में कोड को बंडल करने का विचार एक बड़ी छलांग था। यह विचार कि आप प्रक्रियाओं को अंतर-संचालनीय, पुन: प्रयोज्य मॉड्यूल में पैकेज कर सकते हैं, प्रोग्रामिंग के पवित्र कंघी बनानेवाले की रेती की तरह था।

EDIT: "सेल्फ-मॉडिफ़ाइंग कोड" भी मूल कयामत पर विशेष रूप से इस्तेमाल किया जाने वाला एक पैटर्न था। यह वह जगह है जहाँ कार्यक्रम वास्तव में इसके निर्देशों को राज्य के आधार पर तेजी से निर्देशों के साथ अधिलेखित कर देगा। जब मैं साइंस म्यूज़ियम में एक प्रोग्रामिंग कोर्स कर रहा था, तो मेरे प्रशिक्षक ने हमें सख्त चेतावनी दी, "सेल्फ-मॉडिफाइंग कोड न लिखें!"

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