"हॅलो, अमिगो! आज एलीने तुला अडॅप्टर पॅटर्नबद्दल सांगितले."
I/O प्रवाहांशी संबंधित बहुतेक वर्ग अडॅप्टर म्हणून लागू केले जातात. ते एकतर समतुल्य इंटरफेसमध्ये रूपांतरित करतात किंवा ते त्यांना जोडतात, साध्यापासून सुरू होऊन कॉम्प्लेक्सपर्यंत जातात.
" InputStreamReader आणि BufferedReader देखील अडॅप्टर्स आहेत का? कमीतकमी, ते ज्या प्रकारे वापरले जातात त्याप्रमाणे ते अॅडॉप्टरसारखेच असतात: एखादी वस्तू तयार केल्यानंतर, ती दुसर्या वर्गाच्या कन्स्ट्रक्टरकडे दिली जाते."
"होय, InputStreamReader इनपुटस्ट्रीम इंटरफेसला रीडर इंटरफेसमध्ये रूपांतरित करते . BufferedReader हे त्याच्या शुद्ध स्वरूपात अडॅप्टर नाही, कारण Java च्या निर्मात्यांनी त्याच्या पद्धतींना त्यांचा स्वतःचा वेगळा इंटरफेस न देण्याचा निर्णय घेतला आहे. पण ते नातेसंबंध आहे."
बॅझिलियन भिन्न वर्ग लिहिण्याऐवजी, Java च्या निर्मात्यांनी दोन डझन अडॅप्टर लिहिले आणि त्यांना प्रोग्रामरला हवे असले तरीही एकमेकांशी कनेक्ट करण्याची परवानगी दिली.
हा दृष्टिकोन अतिशय सोयीस्कर आहे. प्रोग्रामर नेहमीच तिचा वर्ग आणि/किंवा अॅडॉप्टर लिहू शकतो, त्याला एक मानक इंटरफेस लागू करू शकतो आणि ती तयार करत असलेल्या अॅडॉप्टर ऑब्जेक्ट्सच्या साखळीमध्ये समाविष्ट करू शकतो.
"म्हणून हे सर्व कसे कार्य करते. मोठ्या जटिल वर्गांऐवजी, आम्ही साध्या वस्तू आणि अडॅप्टरच्या साखळ्या बनवतो. आणि मग तुम्ही फक्त त्या तयार करा आणि त्यांना योग्य क्रमाने एकत्र करा!"
"आणि जे काही गहाळ आहे ते तुम्ही अंमलात आणता."
"हो, समजले."
"पण खरं तर मला आज तुम्हाला वाचक आणि लेखकाबद्दल सांगायचं होतं . हे दोन अमूर्त वर्ग आहेत जे इनपुटस्ट्रीम आणि आउटपुटस्ट्रीम वर्गांसारखेच आहेत. परंतु त्या वर्गांप्रमाणेच, हे दोन वर्ग वर्णांसह कार्य करतात. ते अक्षरे वाचतात आणि लिहितात. ते आहेत. मजकूर माहितीसह काम करताना अतिशय सोयीस्कर. त्यांच्याकडे असलेल्या पद्धती पाहू या:"
वाचक पद्धती | पद्धत काय करते |
---|---|
|
"ही पद्धत बफरमध्ये ( char array ), बफर पूर्ण भरेपर्यंत किंवा स्त्रोताकडे वाचण्यासाठी आणखी वर्ण नसेपर्यंत अनेक वर्ण लगेच वाचते." पद्धत प्रत्यक्षात वाचलेल्या वर्णांची संख्या परत करते (जे अॅरेच्या लांबीपेक्षा कमी असू शकते) |
|
"ही पद्धत एक वर्ण वाचते आणि ते परत करते. परिणाम दिसण्यासाठी इंटमध्ये रुंद केला जातो. उपलब्ध वर्ण नसल्यास, पद्धत -1 परत करते." |
|
वाचन पद्धतींसाठी कोणतेही न वाचलेले वर्ण असल्यास ही पद्धत सत्य दर्शवते |
|
ही पद्धत प्रवाह "बंद" करते. तुम्ही स्ट्रीमसह काम पूर्ण केल्यावर तुम्ही याला कॉल करता. ऑब्जेक्ट नंतर फाईल बंद करण्यासाठी आवश्यक असलेली हाउसकीपिंग ऑपरेशन्स इ. करते. या टप्प्यावर, तुम्ही प्रवाहातील कोणताही डेटा वाचू शकत नाही. |
"हे निष्पन्न झाले की रीडरची रीड(char [] cbuf) पद्धत आम्हाला एका वेळी एका वर्णाऐवजी अक्षरांचे संपूर्ण ब्लॉक वाचू देते. त्यामुळे ते जलद आणि अधिक सोयीस्कर आहे."
"नक्की. आणि आता लेखकाकडे कोणत्या पद्धती आहेत ते पाहूया:"
पद्धत | पद्धत काय करते |
---|---|
|
ही पद्धत एक अक्षर लिहिते. int प्रकार एका वर्णापर्यंत संकुचित केला आहे. अतिरिक्त भाग फक्त टाकून दिला जातो. |
|
ही पद्धत वर्णांची अॅरे लिहिते. |
|
ही पद्धत स्ट्रिंग लिहिते. हे फक्त अक्षरांच्या अॅरेमध्ये रूपांतरित केले जाते आणि नंतर दुसरी पद्धत म्हणतात. |
|
जर प्रवाह अद्याप लिहिलेला नसलेला कोणताही डेटा अंतर्गत संचयित करत असेल, तर ही पद्धत ते लिहिण्यास भाग पाडते. |
|
ही पद्धत प्रवाह "बंद" करते. तुम्ही स्ट्रीमसह काम पूर्ण केल्यावर तुम्ही याला कॉल करता. ऑब्जेक्ट नंतर फाइल बंद करण्यासाठी आवश्यक असलेली हाउसकीपिंग ऑपरेशन्स इ. करते. तुम्ही यापुढे स्ट्रीममध्ये डेटा लिहू शकत नाही आणि फ्लशला आपोआप कॉल केला जातो. |
वाचक आणि लेखक हे अमूर्त वर्ग आहेत हे समजून घेणे महत्त्वाचे आहे . ते काहीही करत नाहीत आणि त्यात अक्षरशः कोणताही कोड नसतो. त्यांच्या सर्व पद्धती त्यांना वारशाने मिळालेल्या वर्गांमध्ये लागू कराव्या लागतील. वर्ग कसे परस्परसंवाद करतात हे प्रमाणित करणे हे त्यांचे कार्य आहे . विकसकांना एकमेकांशी संवाद साधण्यासाठी त्यांच्या स्वतःच्या मानकांचा शोध लावण्याची गरज नाही. प्रत्येकासाठी काही मूलभूत मानके राखणे अधिक सोयीचे आहे. हे वेगवेगळ्या प्रोग्रामरद्वारे लिहिलेल्या वर्गांना फक्त Java च्या निर्मात्यांनी लिहिलेल्या वर्गांशीच नव्हे तर इतर प्रोग्रामरने लिहिलेल्या वर्गांशी देखील सहज संवाद साधण्याची परवानगी देते.
मानके शक्तिशाली आहेत.
"मी सहमत आहे. सामान्य मानकांचे समर्थन करणे प्रत्येकासाठी फायदेशीर आहे."
GO TO FULL VERSION