حاصل کرنے والے/سیٹرز۔ برائی اور مدت

ایگور بگینکو کا مضمون 19 ستمبر 2014 | اس میں پوسٹ کیا گیا: کور جاوا یہ پرانی بحث ایلن ہولوب نے اپنے مشہور مضمون میں 2003 میں شروع کی تھی، کیوں گیٹر اور سیٹٹر کے طریقے برے ہیں - کیا گیٹرز/سیٹرز ایک مخالف پیٹرن ہیں اور کیا ہمیں ان سے بچنا چاہیے، یا یہ کوئی ایسی چیز ہے جو ہم ہیں''۔ آبجیکٹ اورینٹڈ پروگرامنگ میں ضرورت ہے۔ میں اس بحث میں اپنے دو سینٹ شامل کروں گا۔ نیچے دیے گئے متن کا خلاصہ یہ ہے: حاصل کرنے والے اور سیٹ کرنے والے بری مشق ہیں؛ ان کو استعمال کرنے والوں کے پاس کوئی عذر نہیں ہے۔ لیکن ایک بار پھر، غلط فہمی سے بچنے کے لیے، میں ہرگز یہ تجویز نہیں کر رہا ہوں کہ جہاں بھی ممکن ہو get/set کے استعمال سے گریز کیا جائے۔ نہیں. میں کہہ رہا ہوں کہ آپ نے انہیں اپنے کوڈ کے قریب بھی نہیں جانے دیا ۔ اس بیان کے بارے میں آپ کا کیا خیال ہے؟ آپ کی توجہ کے قابل؟ کیا آپ 15 سالوں سے گیٹ/سیٹ پیٹرن استعمال کر رہے ہیں اور کیا آپ جاوا کے ایک معزز معمار ہیں؟ اور آپ کسی اجنبی سے یہ بکواس سننا بھی نہیں چاہتے؟ ٹھیک ہے... میں آپ کے جذبات کو سمجھتا ہوں۔ میں نے اسی طرح محسوس کیا جب تک کہ میں ڈیوڈ ویسٹ کی کتاب "آبجیکٹ تھنکنگ" کو نہیں دیکھ پایا - یہ آبجیکٹ اورینٹڈ پروگرامنگ کی بہترین کتاب ہے جو میں نے کبھی پڑھی ہے۔ تو پلیز۔ پرسکون ہو جاؤ اور سمجھنے کی کوشش کرو کہ میں کیا سمجھانے کی کوشش کر رہا ہوں۔ تنازعہ کا موضوع آبجیکٹ پر مبنی دنیا میں "ایکسیسرز" (گیٹرز اور سیٹٹرز کا دوسرا نام) کے خلاف کئی دلائل موجود ہیں۔ اور وہ سب بہت درست دلائل ہیں۔ آئیے ان پر ایک سرسری نظر ڈالتے ہیں۔ پوچھو، مت بتاؤ : ایلن ہولوب کہتے ہیں، "وہ معلومات نہ پوچھیں جس کی آپ کو نوکری کرنے کی ضرورت ہے؛ اس ادارے سے 'پوچھیں' جس کے پاس یہ معلومات آپ کے لیے کام کرنے کے لیے ہیں۔" انکیپسولیشن کے اصول کی خلاف ورزی : ​​ایک آبجیکٹ کو دوسری اشیاء کے ذریعے الگ کیا جا سکتا ہے کیونکہ وہ سیٹرز کے ذریعے کسی بھی ڈیٹا کو آبجیکٹ میں ایمبیڈ کرنے کے قابل ہوتے ہیں۔ کوئی شے محض اپنی حالت کو محفوظ طریقے سے سمیٹ نہیں سکتی کیونکہ کوئی بھی اس حالت کو بدل سکتا ہے۔ عمل درآمد کی تفصیلات سامنے آئی ہیں : اگر آپ کسی دوسرے شے سے ایک شے حاصل کر سکتے ہیں، تو ہم پہلی چیز کے نفاذ کی تفصیلات پر بہت زیادہ انحصار کر رہے ہیں۔ اگر کل یہ بدل جاتا ہے (مثال کے طور پر، نتیجہ کی قسم)، تو ہمیں کوڈ کو تبدیل کرنا پڑے گا۔ مندرجہ بالا تمام دلیلیں یقینی طور پر معنی رکھتی ہیں، لیکن یہ سب سے اہم نقطہ نظر سے محروم ہے. بنیادی غلط فہمی زیادہ تر پروگرامرز کا خیال ہے کہ ایک آبجیکٹ طریقوں کے ساتھ ڈیٹا کا ڈھانچہ ہے۔ میں بوزہدار بوزہانوف کے مضمون کا حوالہ دیتا ہوں: گیٹرز اور سیٹرز برے نہیں ہیں۔. لیکن زیادہ تر اشیاء جن کے لیے گیٹرز اور سیٹرز بنائے جاتے ہیں ان میں صرف ڈیٹا ہوتا ہے۔ یہ غلط فہمی ایک بہت بڑی غلط فہمی کا نتیجہ ہے! آبجیکٹ "صرف ڈیٹا اسٹور نہیں کرتے ہیں۔" آبجیکٹ ڈیٹا کے ڈھانچے نہیں ہیں جن میں طریقے منسلک ہیں۔ "ڈیٹا اسٹوریج" کا یہ تصور آبجیکٹ پر مبنی پروگرامنگ اور طریقہ کار کی زبانوں، خاص طور پر C اور COBOL سے آیا ہے۔ میں دوبارہ دہراؤں گا: کوئی شے صرف ڈیٹا عناصر اور افعال کا مجموعہ نہیں ہے جو ان میں ہیرا پھیری کرتے ہیں۔ ایک آبجیکٹ ڈیٹا آبجیکٹ نہیں ہے۔ پھر کیا؟ بال اور کتا حقیقی آبجیکٹ پر مبنی پروگرامنگ میں، اشیاء جاندار ہیں، بالکل آپ اور میری طرح۔ وہ جاندار ہیں، اپنے رویے، خصوصیات اور زندگی کے چکر کے ساتھ۔ کیا کسی جاندار میں سیٹر ہو سکتا ہے؟ کیا آپ کتے کے ساتھ گیند ("سیٹ") جوڑ سکتے ہیں؟ مت سوچو۔ لیکن یہ بالکل وہی ہے جو ذیل میں کوڈ کا ٹکڑا کرتا ہے:

