1. सामान्य आधार वर्ग
आज आम्ही मनोरंजक विषयांच्या स्मॉर्गसबोर्डचा आनंद घेऊ. बुद्धिबळाच्या तुकड्यांचे प्रतिनिधित्व करणारे सर्व वर्ग सुलभ करण्यासाठी आम्ही बेस क्लास कधी सुरू केला ते लक्षात ठेवा ? मला अशी आशा आहे 🙂ChessItem
आता कल्पना करा की प्रत्येक तुकड्यात एक draw()
पद्धत आहे जी स्क्रीनवर रेखाचित्रे हाताळते. तुम्ही draw()
मेथडला कॉल करा, आणि तुकडा त्याच्या वर्तमान निर्देशांकांवर स्वतःच काढतो. ही पद्धत बेस क्लासमध्ये हलवणे सोयीचे होईल.
जर draw()
पद्धत ChessItem बेस क्लासमध्ये असेल, तर आम्ही ती पीस क्लासमध्ये ओव्हरराइड करू शकतो आणि याप्रमाणे सुंदर कोड लिहू शकतो:
class ChessBoard
{
public void drawAllChessItems()
{
// Add the pieces to the list
ArrayList<ChessItem> items = new ArrayList<ChessItem>();
items.add(new King());
items.add(new Queen());
items.add(new Bishop());
// Draw them regardless of their type
for(ChessItem item: items)
{
item.draw();
}
}
}
बेस क्लास सादर करून ChessItem
, आम्ही कोड मोठ्या प्रमाणात सुलभ करण्यात सक्षम झालो: प्रत्येक वर्गाच्या पद्धती स्वतंत्रपणे कॉल करण्याची आवश्यकता नाही, आम्ही सर्व वस्तू एकाच संग्रहात सहजपणे संग्रहित करू शकतो इ.
परंतु येथे एक मनोरंजक प्रश्न आहे: draw()
वर्गात थेट घोषित केलेली पद्धत ChessItem
स्क्रीनवर काय दर्शविली पाहिजे? शेवटी, बुद्धिबळात असा कोणताही तुकडा नाही, म्हणून काढण्यासाठी काहीही नाही.
अगदी बरोबर आहे. ChessItem
इतकेच काय, थेट वस्तू तयार करण्यात काहीच अर्थ नाही . हा बुद्धिबळाचा तुकडा नाही तर फक्त एक अमूर्तता आहे - एक वर्ग जो आम्ही आमच्या सोयीसाठी तयार केला आहे. OOP मध्ये अॅब्स्ट्रॅक्शन कसे कार्य करते : आम्ही महत्त्वाचा डेटा आणि पद्धती (सर्व तुकड्यांद्वारे सामायिक केलेल्या) बेस क्लासमध्ये हलवतो आणि त्यांच्यातील फरक वेगळ्या वंशज वर्गांमध्ये ठेवतो.
2. अमूर्त वर्ग
अशा परिस्थितींसाठी, Java मध्ये एक विशेष प्रकारचा वर्ग आहे: अमूर्त वर्ग . ते प्रोग्रामरना समान वर्गांसह कार्य करणे सोपे करण्यासाठी आणि त्यांच्यातील डुप्लिकेट कोडचे प्रमाण कमी करण्यासाठी डिझाइन केले आहे.
अमूर्त वर्गांबद्दल जाणून घेण्यासाठी येथे तीन गोष्टी आहेत.
कोणतीही अंमलबजावणी नसलेली पद्धत
अमूर्त वर्गात अंमलबजावणीशिवाय पद्धत घोषणा असू शकते. हीच पद्धत अमूर्त बनवते. मेथड बॉडी फक्त अर्धविरामाने बदलली आहे. आणि पद्धतीच्या नावापूर्वी आपण abstract
कीवर्ड लिहितो. उदाहरण:
public abstract class ChessItem
{
public int x, y; // Coordinates
private int value; // The piece's value
public int getValue() // Ordinary method that returns value field
{
return value;
}
public abstract void draw(); // Abstract method. The implementation is missing.
}
अमूर्त वर्ग
अंमलबजावणीशिवाय प्रत्येक पद्धत अमूर्त कीवर्डसह चिन्हांकित केली जाते. जर एखाद्या वर्गात अगदी एक अमूर्त पद्धत असेल, तर वर्ग देखील कीवर्डसह चिन्हांकित केला जातो abstract
.
वस्तू तयार करण्यास मनाई
तुम्ही अमूर्त वर्गाच्या वस्तू तयार करू शकत नाही . असा कोड संकलित होणार नाही.
कोड | वर्णन |
---|---|
|
हा कोड संकलित करत नाही : |
|
पण तुम्ही हे करू शकता |
एक अमूर्त वर्ग वारसा
जर तुमच्या वर्गाला अमूर्त वर्गाचा वारसा मिळाला असेल, तर तुम्हाला सर्व वारसा मिळालेल्या अमूर्त पद्धती ओव्हरराइड करणे आवश्यक आहे, म्हणजे तुम्हाला त्यांच्यासाठी अंमलबजावणी लिहिणे आवश्यक आहे. अन्यथा, तुमचा वर्ग देखील अमूर्त घोषित करावा लागेल.
जर एखाद्या वर्गात थेट घोषित केलेली किंवा पालक वर्गाकडून वारशाने मिळालेली एकही लागू न केलेली पद्धत असेल , तर वर्ग अमूर्त मानला जातो.
आणि हे सर्व का आवश्यक आहे? अमूर्त वर्ग का आवश्यक आहेत? त्याऐवजी सामान्य वापरणे शक्य नाही का? आणि अॅबस्ट्रॅक्ट पद्धतींऐवजी, आपण मेथड बॉडी म्हणून फक्त दोन रिकाम्या कुरळे कंस लिहू शकत नाही का?
आम्ही करू शकलो. परंतु हे निर्बंध सुधारकासारखेच आहेत private
. आम्ही खाजगी कीवर्डचा वापर इतर प्रोग्रामरना थेट डेटामध्ये प्रवेश करण्यापासून रोखण्यासाठी आणि त्यांचे वर्ग लिहिताना केवळ आमच्या सार्वजनिक पद्धती वापरण्यास भाग पाडण्यासाठी वापरतो.
अमूर्त वर्गांमध्येही असेच आहे. अमूर्त वर्गाच्या लेखकाला वर्गाच्या वस्तू तयार करायच्या नाहीत. त्याऐवजी, अमूर्त वर्गातून अमूर्त पद्धती वारशाने मिळतील आणि नंतर अधिलिखित केल्या जाव्यात अशी लेखकाची अपेक्षा आहे.
या दृष्टिकोनाचा फायदा मोठ्या प्रकल्पांमध्ये सहज दिसून येतो. तुमच्याकडे जितके अधिक वर्ग आहेत, तितक्या स्पष्टपणे तुम्हाला त्यांच्या भूमिकांचे वर्णन करणे आवश्यक आहे. नजीकच्या भविष्यात या पद्धतीचा फायदा तुम्हाला दिसून येईल. प्रत्येक गोष्ट यातून जाते.
GO TO FULL VERSION