पुस्तक "आधुनिक जावा। लैम्ब्डा एक्सप्रेशंस, स्ट्रीम्स, एंड फंक्शनल प्रोग्रामिंग ”

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

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

इस पुस्तक में: • नई जावा सुविधाएँ • स्ट्रीमिंग डेटा और प्रतिक्रियाशील प्रोग्रामिंग • जावा मंच मॉड्यूल प्रणाली।

अंश। अध्याय 11. शून्य के लिए सबसे अच्छा विकल्प के रूप में वैकल्पिक वर्ग

अपने हाथ को उठाएं अगर आपके करियर के दौरान जावा डेवलपर के रूप में आपको कभी भी NullPointerException प्राप्त हुई है। यदि यह अपवाद आपके द्वारा सामना किया गया सबसे आम है, तो इसे छोड़ दें। दुर्भाग्य से, हम आपको अब नहीं देखते हैं, लेकिन यह बहुत संभावना है कि आपका हाथ उठा हुआ है। हमें यह भी संदेह है कि आप कुछ ऐसा सोच रहे होंगे: “हाँ, मैं सहमत हूँ। अपवाद NullPointerException किसी भी जावा डेवलपर के लिए सिरदर्द है, चाहे वह शुरुआती या विशेषज्ञ हो। लेकिन उनके साथ कुछ भी नहीं किया जा सकता है, यह वह कीमत है जो हम ऐसे सुविधाजनक और संभवतः अपरिहार्य डिजाइन का उपयोग खाली लिंक के रूप में करते हैं। ” यह (अनिवार्य) प्रोग्रामिंग की दुनिया में एक आम राय है; फिर भी, शायद यह पूरी सच्चाई नहीं है, बल्कि एक गहरी पक्षपातपूर्ण जड़ है।

ब्रिटिश कंप्यूटर विज्ञान विशेषज्ञ टोनी होरे, जिन्होंने 1965 में अशक्त लिंक का निर्माण किया, जबकि ALGOL W भाषा को विकसित करते हुए, पहले टाइप की गई प्रोग्रामिंग भाषाओं में से एक, जिसके रिकॉर्ड को स्मृति को ढेर पर आवंटित किया गया था, बाद में स्वीकार किया कि उसने यह किया " सिर्फ कार्यान्वयन में आसानी के कारण। ” यद्यपि वह खाली लिंक के लिए एक अपवाद का उपयोग करने की पूर्ण सुरक्षा की गारंटी देना चाहता था, उसने सोचा कि मूल्य की अनुपस्थिति को अनुकरण करने का यह सबसे सुविधाजनक तरीका था। कई साल बाद, उन्होंने इस निर्णय पर खेद व्यक्त किया, इसे "मेरी अरब डॉलर की गलती" कहा। हम सभी ने इस निर्णय के परिणामों को देखा। उदाहरण के लिए, हम यह निर्धारित करने के लिए किसी ऑब्जेक्ट के क्षेत्र की जांच कर सकते हैं कि क्या यह दो संभावित मूल्यों में से एक का प्रतिनिधित्व करता है, केवल यह पता लगाने के लिए कि हम ऑब्जेक्ट नहीं, बल्कि एक नल पॉइंटर चेक कर रहे हैं, और तुरंत इस कष्टप्रद NullPointerException को प्राप्त करें।

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

11.1। मूल्य की कमी का अनुकरण कैसे करें

कल्पना करें कि आपके पास कार बीमा खरीदने वाले कार के मालिक के लिए लिस्टिंग 11.1 में नेस्टेड ऑब्जेक्ट संरचना है।

लिस्टिंग 11.1। व्यक्ति / कार / बीमा डेटा मॉडल

public class Person { private Car car; public Car getCar() { return car; } } public class Car { private Insurance insurance; public Insurance getInsurance() { return insurance; } } public class Insurance { private String name; public String getName() { return name; } } 

आपको क्या लगता है कि निम्नलिखित कोड के साथ समस्या क्या है?

 public String getCarInsuranceName(Person person) { return person.getCar().getInsurance().getName(); } 

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

11.1.1। सुरक्षा जाँच के साथ NullPointerException को कम करें