Dog dog = new Dog();
dog.setBall(new Ball());

تو آپ کو یہ کیسا لگتا ہے؟ کیا آپ کتے سے گیند نکال سکتے ہیں ("حاصل")؟ ٹھیک ہے، آئیے فرض کریں کہ آپ کر سکتے ہیں۔ اگر اس نے کھا لیا اور آپ نے اس کی سرجری کر دی۔ اس صورت میں، ہاں، آپ کتے سے گیند حاصل کر سکیں گے ("حاصل")۔ یہ بالکل وہی ہے جس کے بارے میں میں بات کر رہا ہوں:

Dog dog = new Dog();
Ball ball = dog.getBall();

یا اس سے بھی زیادہ مضحکہ خیز مثال:

Dog dog = new Dog();
dog.setWeight("23kg");

کیا آپ حقیقی زندگی میں اس کا تصور کر سکتے ہیں؟ کیا ایسا لگتا ہے جیسے آپ ہر روز لکھتے ہیں؟ اگر ہاں، تو آپ ایک پروسیجرل پروگرامر ہیں۔ بس اسے تسلیم کرو۔ ڈیوڈ ویسٹ نے اپنی کتاب کے صفحہ 30 پر کیا کہا ہے: ایک کامیاب پروسیجرل ڈویلپر کو ایک کامیاب مقصدی ڈویلپر میں تبدیل کرنے کا پہلا قدم ایک لوبوٹومی ہے۔ کیا آپ کو لوبوٹومی کی ضرورت ہے؟ مجھے اس کی ضرور ضرورت تھی، اور مجھے یہ مغرب کی کتاب "آبجیکٹ تھنکنگ" پڑھتے ہوئے ملا۔ معروضی سوچ کسی چیز کی طرح سوچنا شروع کریں اور آپ فوری طور پر ان طریقوں کا نام بدل دیں گے۔ یہ ہے جو آپ کو مل سکتا ہے:

Dog dog = new Dog();
dog.take(new Ball());
Ball ball = dog.give();

اب ہم کتے کو ایک حقیقی جانور سمجھتے ہیں جو ہم سے گیند لے سکتا ہے اور اگر ہم مانگیں تو واپس بھی دے سکتے ہیں۔ صرف اس صورت میں، میں نوٹ کرتا ہوں کہ کتا NULL واپس نہیں کر سکتا۔ کتے صرف یہ نہیں جانتے کہ NULL کیا ہے! مقصدی سوچ (سوچ) آپ کے کوڈ سے NULL حوالہ جات کو فوری طور پر ہٹا دیتی ہے۔ چارلس کرچٹن کے ذریعہ وانڈا (1988) نامی ایک مچھلی مزید برآں، معروضی سوچ کسی چیز کی غیر متغیر ہونے کا باعث بنے گی، جیسے کہ ہماری مثال میں "کتے کا وزن"۔ آپ کوڈ کو کچھ اس طرح دوبارہ لکھیں گے:

Dog dog = new Dog("23kg");
int weight = dog.weight();

کتا ایک غیر تبدیل شدہ جاندار ہے جو باہر کے کسی کو بھی اپنا وزن، سائز یا نام تبدیل کرنے کی اجازت نہیں دیتا ہے۔ وہ درخواست پر اپنا وزن یا نام بتا سکتی ہے۔ عوامی طریقوں میں کوئی حرج نہیں ہے جو کسی چیز کی کچھ "اندرونی" خصوصیات کے سوالات کو بے نقاب کرتے ہیں۔ لیکن یہ طریقے "حاصل کرنے والے" نہیں ہیں اور انہیں کبھی بھی "گیٹ" کا سابقہ ​​نہیں لینا چاہیے۔ ہم کتے سے باہر نہیں نکلتے۔ ہمیں اس کا نام نہیں آتا۔ ہم اس سے کہتے ہیں کہ وہ ہمیں اپنا نام بتائے۔ کیا آپ فرق دیکھتے ہیں؟ ہم یہاں سیمنٹکس کے بارے میں بھی بات نہیں کر رہے ہیں۔ ہم پروگرامنگ کے طریقہ کار کو آبجیکٹ اورینٹڈ سے مختلف کرتے ہیں۔ پروسیجرل پروگرامنگ میں، ہم ڈیٹا کے ساتھ کام کرتے ہیں، اسے جوڑ توڑ کرتے ہیں، اسے حاصل کرتے ہیں، اسے سیٹ کرتے ہیں اور اگر ضروری ہو تو اسے حذف کرتے ہیں۔ ہم انچارج ہیں، اور ڈیٹا محض ایک غیر فعال جزو ہے۔ کتا ہمارے لیے کچھ بھی نہیں ہے - اس میں صرف "ڈیٹا ہوتا ہے۔" اس کی اپنی زندگی نہیں ہے۔ ہم آزادانہ طور پر اس سے اپنی ضرورت کی ہر چیز حاصل کر سکتے ہیں اور اس میں کوئی بھی ڈیٹا ڈال سکتے ہیں۔ اس طرح C، COBOL، Pascal اور دیگر طریقہ کار کی زبانیں کام کرتی ہیں (کام کرتی ہیں)۔ اور آبجیکٹ اورینٹڈ دنیا میں صورتحال اس کے بالکل برعکس ہے۔ یہاں ہم اشیاء کو جاندار مانتے ہیں، ان کی اپنی تاریخ پیدائش اور موت کے لمحے، ان کی اپنی شخصیت اور عادات کے ساتھ، اگر آپ چاہیں تو۔ ہم کتے سے ہمیں ڈیٹا کا ایک ٹکڑا دینے کے لیے کہہ سکتے ہیں (مثال کے طور پر اس کا وزن) اور وہ ہمیں معلومات واپس کر سکتا ہے۔ لیکن ہمیشہ یاد رکھیں کہ کتا ایک فعال جزو ہے۔ وہ فیصلہ کرتی ہے کہ درخواست کے بعد کیا ہوتا ہے۔ اور اسی وجہ سے کسی چیز کے طریقوں کو سیٹ یا حاصل سے شروع کرنا بالکل غلط ہے۔ اور یہ انکیپسولیشن کی خلاف ورزی کے بارے میں بھی نہیں ہے، جیسا کہ بہت سے لوگ سوچتے ہیں۔ یہ اس حقیقت کے بارے میں ہے کہ یا تو آپ کسی چیز کی طرح سوچ رہے ہیں یا پھر بھی جاوا نحو کے ساتھ COBOL لکھ رہے ہیں۔ پی ایس اور ہاں، آپ پوچھ سکتے ہیں: "جاوا بینز، جے پی اے، جے اے ایکس بی اور بہت سے دوسرے جاوا API کے بارے میں کیا ہے جو حاصل/سیٹ پر منحصر ہے؟" روبی میں بلٹ ان فنکشن کا کیا ہوگا جو ایکسیسرز بنانا آسان بناتا ہے؟ ٹھیک ہے، میں آپ کو کیا بتاؤں ... آپ کی قسمت سے باہر ہو. پروسیجرل COBOL کی قدیم دنیا میں رہنا حقیقی اشیاء کی حیرت انگیز دنیا کو سمجھنے اور قبول کرنے سے کہیں زیادہ آسان ہے۔ پی پی ایس _ میں یہ کہنا بھول گیا، ہاں، سیٹر کے ذریعے انحصار داخل کرنا بھی ایک خوفناک اینٹی پیٹرن ہے۔ لیکن اس پر مزید اگلی پوسٹ میں! اصل آرٹیکل