अप्रत्याशित NullPointerException से कैसे बचें? आप आमतौर पर जहाँ भी ज़रूरत हो (और कभी-कभी, सुरक्षित प्रोग्रामिंग की आवश्यकताओं को पार करते हुए, और जहाँ आपको ज़रूरत नहीं है), और अक्सर अलग-अलग शैलियों में अशक्त चेक जोड़ सकते हैं। NullPointerException की पीढ़ी को रोकने के लिए एक विधि लिखने का हमारा पहला प्रयास लिस्टिंग 11.2 में दिखाया गया है।


यह विधि हर बार एक चर के शून्य होने की जाँच करती है, स्ट्रिंग मान को "अज्ञात" लौटाता है अगर इस dereferencing श्रृंखला में सामना किए गए चर में से कम से कम एक खाली मान है। इस नियम का एकमात्र अपवाद यह है कि हम अशक्त के लिए बीमा कंपनी के नाम की जांच नहीं करते हैं, क्योंकि हम जानते हैं कि (किसी भी अन्य कंपनी की तरह) इसका नाम होना चाहिए। कृपया ध्यान दें कि हम केवल विषय क्षेत्र के ज्ञान के कारण इस अंतिम जांच से बचने का प्रबंधन करते हैं, लेकिन यह तथ्य जावा कक्षाओं में परिलक्षित नहीं होता है जो हमारे डेटा को मॉडल करते हैं।

हमने 11.2 को सूचीबद्ध करने में विधि को "गहरी शंका" के रूप में वर्णित किया है, क्योंकि एक दोहराई जाने वाली परिपाटी इसमें ध्यान देने योग्य है: प्रत्येक बार संदेह होने पर, चर शून्य नहीं होता है, ब्लॉक होने पर आपको एक और नेस्टेड जोड़ना पड़ता है, जिससे कोड इंडिकेशन का स्तर बढ़ जाता है। जाहिर है, यह तकनीक अच्छी तरह से पैमाने पर नहीं है और पठनीयता को कम करती है, इसलिए एक अलग समाधान की कोशिश करना बेहतर है। इस समस्या से बचने के लिए, आइए एक अलग रास्ता अपनाएं, जैसा कि लिस्टिंग 11.3 में दिखाया गया है।

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


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

11.1.2। समस्याओं का सामना करना पड़ा अशक्त

ऊपर संक्षेप में, जावा में खाली लिंक का उपयोग सैद्धांतिक और व्यावहारिक दोनों समस्याओं का कारण बनता है।

• त्रुटियों के स्रोत के रूप में कार्य करता है। NullPointerException Java में सबसे आम (एक विस्तृत मार्जिन द्वारा) अपवाद है।
• "इन्फ्लेट्स" कोड। अक्सर अशक्त चेक के साथ कोड को पॉप्युलेट करने की आवश्यकता के कारण पठनीयता बिगड़ जाती है, अक्सर गहरा घोंसला होता है।
• इसका कोई मतलब नहीं है। इसमें किसी भी अर्थ संबंधी अर्थ का अभाव है, विशेष रूप से, स्थैतिक संकेतन के साथ किसी भाषा में अर्थ की अनुपस्थिति का मॉडलिंग करने का ऐसा तरीका मौलिक रूप से गलत है।
• जावा भाषा की विचारधारा का उल्लंघन करता है। जावा हमेशा डेवलपर्स से संकेत छिपाता है, एक अपवाद के साथ: एक शून्य सूचक।
• प्रकार प्रणाली में एक अंतर बनाता है। नल में किसी भी प्रकार या अन्य जानकारी शामिल नहीं है, इसलिए इसे किसी भी प्रकार के लिंक को सौंपा जा सकता है। यह सिस्टम के दूसरे हिस्से में नल को स्थानांतरित करते समय समस्याएं पैदा कर सकता है, जहां इस बारे में कोई जानकारी नहीं है कि यह नल शुरू में क्या होना चाहिए।

अगली उपधारा में अन्य व्यवहार्य समाधानों के आधार के रूप में, हम अन्य प्रोग्रामिंग भाषाओं द्वारा दी गई संभावनाओं की संक्षेप में जाँच करते हैं।

11.1.3। अन्य प्रोग्रामिंग भाषाओं में अशक्त करने के लिए विकल्प

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

def carInsuranceName = person?.car?.insurance?.name

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

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

अन्य कार्यात्मक प्रोग्रामिंग भाषाओं, जैसे हास्केल और स्काला, इस समस्या को अलग तरह से देखते हैं। हास्केल में एक शायद प्रकार होता है, जो अनिवार्य रूप से एक वैकल्पिक मूल्य को एन्क्रिप्ट करता है। एक प्रकार की वस्तु शायद निर्दिष्ट प्रकार का मान हो सकती है या कुछ भी नहीं हो सकती है। हास्केल में खाली लिंक की अवधारणा का अभाव है। स्केल में, टाइप T के मान की उपस्थिति या अनुपस्थिति को रोकने के लिए, एक समान तार्किक संरचना विकल्प [T] प्रदान किया जाता है, जिसे हम अध्याय 20 में चर्चा करेंगे। इस मामले में, आपको स्पष्ट रूप से जांचना होगा कि क्या प्रकार विकल्प के संचालन का उपयोग करके एक मूल्य मौजूद है, जो "अशक्त चेक" प्रदान करता है। । अब यह संभव नहीं है कि "नल की जांच करना भूल जाएं", क्योंकि प्रकार के सिस्टम को स्वयं जाँच की आवश्यकता होती है।

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

11.2। वैकल्पिक वर्ग का परिचय

जावा 8 में, हास्केल और स्काला भाषाओं के प्रभाव में, एक नया java.util.Optional वर्ग एक वैकल्पिक मूल्य को एनकैप्सुलेट करने के लिए प्रकट हुआ है। उदाहरण के लिए, यदि आप जानते हैं कि कोई व्यक्ति कार का मालिक हो सकता है या नहीं हो सकता है, तो आपको टाइप कार के साथ कार्मिक वर्ग में वैरिएबल कार की घोषणा नहीं करनी चाहिए और यदि व्यक्ति के पास कार नहीं है तो इसे खाली संदर्भ सौंप दें; इसके बजाय, इसका प्रकार वैकल्पिक होना चाहिए, जैसा कि अंजीर में दिखाया गया है। 11.1।


एक मूल्य को देखते हुए, वैकल्पिक वर्ग इसके लिए एक एडाप्टर के रूप में कार्य करता है। इसके विपरीत, Optional.empty विधि द्वारा लौटाए गए रिक्त वैकल्पिक का उपयोग करके एक मूल्य की अनुपस्थिति को मॉडल किया गया है। यह स्थिर फैक्टरी विधि वैकल्पिक वर्ग का एक विशेष अकेला उदाहरण देता है। आप सोच रहे होंगे कि खाली लिंक और Optional.empty () के बीच क्या अंतर है। शब्दार्थ, उन्हें एक और एक ही माना जा सकता है, लेकिन व्यवहार में उनके बीच भारी अंतर हैं। अनिवार्य रूप से अशक्तता को कम करने का प्रयास NullPointerException की ओर जाता है, और Optional.empty () एक वैकल्पिक, वैकल्पिक प्रकार का वैकल्पिक ऑब्जेक्ट है, जिसे आसानी से एक्सेस किया जा सकता है। जल्द ही आप देखेंगे कि वास्तव में कैसे।

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

इसे ध्यान में रखते हुए, आप लिस्टिंग 11.1 से मूल मॉडल को फिर से कर सकते हैं। हम वैकल्पिक वर्ग का उपयोग करते हैं, जैसा कि लिस्टिंग 11.4 में दिखाया गया है।

ध्यान दें कि वैकल्पिक वर्ग का उपयोग मॉडल के शब्दार्थ को समृद्ध करता है। व्यक्ति वर्ग में एक वैकल्पिक क्षेत्र और कार वर्ग में एक वैकल्पिक क्षेत्र इस तथ्य को दर्शाता है कि किसी व्यक्ति के पास कार हो सकती है या नहीं, जिस तरह एक मशीन बीमा हो सकती है या नहीं।

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


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

लेखकों के बारे में

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

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

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

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर पाई जा सकती है
» सामग्री
» अंश

फेरीवालों के लिए कूपन पर 25% की छूट - जावा

पुस्तक के पेपर संस्करण के भुगतान पर, एक इलेक्ट्रॉनिक पुस्तक ई-मेल द्वारा भेजी जाती है।